NEWS

@pk68 Danke für die Info, habe es an den Buttons heute morgen bemerkt...lol

@mcu habe gerade was gefunden

https://forum.iobroker.net/topic/80855/opendtu-onbattery-blockly-dpl-ein-aus/3

@homoran sagte in Wieder mal der Fully ...:

@dr-pie sagte in Wieder mal der Fully ...:

Dort steht die 192.168.178.28:8082/vis/index.html?3#Flur drin.

was ist das???

Unter diesem Pfad sind alle Dateien abgelegt... /vis.0/3/
Ich habe natürlich auch versucht alles unter /vis.0 zu legen.
Dann lädt die Vis am Laptop und am PC problemlos (wie immer) aber kein Tab ... nachdem ich die neue url dort eingetragen habe.

@humidor konnte ich bereits über das Victron System lösen, somit erl.

@meister-mopper ich habe für FULLY BROWSER die Fully Plus licence gekauft ein gutes project das man unestutzen kann .der browser kann viel

@enzos Ebenso mit altem iPad, welches nur noch auf iOS 15.8.4 aktualisiert werden kann (hängt aber an der Wand und tut sonst seinen Dienst).
Vis lädt nicht mit web 7.0.8 oder 7.0.9. Downgrade auf 6.3.1 hat das Problem gelöst.
(log auf debug level hat keinen Fehler angezeigt).

@paul53 sagte in Umbenennen von Datenpunkten:

Die dürfen allerdings nicht umbenannt werden!

Natürlich nicht!
da kann aber nachdem der angebundene DP umbenannt wurde, ohne Änderungen an Skripten Visualisierungen o.ä. schnell umgestellt werden

@master67

Falls die return Energy Werte fehlen (weiß0 jetzt nich auswendig ob der plus plug s die prinzipiell kann, dann kann es notwendig sein dass die auf die aktuelle BETA Version aktualisierst. Aber bitte nur wenn dir was Wichtiges fehlt. BETA ist nicht stable :-).

Diskussionen dazu sollten aber aus diesem Topc dann rausgehalten werden. Dazu gibts das Topic https://forum.iobroker.net/topic/80722/test-adapter-shelly-9-4-x-latest-beta

Bei mir ist das Problem erst gestern aufgetreten, hat sich aber mit der vorgeschlagenen Maßnahme beheben lassen. Vielen Dank @Sammyray

@fuchs1978

Okay, habe ChatGPT mal seinen eigenen Unsinn erklären lassen. Macht wohl tatsächlich Sinn

Für alle anderen, die ich bis hier angelangt sind, nicht mehr weiterlesen. Nur den allerersten Post im thread beachten bitte. War alles Spaß

--

Das klingt nach einer ziemlich fortgeschrittenen Smart-Metering-/Energiemanagement-Installation – ich zerleg dir das gern in verständlichere Stücke:

Was du da machst:

iMSys via CLS über WAN ins HES
→ Dein intelligentes Messsystem (iMSys) kommuniziert über die Controllable-Local-System-Schnittstelle (CLS) über das Wide Area Network (WAN) direkt zum Head-End-System (HES). Das ist der klassische Fernzugriff auf das Energiemanagement-System über eine sichere Verbindung.

FNN-konformes SMGW
→ Du nutzt ein Smart Meter Gateway (SMGW), das den Vorgaben des Forum Netztechnik/Netzbetrieb (FNN) entspricht – also nach deutschem Standard zertifiziert ist.

EEG-Zugang über §14a EnWG mit Fallback auf 9er-Logik
→ Du profitierst vom §14a des Energiewirtschaftsgesetzes (steuerbare Verbrauchseinrichtungen), hast aber als Sicherheitsmechanismus (Fallback) die „9er-Logik“, vermutlich eine klassische Laststeuerungsregel (z. B. auf Schaltuhr-/Schaltlogikbasis).

Lokal angebundenes LMC via TAF10
→ Du hast ein Local Metrological Control (LMC) System, das lokal arbeitet und über das Tarifanwendungsfall 10 (TAF10 – Steuerung durch den Netzbetreiber) Daten erhält bzw. steuert.

ioBroker via EEBUS über SHIP-Stack
→ Dein ioBroker (Smart Home Zentrale) versucht über EEBUS (herstellerübergreifender Kommunikationsstandard für Energiemanagement) zu kommunizieren, wobei SHIP der Kommunikationsstack ist (Security Layer + IP-basierte Übertragung). Es gibt aber Probleme beim TLS-Handshaking – also der Verschlüsselungsverbindung auf HAN-Komponentenebene.

Update der BSI TR-03109 fehlt
→ Du vermutest, dass dein Problem daran liegt, dass dein System noch nicht die neueste Version der BSI-TR-03109 (Technische Richtlinie für SMGWs) verwendet.

