Community Forum

Bluefox

@bloop Danke für die Vorstellung und vor allem für die Messungen. Dass gemma4 ohne Kontext bei 8 von 12 Fragen Funktionen erfindet, deckt sich mit dem, was ich bei kleinen lokalen Modellen sehe.

Hast du schon iobroker.ai-server + assistant + pi-agent ausprobiert? ai-server startet Ollama im Docker oder nutzt einen bestehenden Ollama-Server und stellt eine OpenAI-kompatible API bereit. Mit deiner 4090 wäre das Backend "External Ollama server" das richtige, NVIDIA im Docker-Container wird noch nicht unterstützt. Der assistant kann ein lokales LLM und pi-agent als Provider nutzen. Mich würde interessieren, ob dein RAG dort als zusätzliche Quelle über MCP Sinn ergibt und wie die Antworten damit im Vergleich aussehen.

Zu deiner Frage nach weiteren Quellen: Ja, die Adapter-READMEs halte ich für den wichtigsten nächsten Schritt. Die meisten Forumsfragen betreffen einen bestimmten Adapter und nicht die Skript-API oder io-package.json. Wahrscheinlich kommen deine 12 Fehlgriffe von 65 genau daher. Bei den Adaptern aus dem Latest-Repo sind die Lizenzen sehr unterschiedlich, das sollte in sources.json sauber mitlaufen. Interessant wären auch docs/ und die Changelogs, wo es sie gibt.

Zwei Fragen dazu:

Wie lange braucht ein Rebuild, wenn du alle Adapter aus dem Latest-Repo aufnimmst? Ein inkrementelles Update (nur Repos mit neuem Commit) wäre dann vermutlich sinnvoller als ein wöchentlicher Komplett-Rebuild.
Hast du einmal gemessen, wie groß der Unterschied bei einem großen Cloud-Modell mit und ohne RAG ist? Das wäre für viele hier interessanter, weil die meisten keine 4090 haben.

Thomas Braun

Oder man verwendet gar keine statischen IPs und spricht die Geräte über den Hostname an und verwendet ansonsten einen zentralen DHCP in seinem Netz. Mit IPv6 und Privacy Extensions funktioniert das mit festgehämmerten 'statischen' IPs eh nicht mehr wie in der Vergangenheit.

Thomas Braun

@mat-sche sagte:

der gesammte PI?

Komplett neu.

haus-automatisierung

@fuzzy1955 sagte:

Mein Handy hat sich via DHCP die IP meines Laptops geschnappt

Die im Laptop war statisch vergeben? Dann sollte die statische IP außerhalb des DHCP-Adressbereiches liegen.

jolic

Hi, in meinem Router kann ich einem Netzwerkgerät, also z.B. meinem Pi, immer die gleiche IPv4-Adresse zuweisen. Damit sollte kein anderes Gerät diese IP "schnappen".

Bluefox

@PRozAC Der kaputte Ordner steht schon in deiner npm ls-Ausgabe aus #6:

/opt/iobroker/node_modules/@aws-sdk/client-polly/node_modules/@aws-sdk/core

Dort fehlt die Version, und daran scheitert npm bei jedem install/uninstall. Mein find von oben hat mit -maxdepth 3 so tief gar nicht gesucht, sorry. Dieser eine Ordner ist nur eine verschachtelte Kopie und kann weg. Das oberste @aws-sdk/core@3.979.1 erfüllt ^3.978.7 auch so:

cd /opt/iobroker
rm -rf node_modules/@aws-sdk/client-polly/node_modules/@aws-sdk/core
npm ls @aws-sdk/core

Wenn npm ls kein invalid mehr meldet, sollten iob upgrade admin und auch iob del sayit wieder durchlaufen.

Dass sayit nach rm -rf wieder auftaucht, liegt sehr wahrscheinlich an einer übrig gebliebenen Instanz. Für vorhandene Instanzen installiert der Controller den Adapter beim Start einfach nach. Was zeigen diese beiden Befehle?

iob list instances | grep -i sayit
iob object list system.adapter.sayit*

Erstellt mit Claude

Bluefox

@FernetMenta danke, das klingt durchdacht. Die Policy mit tolerate-no-instance als Standard finde ich sinnvoll, und dass der Container "unhealthy" stehen bleibt statt in einen Crash-Loop zu laufen, ist gut.

