wichtiges UPDATE für controller 7.2.2 im stable

[haselchen]

@Bluefox

Eigenes Ego passt noch in die Klamotten?

[wendy2702]

Ich habe mal ein Frage als KI/Ai noob.

Wenn die KI/Ai ,durch wissentliches aktivieren der Funktion, mein und x andere System(e) kennen inklusive Logs, Adapter bzw. Instanz Konfigurationen usw.

Kann man das dann nicht durch den richtigen Prompt auch alles wieder abfragen? Also quasi jeder?

[Bluefox]

@wendy2702 Nein.

[DasBo1975]

Um auch mal was anderes zu sagen.

Ich begrüße diese Erweiterung und sehe es als durchaus positiv und sinnvoll an.
Alles entwickelt sich weiter und sowas gehört mit dazu.

Danke für die Arbeit und die aufgewendete Zeit

[wendy2702]

@Bluefox sagte:

@wendy2702 Nein.

Hm,

Ist das bestätigt oder irgendwie belegbar?

Ich meine selbst mit Google kann/konnte man Informationen über andere Systeme finden.

Hat eventuell jemand anderes der Erfahrung im Umgang mit KI/Ai hat noch weitere Informationen?

[Wildbill]

@Bluefox sagte:

@haselchen sagte:

Und darauf hab ich einfach kein Bock.

Alu-Hut ist nicht zu eng?

Ganz ehrlich. Mit solchen Reaktion bzw. Antworten auf, meiner Meinung nach, durchaus angebrachter Kritik oder Hinterfragung, braucht sich niemand mehr wundern, wenn es eine zunehmende Abwanderung von iobroker hin zu anderen Systemen geben sollte. Erst Recht, wenn das von einem DER Haupt-Maintainer von iobroker kommt.

Aber nur meine Meinung…

Gruss, Jürgen

[Bluefox]

@Wildbill sagte:

durchaus angebrachter Kritik

Ich bin einfach müde, ständig gegen Windmühlen zu kämpfen, und ehrlich gesagt auch enttäuscht von manchen Reaktionen.

Jahrelang gab es im System die Adapter iobroker.ws und iobroker.socket-io. Diese arbeiten nach einem ähnlichen Prinzip und bieten ebenfalls Schnittstellen, über die man mit ioBroker sehr viel machen kann. Darüber hat sich niemand beschwert. Auch diese Adapter waren in der Adapterliste sichtbar, selbst wenn sie nicht installiert waren.

Jetzt reicht es offenbar schon, wenn im Paketnamen MCP, KI oder AI steht, und plötzlich werden manche paranoid.

Vielleicht wäre es sinnvoll, einmal mit etwas Vernunft auf das Thema zu schauen: Solange in einer Steckdose kein Stecker steckt, passiert auch nichts. Und mit „Steckdose“ meine ich nicht nur MCP, sondern genauso Web, Admin, REST, Socket, Homematic, Redis und andere Schnittstellen. Das sind alles Zugänge, die theoretisch auch von KI oder anderen Systemen genutzt werden könnten.

Der entscheidende Punkt ist nicht der Name der Schnittstelle, sondern ob sie aktiviert, konfiguriert und freigegeben wurde. Ohne aktive Verbindung, ohne Zugangsdaten und ohne Berechtigungen passiert nichts.

[Wildbill]

@bluefox Soweit ist es (mir) schon klar. Aber wenn jemand das hinterfragt, eventuell nicht genau weiß, was wie tut oder vielleicht einfach auch mehr Details will dann einen „Aluhutträger“ zu unterstellen, anstatt sachlich auf das Thema einzugehen und die Bedenken detailiert auszuräumen, dann ist das eben, zumindest nach meinem Verständnis, nicht in Ordnung und der falsche Weg.
Wenn das einer liest, der gerade erst zu iobroker gekommen ist oder der sich bisher nur dafür interessiert, der könnte ein völlig falsches Bild vom Umgang der iobroker-User miteinander bekommen.

Gruss, Jürgen

[Homoran]