EEBUS-SPINE-Bridge zu EDL40 klappt nicht wegen MDM-Konflikt
→ Du wolltest Daten von deinem EDL40-Zähler (ein moderner Standard-Stromzähler) über eine Bridge ins System bringen, aber der Meter Data Management-Layer (MDM) macht Probleme – vermutlich durch inkompatibles Datenhandling oder fehlende IDs.

GWA-Whitelist
→ Du suchst nach einer Liste zugelassener bzw. unterstützter Geräte (Whitelist) von deinem Gateway Administrator (GWA), um die Kompatibilität sicherzustellen.

Kurz gesagt:

Du betreibst ein ziemlich professionelles Energiemanagement-System mit Fokus auf Standardkonformität (FNN, EnWG, EEBUS etc.), kämpfst aber gerade mit Interoperabilitätsproblemen auf TLS-/HAN- und Zählerdaten-Ebene.

Wenn du willst, kann ich dir helfen, gezielt rauszufinden:

Welche Version der TR-03109 du brauchst Woher du ggf. eine GWA-Whitelist bekommst Wie man TLS-Probleme beim SHIP-Stack debuggt

Willst du das mal Schritt für Schritt durchgehen?

@sabinet
Danke für die Info, werde es morgen gleich Probieren
Lg iob_tom

@horst-böttcher sagte in Zigbee falsche anzeige ob ereichbar:

@asgothian sagte in Zigbee falsche anzeige ob ereichbar:

gut dann werde ich demchast mal ein conbee 2 hohlen fürleicht wird es dann besser ist ja nich ein aler conbee 2

Was willst du mit einem Conbee2 ? Was hast jetzt du als Koordinator ?

A.

@karl-heinz1 sagte in Backup gemacht keine Fehlermeldung Adapter werden nicht grün:

scheinbar war irgendwas im Hintergrund noch nicht fertig.

Der Restore stellt ausschließlich die Konfigurationen der Instanzen wieder her.
Die Adapterdateien werden anschließend neu gebaut.
Das dauert.

Sieht man u.a. daran, dass die Icons der Instanzen noch nicht da sind

Liebe Teilnehmerinnen und Teilnehmer,

wir möchten uns ganz herzlich bei euch für eure Teilnahme an der ersten Phase unserer Studie bedanken. Eure Unterstützung, eure Geduld und euer Interesse bedeuten uns wirklich viel!

Für einige von euch waren die Abläufe mitunter mit längeren Wartezeiten oder kleineren Unannehmlichkeiten verbunden – dafür möchten wir uns aufrichtig entschuldigen. Auch für uns war es das erste Mal, dass wir ein Projekt in dieser Form durchgeführt haben, und ganz ehrlich: Wir waren vom großen Andrang etwas überwältigt.

Dass so viele von euch mitgemacht haben, freut uns riesig – gleichzeitig hat es uns gezeigt, wo wir noch besser werden müssen. Wir nehmen eure Rückmeldungen ernst und arbeiten bereits daran, die zweite Phase der Studie reibungsloser und angenehmer für euch zu gestalten.

Phase 2 wird im zweiten Drittel dieses Jahres starten. Wir melden uns rechtzeitig mit allen Infos.

Nochmals: Danke, dass ihr Teil dieses Projekts seid. Ohne euch wäre das alles nicht möglich!

Herzliche Grüße und einen schönen Feiertag wünscht
Das KISSHome-Team

Ein eben abgeschlossener Rebuild hat KEINEN Fehler gezeigt,

Das Problem sollt daher behoben sein.

@andreios ich würde erst mal das readme hier lesen: https://github.com/rg-engineering/ioBroker.ebus
Dieser adapter funktioniert nur mit dem eBUS daemon: https://github.com/john30/ebusd
Dann ist die Frage, ob du auf das wlan Gateway lokal, ohne Internet und ohne app per browser zugreifen kannst.

@asgothian

ahh da gibts n Knopf um die Szene zu aktivieren.. der war aus.. ok.. geht.. alles klar, danke!
Mal wieder ein Layer-8 Error 😄

@oliverio

Bin da auch nicht drin. Aber ich vermute ein Broadcast verursacht zu viel Netzlast und die Latenz dürfte auch zu groß sein.

Es gibt aber wohl eine Möglichkeit den ntp-Server per DHCP zu übermitteln. Hab ich aber noch nie in freier Wildbahn gesehen.

Ich habedas Skript mal etwas "erweitert".

Das legt jetzt Datenpunkte unter "userdata" an. Die Daten können dann weiter in einer VIS verwendet werden.