Zum Admin: Welchen Hilfetext meinst du genau? Schick mir am besten einen Screenshot oder den Text, dann passen wir das im Admin für nicht offizielle Container an.

Zur möglichen Übernahme des offiziellen Images: Im js-controller hängt die Erkennung "offizielles Image" im Moment nur an /opt/scripts/.docker_config/.thisisdocker. Ab Version 8.1.0 des offiziellen Images ist damit auch das Controller-Upgrade über die UI wieder freigeschaltet. Außerdem wird die neueste Image-Version fest von iobroker/iobroker auf Docker Hub abgefragt. Bei deinem Konzept (Version des Images = Version des js-controllers, kein Upgrade aus dem Container heraus) passt das nicht. Wenn es so weit ist, sollten wir die Erkennung im js-controller gemeinsam anpassen.

Bei den nativen Modulen bleibt für mich der Punkt mit den Adaptern offen. Wenn ein Adapter nach einem Node-Major-Wechsel keinen passenden Prebuild hat, sollte im Log klar stehen, dass ohne Build-Chain nicht gebaut werden kann, statt nur des node-gyp-Fehlers.

Bluefox

@Mico fast. Du musst nicht jeden Shelly einzeln prüfen. receivedBy gibt es pro BLE-Gerät, nicht pro Shelly: shelly.0.ble.<mac>.receivedBy. Darin steht ein JSON mit allen Shellys, die das Gerät empfangen haben, jeweils mit rssi und ts. Du wertest also nur diesen einen DP aus und nimmst den neuesten Zeitstempel.

Ja, das große Teil (Sensor mit Batterie) kommt ins Auto, der Magnet bleibt liegen. Wichtig: In der Shelly App den Beacon-Modus aktivieren, sonst sendet er nur beim Öffnen/Schließen und du bekommst im Auto nichts.

Beispiel für den javascript-Adapter:

const BLE_ID = 'shelly.0.ble.<mac>.receivedBy';   // MAC anpassen
const PRESENCE_ID = '0_userdata.0.autoZuhause';
const TIMEOUT_MIN = 10;

createState(PRESENCE_ID, false, { type: 'boolean', role: 'indicator', read: true, write: false });

function check() {
    let lastTs = 0;
    const st = getState(BLE_ID);
    if (st && st.val) {
        try {
            const list = JSON.parse(st.val);
            for (const dev of Object.keys(list)) {
                lastTs = Math.max(lastTs, list[dev].ts || 0);
            }
        } catch (e) {
            log(`Cannot parse receivedBy: ${e}`, 'warn');
        }
    }
    const present = Date.now() - lastTs < TIMEOUT_MIN * 60000;
    if (getState(PRESENCE_ID).val !== present) {
        setState(PRESENCE_ID, present, true);
    }
}

on({ id: BLE_ID, change: 'any' }, check);
schedule('* * * * *', check);
check();

Der Schedule ist wichtig. Wenn das Auto weg ist, kommt nämlich kein Update mehr, und "weg" erkennst du nur am Timeout. Den Timeout würde ich nicht zu kurz wählen, weil BLE im Auto (Blech, Garage) gerne mal ein paar Pakete verliert. Schau dir am besten erst ein, zwei Tage die ts/rssi Werte an, bevor du die Alarmanlage dranhängst.

Thomas Braun

@mat-sche sagte:

Das sollte doch 64bit sein?!

Nein, nicht zwingend. Das userland kann 32Bittig sein. Das siehst du u. a. in der Ausgabe von

iob diag

Wenn du per

iob nodejs-update

das nodejs Update anleierst wird dir das aber auch angezeigt.

Mico

Das klingt ja schon mal vielversprechend

Also auf allen Shellys Gen2 läuft bei mir der BLE Script zZ. Vers. 1.4
Ich habe noch ein Door Window liegen zum testen.

Der hat ja zwei Teile den großen und der kleine der sich webewegt wenn Tür oder Fenster geöffnet werden. Denn großen würde ich dann ins Auto legen.
Dann bräuchte ich also den DP wenn der da ist bzw. weg das wäre der DP shelly.0.ble.receivedby die müßte ich dann von allen shelly überprüfen ob dort der Sender da bzw. weg ist und dann kann ich etwas schalten richtig?

Community Forum

Pro

Beiträge

Mitgliederliste