UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[schweiger2]

Bin nicht wirklich bewandert im Umgang mit dem Thema "issues".

Bei mir (und vielen anderen) logged der Info-Adapter für sich selbst sehr viele Warnhinweise zu "wrong object types" - bekannt. Issue ist ja auch eröffnet worden.

https://github.com/iobroker-community-adapters/ioBroker.info/issues/281

Wie geht das eigentlich weiter ? Wen muss man bitten, den Adapter anzupassen ? Ist das Idittmar81 ?

Bitte gerade bei diesem Projekt auf Basis privaten Engagements meine Frage nicht falsch verstehen: gibt es so etwas wie (ungeschriebene) SLAs für solche Anpassungen ?

Beste Grüße
schweiger2

[Homoran]

@schweiger2 sagte in js-controller 3.3 jetzt im Latest:

gibt es so etwas wie (ungeschriebene) SLAs für solche Anpassungen ?

was ist denn SLA?

@schweiger2 sagte in js-controller 3.3 jetzt im Latest:

Wen muss man bitten, den Adapter anzupassen ?

ein issue beim Adapter reicht vollkommen

[schweiger2]

@homoran

SLA - Service Level Agreement - vereinbarte Zeit, innerhalb der geleistet wird

[Homoran]

@schweiger2 sagte in js-controller 3.3 jetzt im Latest:

@homoran

SLA - Service Level Agreement - vereinbarte Zeit, innerhalb der geleistet wird

Danke!
again what learned

Antwort auf die Frage von vorhin: gibbet nich - It's done, when it's done!

[foxriver76]

@schweiger2 Die Entwickler arbeiten auf freiwilliger Basis und unentgeltlich, daher gibt es so etwas selbstverständlich nicht. Was sollte denn passieren, wenn SLAs nicht eingehalten werden? Macht für mich nicht viel Sinn. Zumal handelt es sich hier nicht um einen Bug, welcher den Adapter unnutzbar macht, es wurde ja schon die ganze Zeit vor der Meldung der DP mit falschem Datentyp beschrieben. Ja, es ist womöglich nervig -> Workaround: Loglevel des Adapters ändern. Ansonsten wurden schon sehr viele Adapter gefixt und es folgen Weitere.

[deta]

@foxriver76 sagte in js-controller 3.3 jetzt im Latest:

@deta Nein, wird mit der nächsten Version gefixt sein, gab einen Bug wenn der Adapter keine Dependency hatte konnte es passieren, dass er mehrfach in die upgrade Queue gekommen ist

Alles klar.

[deta]

@thomas-braun sagte in js-controller 3.3 jetzt im Latest:

@deta

npm@7 funktioniert noch nicht korrekt zusammen mit dem ioBroker. Versuch npm@6

Hab mit der aktuellen npm@7 keine Probleme. Und @foxriver76 ,sagte es wird in der nächsten Version gefixt.

[Thomas Braun]

@deta
Ja, npm@7 tickt aber dennoch noch nicht ganz sauber mit dem ioBroker zusammen.

@apollon77 sagte:

Falls jemand wirklich mit Node.js 16.x experimentieren will, dann bitte AUSSCHLIESSLICH mit npm 6 !! (die npm Entwickler haben in npm 7 wieder Dinge geändert, die wir noch untersuchen)

Quelle:
https://forum.iobroker.net/topic/44624/js-controller-3-3-jetzt-im-latest

Also aus unserer Sicht sieht es aktuell gut aus, aber wir haben noch keine vollständigen Erfahrungen mit der Version. sieht Nodejs 16 an sich gut aus, aber von npm 7.10.0 raten wir dringend ab! Ein Downgrade auf npm 6 sollte raber problemlos auch mit Nodejs 16 tun!

Quelle:
https://forum.iobroker.net/topic/44421/iobroker-und-nodejs-16

Wie also immer bei Beta-Releases gilt: Kann funktionieren, kann aber auch in die Hose gehen. YMMV, wie der Franzose zu sagen pflegt.

[deta]

@thomas-braun Mag sein, habe NPM 7.11.2 am laufen, bisher keine Probleme.
Beobachte es immer beim Update. Nichts was nicht bis jetzt gegangen ist.

[Thomas Braun]

@deta
Wie gesagt: Kann funktionieren, kann auch in Einzelfällen in die Hose gehen. Hängt wohl auch davon ab wie komplex die Depencies der Adapter sind bzw. ob da noch skripte mit gezogen werden.

@apollon77 nochmal zitiert:

So, wir wären dann mal wieder soweit ... npm ist blöd

https://github.com/npm/cli/issues/3123

https://github.com/npm/cli/issues/3116

Beide Issues treffen uns scheinbar aktuell wenn man den js-controller über GitHub oder npm aktualisiert.

Also daher: Wir raten von npm 7 aktuell ab und beobachten die beiden Bugs. Ein Downgrade auf npm6 sollte auch mit nodejs 16 probemlos tun