const wrThreshold = 0.7; const moduleThreshold = 0.7; const minProduction = 5; const pushoverInstance = 'pushover.0'; const warnDelay = 15 * 60 * 1000; const groups = [ { name: "Solaranlage", wrs: [ { id: "114***********", name: "WR1_HM-1000", moduleCount: 2 }, { id: "114***********", name: "WR2_HM-1000", moduleCount: 2 }, { id: "114***********", name: "WR3_HM-1000", moduleCount: 2 } ] } ]; if (!globalThis.wrStatus) globalThis.wrStatus = {}; function sendPushoverMessage(message) { sendTo(pushoverInstance, 'send', { message, title: 'Wechselrichter-Überwachung', priority: 0 }); } function checkWRs() { let now = Date.now(); groups.forEach(group => { let wrPowers = []; let activeWRs = []; group.wrs.forEach((wr, i) => { const producingState = getState(`opendtu.0.${wr.id}.producing`).val; const isProducing = producingState === true || producingState === 'true'; const wrPower = isProducing ? getState(`opendtu.0.${wr.id}.power_dc`).val : 0; wrPowers[i] = wrPower; if (isProducing) { activeWRs.push({ index: i, ...wr, wrPower }); } // Schreibe Status in 0_userdata const statusText = isProducing ? (wrPower >= minProduction ? "✅ OK" : "⚠️ Schwache Produktion") : "❌ Keine Produktion"; setState(`0_userdata.0.WR_Status.${wr.name}.Status`, { val: statusText, ack: true }); }); if (activeWRs.length > 1) { let avgWR = activeWRs.reduce((sum, wr) => sum + wr.wrPower, 0) / activeWRs.length; activeWRs.forEach(wr => { let status = globalThis.wrStatus[wr.name] || { warnSince: null, warned: false }; if (wr.wrPower < avgWR * wrThreshold) { if (!status.warnSince) status.warnSince = now; if (!status.warned && (now - status.warnSince) >= warnDelay) { sendPushoverMessage(`⚠️ WR-Warnung (${group.name}): ${wr.name} liefert seit 15 Minuten nur ${wr.wrPower} W (Durchschnitt: ${avgWR.toFixed(1)} W)`); status.warned = true; } } else { if (status.warned) { sendPushoverMessage(`✅ Entwarnung (${group.name}): ${wr.name} liefert wieder ausreichend Leistung.`); } status.warnSince = null; status.warned = false; } globalThis.wrStatus[wr.name] = status; }); } activeWRs.forEach(wr => { let modulePowers = []; for (let m = 1; m <= wr.moduleCount; m++) { let modPower = getState(`opendtu.0.${wr.id}.dc.input_${m}.power`).val; modulePowers[m - 1] = modPower; } let avgModule = modulePowers.reduce((a, b) => a + b, 0) / wr.moduleCount; modulePowers.forEach((mp, idx) => { const modKey = `${wr.name}_modul${idx + 1}`; let status = globalThis.wrStatus[modKey] || { warnSince: null, warned: false }; // Modulstatus schreiben const modStatus = mp > 0 ? "✅ OK" : "❌ Kein Ertrag"; setState(`0_userdata.0.WR_Status.${wr.name}.Modul${idx + 1}`, { val: modStatus, ack: true }); if (mp < avgModule * moduleThreshold) { if (!status.warnSince) status.warnSince = now; if (!status.warned && (now - status.warnSince) >= warnDelay) { sendPushoverMessage(`⚠️ Modul-Warnung (${wr.name}): Modul ${idx + 1} liefert seit 15 Minuten nur ${mp} W (Durchschnitt: ${avgModule.toFixed(1)} W)`); status.warned = true; } } else { if (status.warned) { sendPushoverMessage(`✅ Entwarnung (${wr.name}): Modul ${idx + 1} liefert wieder ausreichend Leistung.`); } status.warnSince = null; status.warned = false; } globalThis.wrStatus[modKey] = status; }); }); group.wrs.forEach((wr, i) => { const producingState = getState(`opendtu.0.${wr.id}.producing`).val; const isProducing = producingState === true || producingState === 'true'; let status = globalThis.wrStatus[wr.name + "_prod"] || { warnSince: null, warned: false }; if (!isProducing) { let anyOtherProducing = group.wrs.some((otherWr, idx) => { if (idx !== i) { const otherState = getState(`opendtu.0.${otherWr.id}.producing`).val; return otherState === true || otherState === 'true'; } return false; }); if (anyOtherProducing) { if (!status.warnSince) status.warnSince = now; if (!status.warned && (now - status.warnSince) >= warnDelay) { sendPushoverMessage(`🔴 Ausfall (${group.name}): ${wr.name} produziert seit 15 Minuten nichts, obwohl andere laufen!`); status.warned = true; } } else { status.warnSince = null; status.warned = false; } } else { if (status.warned) { sendPushoverMessage(`✅ Entwarnung (${group.name}): ${wr.name} produziert wieder!`); } status.warnSince = null; status.warned = false; } globalThis.wrStatus[wr.name + "_prod"] = status; }); }); } schedule('*/2 * * * *', checkWRs);