@Bluefox Das passt ja alles!
Aber was spricht dagegen diese Module erst dann zu installieren, wenn eine Checkbox "Assistenten nutzen (default inaktiv!) aktiviert wird, um diesen Ressentiments (aka Aluhut) entgegenzukommen?

Oder stelle ich mir das zu einfach vor?

[Bluefox]

@wendy2702 Ich habe den Eindruck, dass hier von mir ein Beweis für etwas verlangt wird, worauf ich gar keinen Zugriff haben kann: nämlich für Systeme, die nicht mir gehören und die ich nicht kontrolliere.

Man kann natürlich immer weiter nach Gegenargumenten suchen und jede Aussage bis ins Detail anzweifeln. Aber irgendwann sollte man zwischen realistischen Risiken, technischer Grundlage und reiner Spekulation unterscheiden.

Wenn man grundsätzlich davon ausgeht, dass jedes System gefährlich ist, nur weil es theoretisch irgendwie missbraucht werden könnte, dann kann man am Ende gar keine Technik mehr benutzen. Mit dieser Denkweise müsste man konsequenterweise auch das Handy in die Mikrowelle legen, weil es ebenfalls Schnittstellen, Funkmodule, Mikrofon, Kamera und Apps hat.

Sicherheitsbedenken sind berechtigt. Aber sie sollten auf konkreten Fakten und nachvollziehbaren technischen Zusammenhängen basieren — nicht auf der Suche nach immer neuen theoretischen Worst-Case-Szenarien.

[Bluefox]

@Homoran Wo ist der Unterschied zwischen ioBroker.ws und ioBroker.mcp? Beide sind Schnittstellen, über beide kann KI, oder wer auch immer zugreifen. Nur ws wird seit ca 7 Jahren geduldet und mcp (seit 2 Wochen) nicht.
Außer einfacher Panik vor KI sehe ich hier KEIN Problem. Nur, dass ich mehr Pakete pflegen muss. Und Arbeit habe ich mehr als genug.
Man hat mir keine Hilfe angeboten, man fordert nur Antworten auf Fragen, die man eigentlich selbst beantworten kann. Es ist Open-Source und man kann ALLES selbst anschauen.

[wendy2702]

@bluefox

Naja,

wie geschrieben bin ich KI/AI Noob und versuche das nur zu hinterfragen. Eine, wie auch von @homoran zuletzt gefragt, gesonderte Implementierung ist ja scheinbar nicht gewollt oder umsetzbar.

Wir haben den Leuten Jahrelang geschrieben wie böse es ist Ports zu öffnen etc., aber jetzt wird gesagt den IOB einer KI anzuvertrauen sei OK !?

Das beisst sich aus meiner Sicht halt etwas.

Glaube der Unterschied und das Hauptproblem ist das alle anderen von dir erwähnten Adapter frei installierbar und deinstallierbar sind. Bei der KI Sache im Admin sieht das jetzt aber anders aus.

Für mich ist das Thema jetzt aber beendet da sich daran eh nichts mehr ändern wird.

[Negalein]

@Bluefox sagte:

und plötzlich werden manche paranoid.

da geb ich dir voll Recht.

allen ist es egal, was ihr Handy, Alexa, Facebook, Insta usw. alles mitlauscht.
Aber kaum lesen oder hören sie KI, springt die Panik an.

Ich hätte es sofort aktiviert, wenn man trotz Abo nicht noch extra für die API zahlen müsste.

[mcm1957]

Da hier der Vergleich mit ioBroker.ws genannt wurde:

Welcher Adapter installiert den Adapter ioBroker.ws implizit? (Hoffe die Frage kann auch jemand anderer als Bluefox beantworten.)
Bei mir installiert admin weder den Adapter ioBroker.ws noch ioBroker.web. Admin läuft aber einwandfrei.

[Bluefox]

@mcm1957 ioBroker.web installiert ioBroker.ws und ioBroker.socket-io. Aber als Pakete und durch npm 2 oder so (vor lange Zeit) hat es funktioniert und die Adapter waren nicht in der Liste aufgetaucht, weil die unter /opt/iobroker/node_modules/iobroker.web/node_module/iobroker.ws waren. Ab irgendeine npm Version wurde implementiert, dass alle Pakete von welchen die Versionen passen in root node_modules liegen (also /opt/iobroker/node_modules/iobroker.ws). Dabei fangen dann die Pakete als Adapter im admin aufzutauchen. Das gleiche ist mit mcp passiert.

[Bluefox]

@Negalein sagte:

wenn man trotz Abo nicht noch extra für die API zahlen müsste.

Das war für mich die Überraschung, dass die doppelt das Geld verlangen. Ich suche noch die Lösung

[mcm1957]

@Bluefox sagte:

@mcm1957 ioBroker.web installiert ioBroker.ws und ioBroker.socket-io. Aber als Pakete und durch npm 2 oder so (vor lange Zeit) hat es funktioniert und die Adapter waren nicht in der Liste aufgetaucht, weil die unter /opt/iobroker/node_modules/iobroker.web/node_module/iobroker.ws waren. Ab irgendeine npm Version wurde implementiert, dass alle Pakete von welchen die Versionen passen in root node_modules liegen (also /opt/iobroker/node_modules/iobroker.ws). Dabei fangen dann die Pakete als Adapter im admin aufzutauchen. Das gleiche ist mit mcp passiert.

Danke - dann kann ich das mal nachstellen. Web hab ich auf dem Minisystem nicht installiert - daher seh ich die anderen Adapter nicht. Alles klar und nochmal DANKE

[mcm1957]

@Bluefox sagte:

@mcm1957 ioBroker.web installiert ioBroker.ws und ioBroker.socket-io. Aber als Pakete und durch npm 2 oder so (vor lange Zeit) hat es funktioniert und die Adapter waren nicht in der Liste aufgetaucht, weil die unter /opt/iobroker/node_modules/iobroker.web/node_module/iobroker.ws waren. Ab irgendeine npm Version wurde implementiert, dass alle Pakete von welchen die Versionen passen in root node_modules liegen (also /opt/iobroker/node_modules/iobroker.ws). Dabei fangen dann die Pakete als Adapter im admin aufzutauchen. Das gleiche ist mit mcp passiert.

Ich muss dir vollinhaltlich recht geben.
Bei Installation von ioBroker.web ist das Verhalten in Bezug auf ioBroker.socketion und ws (fast) ident. Die beiden Adapter erscheinen dann auch automatisch. Einziger Unterschied ist dass bei einem Versuch diese zu löschen keine Fehlermeldung über fehlende Files kommt sondern dass das Löschen scheinbar fehlerfrei durchgeht - der Adapter aber da bleibt. Das ist aber eigentlich nur eine kosmetische Spitzfindigkeit.

Insofern hast du voll recht dass das eigentlich nichts neues ist. Unterschied ist nur, dass diese Adapter mit web kommen und damit "einläuchtender" sind.

Leider hat sich die Diskussion darüber unnötig hochgeschaukelt. Konstruktiver wäre gewesen den Grund für die implizite Installation ausführlicher zu erläutern und ggF geeignet klarzustellen, dass damit keinerlei Fremdzugriffsmöglichkeit geschaffen wird.

DANKE für deine erläuternden Infos und die Querverweise.

[mcm1957]

@Bluefox sagte:

@Negalein sagte:

wenn man trotz Abo nicht noch extra für die API zahlen müsste.

Das war für mich die Überraschung, dass die doppelt das Geld verlangen. Ich suche noch die Lösung

DANKE - klingt mal gut

[mcm1957]

Blöde Frage obendrauf:
Wäre es nicht sinnvoll ioBroker.socketio bzw. ws und ioBroker.mcp als normale Dependencies in io-package.json (auch) zu listen?
Dann würde doch bei einem Deinstallationsversuch eine klare Meldung kommen dass das nicht geht da xyz den Adapter braucht. Wär ev. klarer als die Anzeige einer Deinstallation die de facto nicht funktioniert. Ist abe rnur ne Dankanregung.