Quelle:
https://forum.iobroker.net/topic/44421/iobroker-und-nodejs-16/9

[apollon77]

@thomas-braun @data EIn "issue" ist erledigt weil es am Ende kein Issue war nur npm jegliche Ausgaben bei einem Update unterdrückt. Das ist blöd aber verkraftbar ... Da läuft eine generelle Diskussion ob das so Sinn macht in einem RfC Ticket.

Das größere Issue ist das noch offene Ticket, was bei einigen Adaptern vllt - aber in jedem Fall bei js-controller Updates von GitHub für Alpha Tests - probleme machen wird. Schauen wir mal.

[JB_Sullivan]

@foxriver76 sagte in js-controller 3.3 jetzt im Latest:

Zumal handelt es sich hier nicht um einen Bug, welcher den Adapter unnutzbar macht, es wurde ja schon die ganze Zeit vor der Meldung der DP mit falschem Datentyp beschrieben. Ja, es ist womöglich nervig -> Workaround: Loglevel des Adapters ändern. Ansonsten wurden schon sehr viele Adapter gefixt und es folgen Weitere.

Da gebe ich dir nur bedingt Recht. Am Tag 1 als das "Problem" mit den vielen Warn-Meldunegn erstmalig auftrat, habe ich mich nicht weiter darum gekümmert und hatte im Anschluss eine LOG Datei von 200 MB Größe!

Wie man aus diversen Foren, Discord oder auch Facebook Beiträgen entnehmen kann, gibt es immer wieder Leute die ihr System auf latest stehen haben und sobald ungewöhnliche Meldungen aufkommen, nervös werden.

Bis sie dann den/die richtigen Beiträge zur Behebung des Phänomens (Workaround) gefunden oder genannt bekommen haben, ist die SD Karte evtl. schon mit übergroßen LOG Dateien geflutet und das Gesamt System auf dem PI fängt mit anderen Sonderbarkeiten an, auf den geringen Speicherplatz zu reagieren.

Von daher JA, erstmal haben die Meldungen keine Konsequenz auf die Funktion des Adapters. In der Summe und in den Händen einiger unbedarfter User, KÖNNTEN sich auch dieser reine Meldungsshower zu einem Problem entwickeln.

[Thomas Braun]

@jb_sullivan
Tja, und da hätten wir wieder die grundsätzlich ungünstige Konstellation aus 'unbedarftem User' und 'Einsatz von Beta-Software'.
Das sollte sich eigentlich gegenseitig ausschließen.

[foxriver76]

@jb_sullivan grundsätzlich ist meine Meinung das was Thomas bereits gesagt hat. Zudem haben wir vor einiger Zeit bewusst die Namensgebung der beiden Verwahrungsorte verändert und Beta sollte nahezu jedem vermitteln, dass es sich hier um Testversionen handelt. Und wenn ich mich bereit erkläre zu Testen, dann habe ich im besten Fall gerade bei Controller den Changelog gelesen + kann die Meldungen deuten/recherchieren. Ebenfalls gibt es hier diesen Thread.

Das Loglevel konnte man ebenfalls jederzeit verändern um die Meldungen zu unterbinden, Loggröße wird ebenfalls im Log-Tab angezeigt. Dein Szenario: Selbst bei 200 MB und dem default von 7 Tagen ergibt sich dabei unkomprimiert 1,4 GB, ist das Log File nicht mehr aktuell wird es zudem komprimiert.

Hätten wir aktuell einen besseren Weg diese Probleme auszumerzen würden wir ihn wählen, unser Ziel ist es sicher nicht die Nutzererfahrung hierdurch zu verschlechtern sondern langfristig zu verbessern.

[Homoran]

@foxriver76 sagte in js-controller 3.3 jetzt im Latest:

Beta sollte nahezu jedem vermitteln, dass es sich hier um Testversionen handelt.

das einzige problem dabei ist, dass man Jahre nach der latest-Installation, die damals noch von vielen propagiert wurde, nie wieder in die Systemeinstellungen sieht und den Namen "Beta" nie zu Gesicht bekommt

[FredF]

@foxriver76 sagte in js-controller 3.3 jetzt im Latest:

Beta sollte nahezu jedem vermitteln, dass es sich hier um Testversionen handelt.

@apollon77
evtl. wäre es sogar hilfreich den Titel dieses Threads zu ändern. Also latest auf beta oder so

[Thomas Braun]

@fredf
Da gebe ich dir Recht, man sollte imho den Begriff 'latest' konsequent durch Beta ersetzen.

[apollon77]

@fredf ok. Ich habe auch noch eine Admin5 ldee ;-)

[FredF]

@apollon77 die Spannung steigt :hand_with_index_and_middle_fingers_crossed:

[Homoran]

@fredf sagte in js-controller 3.3 jetzt im Beta:

evtl. wäre es sogar hilfreich den Titel dieses Threads zu ändern. Also latest auf beta oder so

steht doch da :joy: