NEWS

Nochmal zusammengefasst:

zuerst setzt man das Template.
Für einen 1Ch

{"NAME":"TX Ultimate 1","GPIO":[0,0,7808,0,7840,3872,0,0,0,1376,0,7776,0,0,224,3232,0,480,3200,0,0,0,3840,0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1,"CMND":"Backlog Pixels 28"}

2Ch

{"NAME":"TX Ultimate 2","GPIO":[0,0,7808,0,7840,3872,0,0,0,1376,0,7776,0,225,224,3232,0,480,3200,0,0,0,3840,0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1,"CMND":"Backlog Pixels 28"}

3Ch

{"NAME":"TX Ultimate 3","GPIO":[0,0,7808,0,7840,3872,0,0,0,1376,0,7776,0,225,224,3232,0,480,3200,0,0,0,3840,226,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1,"CMND":"Backlog Pixels 28"}

4Ch

{"NAME":"TX Ultimate 4","GPIO":[0,0,7808,0,7840,3872,0,0,0,1376,0,7776,0,225,224,3232,0,480,3200,227,0,0,3840,226,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1,"CMND":"Backlog Pixels 28"}

Danach erstelle ich unter Werkzeuge -> Dateisystem verwalten eine Datei mit dem Namen txultimate.be mit folgendem Inhalt:

class TXUltimate : Driver static header = bytes('AA55') var ser # create serial port object # intialize the serial port, if unspecified Tx/Rx are GPIO 16/17 def init(tx, rx) if !tx tx = 19 end if !rx rx = 22 end self.ser = serial(rx, tx, 115200, serial.SERIAL_8N1) tasmota.add_driver(self) end def split_55(b) var ret = [] var s = size(b) var i = s-2 # start from last-1 while i > 0 if b[i] == 0xAA && b[i+1] == 0x55 ret.push(b[i..s-1]) # push last msg to list b = b[(0..i-1)] # write the rest back to b end i -= 1 end ret.push(b) return ret end def crc16(data, poly) if !poly poly = 0x1021 end # CRC-16/CCITT-FALSE HASHING ALGORITHM var crc = 0xFFFF for i:0..size(data)-1 crc = crc ^ data[i] << 8 for j:0..7 if crc & 0x8000 crc = (crc << 1) ^ poly else crc = crc << 1 end end end return crc & 0xFFFF end def encode(payload) var msg_crc = self.crc16(bytes(payload)) # calc crc var b = bytes('AA55') # add header b += bytes(payload) # add payload b.add(msg_crc, -2) # add calculated crc 2 bytes, big endian return b end # send a string payload (needs to be a valid json string) def send(payload) print("TXU: Sent =", payload) var payload_bin = self.encode(payload) self.ser.write(payload_bin) log("TXU: Sent = " + str(payload_bin), 2) end # read serial port def every_50ms() if self.ser.available() > 0 var msg = self.ser.read() # read bytes from serial as bytes import string if size(msg) > 0 # print("TXU: Raw =", msg) if msg[0..1] == self.header var lst = self.split_55(msg) for i:0..size(lst)-1 msg = lst[i] print(msg) var event = "" var params = "" if msg[3] == 0x02 # 02 signifies a touch event # print('Touch event') if msg[4] == 0x01 # data lenght 1 is a press if msg[5] < 0x0B event = "Short" params = ',"Channel":' + str(msg[5]) print('Short press zone:', msg[5]) elif msg[5] == 0x0B event = "Multi" print('Multi press') elif msg[5] > 0x0B event = "Long" params = ',"Channel":' + str(msg[5]-16) print('Long press zone:', msg[5]) end elif msg[4] == 0x02 # data length 3 is a release event = "Touch" params = ',"Channel":' + str(msg[6]) print('Touch event:', msg[5], 'pos:', msg[6]) if msg[5] != 0x00 event = "Dash" params = ',"From":' + str(msg[6]) + ',"To":' + str(msg[5]) print('Mini swipe channel', msg[5], '->', msg[6]) end elif msg[4] == 0x03 # data lenght 1 is a swipe if msg[5] == 0x0C event = "Swipe right" params = ',"From":' + str(msg[6]) + ',"To":' + str(msg[7]) print('Swipe left-right', msg[6], '->', msg[7]) elif msg[5] == 0x0D event = "Swipe left" params = ',"From":' + str(msg[6]) + ',"To":' + str(msg[7]) print('Swipe right-left', msg[6], '->', msg[7]) end end var jm = string.format("{\"TXUltimate\":{\"Action\":\"%s\"%s}}",event,params) tasmota.publish_result(jm, "RESULT") end end end end end end end txu=TXUltimate()

und damit diese Datei auch beim Start geladen wird, noch eine weitere Datei mit dem Namen autoexec.be mit dem Inhalt

load("txultimate.be")

Dann geht es weiter mit den Rules. Ich lasse ganz bewusst Rule1 von dieser Seite weg, da sie bei mir ziemliches Chaos verursacht. Bei Mehrchannelschaltern werden z.b. die Channel wild durcheinander geschaltet. Außerdem habe ich bei mir das Backlight per Script geschaltet. Es schaltet sich abends an und morgens aus. Das funktioniert mit der Rule auch nicht, da es sich dann bei jedem Tastendruck an- bzw ausschaltet.

Damit der Touch die Relais schaltet, benutze ich folgende Rule von @Dieter_P

rule2 On TXultimate#Action$!Touch do break rule2 + On TXUltimate#Channel=1 do power1 toggle endon rule2 + On TXUltimate#Channel=<xxx> do power1 toggle endon rule2 + On TXUltimate#Channel=5 do power2 toggle endon rule2 + On TXUltimate#Channel=<xxx> do power2 toggle endon rule2 + On TXUltimate#Channel=10 do power3 toggle endon rule2 + On TXUltimate#Channel=<xxx> do power3 toggle endon

Hier im Beispiel für einen 3Ch-Schalter. Wobei ich aber nicht einfach die Channel übernehme, sondern sie selber austeste. Da man sowieso in der Konsole ist, muss man hier nur auf das Touch an der gewünschten Stelle drücken und die Konsole gibt den Channel aus. Den übernehme ich dann in die Rule, hier gekennzeichnet mit dem <xxx>.

Das wars eigentlich auch schon. Der Schalter sollte nun funktionieren.

Update auf Github für cardThermo2 freigegeben

Beschreibung wurde angepasst an die jetzigen Gegebenheiten!
Wenn ich Skript schreibe meine ich immer das Adapter-Skript - nicht das andere 😄

Konfiguration der cardThermo2 im Adapter

Diese unterscheitet sich von der Skriptkonfiguration, daher eine komplette Beschreibung.
Struktur:

Aussehen Feature Probleme Konfiguration Alias Direkt über Datenpunkte Gemeinsame Optionen PageItemerweiterung Aussehen:

image.jpg

Feature: bis zu 8 Heizkreise möglich (z.B. Heizung/Klimaanlage oder Küche/Wohnzimmer/...) unendliche Anzahl an Pageitems (mit Blätterfunktion), das sind die 8 aussen rum und Nr. 9 zwischen dem + und - Pageitems können einem Heizkreis zu geordnet werden (automatisch erzeugt werden bei mehreren Heizkreisen immer einem zugewiesen) Überschriften sind per Heizkreis Die Zeilen ober und unterhalb der Einstelltemperatur sind frei definierbar mit icon, wert, unit Bekannte Probleme leichtes Flackern auf Grund der hübschen Optik - das wird bleiben Mode und Modeset könnten noch inkonsequent sein - in arbeit Konfiguration

Eine komplette Seite sieht im Skript z.B. so aus

Beispiel mit dem ich rumgetestet habe

const ThermoNew: PageType = { type: 'cardThermo2', uniqueName:'main', heading: 'egal wird eh nicht angezeigt', thermoItems:[ {name: 'test1', id:'0_userdata.0.Einzelne_Geräte.Thermostat'}, {name: 'test2', modeList:['aus','kaputt', 'falsch'], modeId:'0_userdata.0.Einzelne_Geräte.Thermostat.MODE' ,iconHeatCycle:'home', iconHeatCycleOffColor:Red, thermoId1:'0_userdata.0.Einzelne_Geräte.Thermostat.ACTUAL', set:'0_userdata.0.Einzelne_Geräte.Thermostat.SET', thermoId2:'0_userdata.0.Einzelne_Geräte.Thermostat.HUMIDITY'}], items:[ {id: 'alias.0.Licht.lights.Gerät_1', filter: 0}, {id: 'alias.0.Licht.lights.Gerät_2', filter: 0}, {id: '0_userdata.0.Einzelne_Geräte.dimmer'}, {id: 'alias.0.NSPanel.allgemein.hue', }, {navigate: true, targetPage: 'fahrplanrouten'}, {id: 'alias.0.NSPanel.allgemein.shutter', filter: 1}, {id: 'alias.0.NSPanel.allgemein.shutter', filter: 1}, {id: 'alias.0.NSPanel.allgemein.shutter', filter: 1} ], }

Alias

Wie gewohnt kann man Aliase (siehe Tabelle) verwenden. Die Role airCondition erzeugt 2 Heizkreise. Die wird eingestellt durch name2, iconHeatCycle2, iconHeatCycleOnColor2 und iconHeatCycleOffColor2. Viele der optionalen Datenpunkte sind drin und werden Heizkreis bezogen als Pageitems hinzugefügt. Fehlende bitte reklamieren.

const Thermo2New: PageType = { type: 'cardThermo2', uniqueName:'Seitenname für interne Verwendung - Pflicht', heading: 'egal wird eh nicht angezeigt', thermoItems:[ { name: 'Das hier ist die Überschrift', id:'0_userdata.0.Einzelne_Geräte.Thermostat', // das hier ist der Channel, Device oder Folder }, ], items:[], } thermoItems enthält Objekte ('{}') die die Heizkreise beschreiben minimum 1 (Liste bzw. Array) id ist der Channel. (Zeichenkette) name ist die Überschrift die angezeigt wird. (Zeichenkette) Ohne dieses wird geschaut ob was im common.name des Channel steht. name2 ist die Überschrift die für eine airCondition verwendet wird. iconHeatCycle2: Überschreibt das Zahlenicon in den PageItems (außen herum) ausschließlich für airCondition iconHeatCycleOnColor2: Überschreibt die Farbe für aktiviert in den PageItems (außen herum) ausschließlich für airCondition iconHeatCycleOffColor2: Überschreibt die Farbe für deaktiviert in den PageItems (außen herum) ausschließlich für airCondition

Der Datenpunkt MODE hat sich verändert, daher bitte unten bei modeList lesen

Direkt über Datenpunkte

Das ist mit Alias nicht mischbar, darf aber natürlich auf die Datenpunkte eines angelegten Channels verweisen.

const Thermo2New: PageType = { type: 'cardThermo2', uniqueName:'Seitenname für interne Verwendung - Pflicht', heading: 'egal wird eh nicht angezeigt', thermoItems:[ { name: 'Das hier ist die Überschrift', set:'0_userdata.0.Einzelne_Geräte.Thermostat.SET', // Der Einstellwert der Heizung thermoId1:'0_userdata.0.Einzelne_Geräte.Thermostat.ACTUAL', // Aktuelle Raumtemperatur (oberer Wert in der Anzeige) thermoId2:'0_userdata.0.Einzelne_Geräte.Thermostat.HUMIDITY', // Aktuelle Luftfeuchtigkeit (unterer Wert in der Anzeige) modeId:'0_userdata.0.Einzelne_Geräte.Thermostat.MODE', // Textfeld unterhalb der Wert - kein Zeichenkettendatenpunkt } ], items:[], } thermoItems enthält Objekte ('{}') die die Heizkreise beschreiben minimum 1 (Liste bzw. Array) name ist die Überschrift die angezeigt wird. (Zeichenkette) set ist der Einstellwert der Heizung - aktuell keine Unterteilung in read/write thermoId1 Aktuelle Raumtemperatur (oberer Wert in der Anzeige) thermoid2 Aktuelle Luftfeuchtigkeit (unterer Wert in der Anzeige) modeId Siehe beschreibung unten zu modeList Gemeinsame Eigenschaften

Hier sind die Eigenschaften beschrieben die zusätzlich zu name, id bzw. name, set angegeben werden können und was sie bedeuten:

Definition

icon?: AllIcons | ''; icon2?: AllIcons | ''; iconHeatCycle?: AllIcons | ''; iconHeatCycleOnColor?: RGB; iconHeatCycleOffColor?: RGB; name?: string; minValue?: number; maxValue?: number; stepValue?: number; power?: string; unit?: string; unit2?: string; onColor?: RGB; onColor2?: RGB; modeList?: string[];

icon: Überschreibt das Standardicon in der 1. Textzeile (Temperatur)
onColor: Überschreibt die Farbe der 1. Textzeile (Temperatur)
unit: Überschreibt die Einheit der 1. Textzeile unnd 2. Textzeile (Temperatur)

icon2: wie oben für Zeile 3 (Luftfeuchtigkeit)
onColor2: wie oben für Zeile 3 (Luftfeuchtigkeit)
unit2: Überschreibt die Einheit der 3. Textzeile (Luftfeuchtigkeit)

iconHeatCycle: Überschreibt das Zahlenicon in den PageItems (außen herum)
iconHeatCycleOnColor: Überschreibt die Farbe für aktiviert in den PageItems (außen herum)
iconHeatCycleOffColor: Überschreibt die Farbe für deaktiviert in den PageItems (außen herum)

minValue: minimale Einstellbare Temperatur (Default: 15) im Admin einstellbar ob 10 = 1 °C oder 10 = 10 °C
maxValue: maximal einstellbare Temperatur (Default: 28) im Admin einstellbar
stepValue: Schritte für +/-. Eine eingetragene 0.1 bedeutet Schritte von 0.1 (Default: 0.5) im Admin einstellbar

power: Das wird aktuell über MODESET benutzt ist da ne 0 ist die anzeige "aus"

im Admin einstellbar: Da gibts auf der 2ten Seite ganz unten eine Option ob man es kompatible zum Skript haben möchte oder natürlich.

modeList: Das denke ich ist noch nicht final und braucht deutlich mehr Text 🙂
modeId bzw. 'MODE' und MODESET arbeiten auf die dieselbe Weise. Der Datenpunkt sollte vom Type number sein und kann im Object common.states verwenden - dann arbeiten das common.states für modeList.
modeList überschreibt common.states und diese überschreibt die Standardmodelist, die im Adapter hinterlegt ist:
Standard Modelist

['OFF', 'AUTO', 'COOL', 'HEAT', 'ECO', 'FAN', 'DRY']

Im Datenpunkt steht z.B. eine 0 dann wird OFF angezeigt, steht dort eine 3 wird HEAT angezeigt (die werden übersetzt).
Wenn das in den common.states des Datenpunktes genauso steht gilt dort das gleich. Ebenso in der modeList.
Im Skript sieht dass dann etwas regional angepasst so aus:

modeList: ["Aus'm", "Automat", "Kühl'n", "Heiz'n", "Sparn", "Puste", "Trockn"],

Ergänzend wurde TargetMode und CurrentMode aufgeteilt - siehe Alias Tabelle - das ist noch nicht final - Da muß am nächsten WE noch etwas rumdiskutiert werden - ich würde gerne den CurrentMode unterhalb der Temperatur anzeigen mit inaktiv, idle, heizen, kühlen
Wenn MODE nicht angegeben ist wird es durch MODESET ersetzt.
MODE: kann vom common.type = 'string' sein, dann wird einfach geschrieben was im Datenpunkt steht.

PageItemerweiterung

Für die Pageitems gibt es eine neue Eigenschaft die aktuell aber nur für die cardThermo2 von belang ist:

items:[ {id: 'alias.0.Licht.lights.Gerät_1', filter: 0}, ],

filter: Ist es definiert wird das Pageitem nur angezeigt, wenn der entsprechende Heizkreis aktiv ist. Zählung beginnt bei 0 (number).
Wenn eine airCondition per 'id' hinzugefügt wird erhöht sich der index nach der airCondition um 1.

Der Adapter unterstützt jetzt auch Platzhalter PageItems - durch id:'delete' oder id:'empty' werden diese definiert.

Das ist noch nicht in der aktuellen Branch. Wenn ihr trotzdem testen wollt der Installationslink wäre dieser Alpha-Test

Schlußanmerkung - die rollen für aircondition können sich noch ändern - die scheinen sich von thermostat zu unterscheiden also besser da nachgucken.

Dank an @Armilar, @TT-Tom

@jogibear9988 hi ja jezt geht wieder alles was ich zumindest so auf den ersten blick sehe vielen danke vorab

@gombersiob Hallo, das war ein guter Tipp, mit dem Vaga komme ich jetzt schon mal auf den WR und kann einzelne Register auslesen. Ich specke jetzt die bei den Eingang und Holding Register ab...👍

@foggysolar sagte in Installtion FFMPEG:

daher werde ich das einfach wieder weglassen oder warten bis es da was anderes gibt

Da gibt's nix anderes. Das ist der Weg, den der Image-Maintainer vorgesehen hat.

Am einfachsten erzeugt man einen ioBroker-Container eh über Docker-Compose (bei Portainer heißt das "Stacks" und bei Synology "Projekt").

Dazu im Container-Manager ein neues "Projekt" erstellen.
Der Pfad dient nur dazu, das Projekt (bzw. dessen Einstellungen) zu speichern. Das kannst Du auf ein beliebiges Volume legen.
Als Quelle wählst Du "docker-compose.yml erstellen".

19846aac-e660-4603-aa36-f82ef1064576-grafik.png

In den Editor fügst Du dann das hier ein (ggf. an die eigenen Gegebenheiten anpassen):

services: iobroker: container_name: ioBroker image: buanet/iobroker:latest hostname: iobroker network_mode: "host" volumes: - /volume1/Docker/ioBroker:/opt/iobroker environment: PACKAGES: "nano ffmpeg" AVAHI: "true" restart: unless-stopped

Das kann man auch im Nachhinein noch machen. Deine Daten liegen ja (hoffentlich) auf Deiner Synology.
Also einfach den alten Container weg und über das Projekt einen neuen hochziehen.

Oder Du gehst halt hin und änderst wie bereits vorgeschlagen den Inhalt der Umgebungsvariablen PACKAGES und hängst da noch ein ffmpeg dran.

214ef1a6-22a6-4ae1-a572-cc234512b425-grafik.png

P.S. (etwas OT): Wie bereits an anderer Stelle schon mal erwähnt: Ich habe "SiYuan" als Container laufen und habe mir dort einen ganzen Katalog an Docker-Compose Vorlagen angelegt. Man weiß ja nie, was man mal brauchen kann 😉
Damit kann man sich z.B. auch eine schöne kleine Knowledgebase anlegen. Wichtige Linux Befehle, Tasmota Commands und was man im Laufe der Zeit sonst noch alles braucht.

services: main: image: b3log/siyuan container_name: SiYuan command: ['--workspace=/siyuan/System/', '--accessAuthCode=<hier das persönliche Passwort>'] ports: - "6806:6806" volumes: - /volume1/Docker/SiYuan:/siyuan/System restart: unless-stopped environment: - TZ=Europe/Berlin - PUID=1000 - PGID=1000

@boeck

Die Datei heißt /opt/AdGuardHome/AdGuardHome.yaml

Edit
Man sollte den Thread auch bis zum Ende lesen. @Dolomiti hat ja schon vor Stunden die Antwort gegeben.

@skvarel
danke für die Tips und Anregungen.

Ich habe bisher eine Vivotek und eine Instar über Synology in der VIS,
möchte aber auch noch ein paar ESP32-CAMs einfügen

Schöne Woche

@quinti
Beispiel mit HTML Widget

8a8e32f0-dce3-4b56-b8a9-512ee39fa30f-image.png

src muss man anpassen und skript hinzufügen

<div id="fadebox" class="fade-container"> <img src="https://192.168.178.170/download/bilder/ffn.png" class="fade-img img1 active"> <img src="https://192.168.178.170/download/bilder/NDR2.png" class="fade-img img2"> </div> <style> #fadebox { position: relative; width: 100%; height: 100%; overflow: hidden; } #fadebox img { position: absolute; top: 0; left: 0; width: 100%; height: 100%; opacity: 0; transition: opacity 2s ease-in-out; /* Dauer = 1 Sekunde */ } #fadebox img.active { opacity: 1; } </style>

a01d02d1-c3ec-4e5f-a980-16fccfc058c7-image.png

let state = 0; setInterval(() => { state = 1 - state; // toggle 0/1 document.querySelector(".img1").classList.toggle("active", state === 0); document.querySelector(".img2").classList.toggle("active", state === 1); }, 4000); // alle 10 Sekunden

vis-html-img-faden.gif

@crunchip sagte in Schreibrechte auf grafana.ini in Docker:

@legro ich verstehe den ganzen "Aufriss" immer noch nicht. ..

Richtig! Tut mir leid, ich vergaß ..

Nie verzagen, crunchip fragen.😖

@azzkikrboy
Das sieht bei dir so aus, als ob aus irgendeinem Grund das Script nicht mehr läuft oder aber e3dc-rscp Adapter keine Verbindung mehr hat.
Setze mal die Objekt-ID 0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_DebugAusgabe = true
Ich benötige das LOG File in dem Moment, wo das wieder passiert.

@maxclaudi du ich speise jenseits der 2MWh im Jahr ein, ich habe kein Problem mit zu wenig über Tag daher ist der ByPass für mich mehr oder weniger nutzlos und ich schone mein Relais. Ob mit oder ohne Last es bleibt eine mechanische Komponente die, je weniger man sie nutzt, entsprechend länger hält.

In einem anderen Usecase sicherlich anders, dann würde ich es ebenfalls so machen und habe es in der Vergangenheit auch mal in der Regelung gehabt, bzw ist noch drin aber da er auf Dauer aus ist, liegt der Subflow halt Tod in der Ecke.

Daher alles gut und wenn man weiß was man tut ist es ja auch mehr als okay 👍🏼 Mache es z.B. bei Relais im ACE so, das ich nur zweimal am Tag schalte. Morgens auf Eingang, abends auf Ausgang und fertig.

Schaut dann so aus in NodeRed

Screenshot_20250826-203912.png

@laser sagte in Victron Photovoltaik Anlage Daten für ioBroker auslesen!:

um den Ladestrom eines kleinen Laders zu verstellen.

aber warum willst du das überhaupt?

@laser sagte in Victron Photovoltaik Anlage Daten für ioBroker auslesen!:

Damit ein Akku nicht schon um 11 Uhr voll ist.

was ist daran so schlimm?

@marcel-drzal

dpkg ist aber das Paketmanagement auf OS-Ebene. Da ist also eine Etage tiefer schon was schief.

sudo apt update

sagt?

Hallo Gemeinde
Ich verfolge diesen Thread schon länger.
Habe erfolgreich einen Waveshare RS485 to LAN Converter an meinen SOFAR HYD20KTL-3PH angeschlossen.
Wenn ich den modbus Adapter konfiguriere, bekomme ich genau das erste mal beim Starten des Adapters Daten.
Nachher ist Stille.
Aufgefallen ist mir, dass "1156-Frequency_Grid" solange funktionierte, wo es an erster Stelle stand und bevor ich weitere IDs rein editierte.

Log:

modbus.0 2025-08-26 18:45:12.714 info Disconnected from slave 192.168.88.101 modbus.0 2025-08-26 18:45:12.713 debug Closing client on purpose. modbus.0 2025-08-26 18:45:11.665 debug Cleaning up request fifo. modbus.0 2025-08-26 18:45:11.665 debug Clearing timeout of the current request. modbus.0 2025-08-26 18:45:11.664 debug Socket closed with error modbus.0 2025-08-26 18:45:09.642 debug [DevID_1/holdingRegs] Poll address 1544 - -383 registers modbus.0 2025-08-26 18:45:09.642 debug [DevID_1] Poll start --------------------- modbus.0 2025-08-26 18:45:09.641 info Connected to slave 192.168.88.101

Das "Socket closed with error" gefällt mir nicht 😉
Ich kenne mich mit dem Thema Modbus nicht so gut aus. Ich vermute eine Fehlkonfiguration.
Oder benutzt ihr gar einen anderen Adapter?

Hier die JSON des Adapters:

{ "_id": "system.adapter.modbus.0", "type": "instance", "common": { "name": "modbus", "version": "6.3.2", "titleLang": { "en": "ModBus", "de": "ModBus", "ru": "ModBus", "pt": "ModBus", "nl": "ModBus", "fr": "ModBus", "it": "ModBus", "es": "ModBus", "pl": "ModBus", "uk": "ModBus", "zh-cn": "ModBus" }, "desc": { "en": "ModBus connection Slave or Master", "de": "ModBus Verbindung Slave oder Master", "ru": "ModBus соединение Slave или Master", "pt": "Conexão ModBus Escravo ou Mestre", "nl": "ModBus-verbinding Slave of Master", "fr": "Connexion ModBus Esclave ou Maître", "it": "Connessione ModBus Slave o Master", "es": "Conexión ModBus Slave o Master", "pl": "Połączenie ModBus Slave lub Master", "zh-cn": "ModBus连接从站或主站" }, "authors": [ "bluefox <dogafox@gmail.com>" ], "licenseInformation": { "license": "MIT", "type": "free" }, "platform": "Javascript/Node.js", "mode": "daemon", "loglevel": "info", "messagebox": true, "icon": "modbus.png", "keywords": [ "ModBus" ], "enabled": true, "extIcon": "https://raw.githubusercontent.com/ioBroker/ioBroker.modbus/master/admin/modbus.png", "readme": "https://github.com/ioBroker/ioBroker.modbus/blob/master/README.md", "type": "protocols", "plugins": { "sentry": { "dsn": "https://0c7b6d766435448cbf4908f615efe683@sentry.iobroker.net/84" } }, "compact": true, "connectionType": "local", "dataSource": "poll", "tier": 2, "eraseOnUpload": true, "adminUI": { "config": "materialize" }, "dependencies": [ { "js-controller": ">=5.0.19" } ], "globalDependencies": [ { "admin": ">=5.1.28" } ], "messages": [ { "condition": { "operand": "and", "rules": [ "oldVersion<5.0.0", "newVersion>=5.0.0" ] }, "title": { "en": "Objects IDs will change with update!", "de": "Objekt-IDs ändern sich mit dem Update!", "ru": "ID объектов изменятся с обновлением!", "pt": "Os IDs de objetos mudarão com a atualização!", "nl": "Object-ID's veranderen met de update!", "fr": "Les ID d'objets changeront avec la mise à jour !", "it": "Gli ID degli oggetti cambieranno con l'aggiornamento!", "es": "¡Los ID de los objetos cambiarán con la actualización!", "pl": "Identyfikatory obiektów zmienią się wraz z aktualizacją!", "zh-cn": "对象 ID 会随着更新而改变！" }, "text": { "en": "This update makes sure that all space characters are correctly replaced by underscores on Object-IDs. This means that they will change after this update if you use more then one space in the names of your registers. You need to manually delete the old Object names.", "de": "Dieses Update stellt sicher, dass alle Leerzeichen bei Objekt-IDs korrekt durch Unterstriche ersetzt werden. Das bedeutet, dass sie sich nach diesem Update ändern, wenn mehr als ein Leerzeichen im Namen der Register verwendet wird. Alte Objektnamen müssen manuell gelöscht werden.", "ru": "Это обновление обеспечивает правильную замену всех символов пробела символами подчеркивания в идентификаторах объектов. Это означает, что они изменятся после этого обновления, если вы используете более одного пробела в именах ваших регистров. Вам необходимо вручную удалить старые имена объектов.", "pt": "Essa atualização garante que todos os caracteres de espaço sejam substituídos corretamente por sublinhados em IDs de objeto. Isso significa que eles serão alterados após esta atualização se você usar mais de um espaço nos nomes dos seus registros. Você precisa excluir manualmente os nomes de objetos antigos.", "nl": "Deze update zorgt ervoor dat alle spatietekens correct worden vervangen door onderstrepingstekens op Object-ID's. Dit betekent dat ze na deze update zullen veranderen als u meer dan één spatie gebruikt in de namen van uw registers. U moet de oude objectnamen handmatig verwijderen.", "fr": "Cette mise à jour garantit que tous les espaces sont correctement remplacés par des traits de soulignement sur les ID d'objet. Cela signifie qu'ils changeront après cette mise à jour si vous utilisez plus d'un espace dans les noms de vos registres. Vous devez supprimer manuellement les anciens noms d'objet.", "it": "Questo aggiornamento assicura che tutti i caratteri spazio siano sostituiti correttamente da caratteri di sottolineatura sugli ID oggetto. Ciò significa che cambieranno dopo questo aggiornamento se utilizzi più di uno spazio nei nomi dei tuoi registri. È necessario eliminare manualmente i vecchi nomi degli oggetti.", "es": "Esta actualización garantiza que todos los caracteres de espacio se reemplacen correctamente por guiones bajos en los ID de objetos. Esto significa que cambiarán después de esta actualización si usa más de un espacio en los nombres de sus registros. Debe eliminar manualmente los nombres de objetos antiguos.", "pl": "Ta aktualizacja zapewnia, że wszystkie znaki spacji są poprawnie zastępowane podkreśleniami w identyfikatorach obiektów. Oznacza to, że zmienią się one po tej aktualizacji, jeśli użyjesz więcej niż jednej spacji w nazwach swoich rejestrów. Musisz ręcznie usunąć stare nazwy obiektów.", "zh-cn": "此更新确保所有空格字符都正确替换为对象 ID 上的下划线。这意味着如果您在寄存器名称中使用超过一个空格，它们将在此更新后更改。您需要手动删除旧的对象名称。" }, "level": "warn", "buttons": [ "agree", "cancel" ] } ], "installedFrom": "iobroker.modbus@6.3.2", "installedVersion": "6.3.2", "host": "ioBroker" }, "native": { "params": { "type": "tcp", "bind": "192.168.88.101", "port": "8899", "comName": "", "baudRate": 9600, "dataBits": 8, "stopBits": 1, "parity": "none", "deviceId": 1, "timeout": 5000, "slave": 0, "poll": "5000", "recon": "4000", "keepAliveInterval": 0, "maxBlock": 100, "maxBoolBlock": 128, "multiDeviceId": false, "pulsetime": "2000", "waitTime": "500", "disInputsOffset": 10001, "coilsOffset": 1, "inputRegsOffset": 30001, "holdingRegsOffset": 40001, "showAliases": false, "directAddresses": false, "doNotIncludeAdrInId": false, "preserveDotsInId": false, "round": 2, "doNotRoundAddressToWord": true, "doNotUseWriteMultipleRegisters": false, "onlyUseWriteMultipleRegisters": true, "writeInterval": 0, "readInterval": 0 }, "disInputs": [], "coils": [], "inputRegs": [], "holdingRegs": [ { "address": 1544, "name": "SOC_Bat1", "description": "", "unit": "%", "type": "uint16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1156, "name": "Frequency_Grid", "description": "", "unit": "Hz", "type": "uint16be", "len": 1, "factor": "0.01", "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1157, "name": "ActivePower_Output_Total", "description": "", "unit": "kW", "type": "int16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1160, "name": "ActivePower_PCC_Total", "description": "", "unit": "kW", "type": "int16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1198, "name": "ActivePower_PV_Ext", "description": "", "unit": "kW", "type": "int16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1199, "name": "ActivePower_Load_Sys", "description": "", "unit": "kW", "type": "int16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1284, "name": "ActivePower_Load_Total", "description": "", "unit": "kW", "type": "int16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 }, { "address": 1542, "name": "Power_Bat1", "description": "", "unit": "kW", "type": "int16be", "len": 1, "factor": 1, "offset": 0, "formula": "", "role": "value", "room": "", "poll": true, "wp": "", "cw": "", "isScale": "", "deviceId": 1, "_address": 0 } ] }, "protectedNative": [], "encryptedNative": [], "notifications": [], "instanceObjects": [ { "_id": "", "type": "meta", "common": { "type": "meta" }, "native": {} }, { "_id": "info", "type": "channel", "common": { "name": "Information" }, "native": {} }, { "_id": "info.connection", "type": "state", "common": { "role": "indicator.connected", "name": "If master connected", "type": "boolean", "read": true, "write": false, "def": false }, "native": {} } ], "objects": [], "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1756223306613 }

Habt ihr einen Rat für mich?

@OliverIO
Meinem "kleinen" llama Modell waren der Objektpfad sowie die Bezeichnung nicht ausreichend. Ein Pfad wie shelly.0.SHBDUO-1#XXXXXX.lights.Switch konnte nicht passend interpretiert werden. Auch die boolean Werte und Beschreibung wurde oft falsch interpretiert.
Deshalb habe ich diese in über die Datenpunkteinstellungen mit Beschreibung, Destination, Wert Boolean true und false, Unit, ... die Möglichkeit zum Definieren erstellt. Daraus wurde dann zb. Wohnzimmer Stehlampe ein, Temperatur Wohnzimmer 26°C oder Gute Nacht Geschichte Kinderzimmer.
Der Datenpunktpfad, Zeitstempel und die entstandene Beschreibung wurde dann an das Ollama Embedding Modell übergeben und in die Datenbank geschrieben. Bei einer Abfrage wurden die gespeicherten Daten dann abgefragt. Selbstverständlich würde sich dies auch mit Funktionen und Räume vordefinieren lassen.

Das Resultat daraus war, dass ich viel präzisere Antworten erhalten habe und auch ein kleines Modell diese relativ schnell verarbeiten konnte.

In Verbindung mit n8n könnte ich mir vorstellen, dass kurze Prompts wie:
Schalte die Stehlampe im Wohnzimmer ein. Direkt über ein Lokales Modell ablaufen könnte.
Größere und längere Anfragen wären mit einem externen Modell abzuarbeiten welchem die Daten zwar für den Prompt zur Verfügung gestellt bekommt, allerdings wären diese immer noch Lokal abgespeichert und nicht ausgelagert.

@bigchris Ja, so geht es nicht. Man kann einen default setzen, oder ihn abhängig vom Wert des DPs machen oder eines anderen.
Beispiele gibt es
https://mcuiobroker.gitbook.io/jarvis-infos/jarvis-v3/besonderheiten-v3/geraet/label

font-size

Es gibt leider keinen Label-Style. Man hat nur die Möglichkeit den Body, also die ganze Zeile zu beeinflussen.
Dies setzt man dann in den body-style.
01e77b63-f345-4930-b98f-bbe5afc01e31-image.png

https://mcuiobroker.gitbook.io/jarvis-infos/jarvis-v3/besonderheiten-v3/geraet/body-stil

Übersicht für die Felder im Gerät
https://mcuiobroker.gitbook.io/jarvis-infos/jarvis-v3/besonderheiten-v3/geraet/eingabewerte-fur-die-gerate-dp-state-felder

Möchte man dennoch nur den Label in der Größe verändern, kann man dies mittels CSS-Eintrag unter den Styles / CSS machen.

/* v3.1 */ /* nth-child(x) -> Zeile der StateList */ .jarvis-widget-20f32ee7-60f1-448c-9aa8-851958a44fec .jarvis-StateListItem-Body:nth-child(2) { font-size: 35px; }

@michael-roling sagte in Test Adapter telegram-menu v.1.6.x:

@deta mach bitte ein Issue auf mit allen Informationen usw. Dann schaue ich mir das an

aufgemacht

@beowolf sagte in OpenDTU-onBattery Blockly DPL Ein/Aus:

Das Ziel ist es, das ich bzw. meine Frau (WAF ist wichtig) mittags wenn die Sonne schön scheint, den DPL ausschalten kann. Also alles, was von den Panels kommt soll zu 100% in das Hausnetz gehen.

Das was ich festgestellt hatte ist, wenn der Herd mittags an ist, ist das ja keine konstante Last. Die Kochplatten gehen an und wieder aus usw.. In der Zeit regelt sich der DPL um den Verstand.

Deshalb brauche in eine Kachel (iQontrol) um mit einem Fingertipp den DPL auszuschalten.

Mit dem Blockly was ich oben eingestellt hatte funktioniert es jetzt.

Ich teste gleich mal dein geändertes.

Hat mir keine Ruhe gelassen und denke, dass ich nun die Lösung für "solarbetriebene" Wechselrichter habe 👍 🙂

edit besser aufbereitet:

OpenDTU‑OnBattery: DPL per ioBroker ein/aus (Laien‑HowTo)

Dieses HowTo erklärt, wie Dynamischen Power Limiter (DPL) von OpenDTU‑OnBattery über ioBroker/MQTT im Alltag als einfacher Ein/Aus‑Schalter benutzt wird.
Der Leitfaden ist bewusst Schritt‑für‑Schritt und für Einsteiger geschrieben.

Kurz über DPL: DPL regelt die Wechselrichterleistung so, dass Netzbezug/Ziel eingehalten wird. Per „Mode“ kann zwischen Normalbetrieb (DPL regelt) und Vollgas/Bypass (volle PV‑Leistung innerhalb des eingestellten Limits) umschalten.

Was man braucht

OpenDTU‑OnBattery (mit aktiviertem DPL)

MQTT‑Broker (z. B. Mosquitto oder ioBroker MQTT‑Adapter im Server/Broker‑Modus)

ioBroker mit zwei MQTT‑Adapter‑Instanzen:

Server/Broker – empfängt/wartet auf MQTT‑Nachrichten Client/Subscriber – abonniert Topics und kann Befehle senden (publish)

Hinweis: Die Anleitung funktioniert z. B. mit ioBroker MQTT‑Adapter v6.1.2.

Schritt 1 – Broker/Server einrichten

In ioBroker eine MQTT‑Adapter‑Instanz anlegen. Unter Instanzen → Verbindung den Modus „Server/Broker“ wählen. Standard‑Ports/Einstellungen sind ausreichend. Benutzer/Passwort merken.

Alternativ kann ein externer Broker (z. B. Mosquitto) genutzt werden.

Schritt 2 – OpenDTU‑OnBattery verbinden

In OpenDTU‑OnBattery die MQTT‑Client‑Einstellungen so setzen, dass sie zum Broker passen (IP/Port/Benutzer/Passwort).

Nach erfolgreicher Verbindung erscheinen in ioBroker unter der Server‑Instanz die ersten Datenpunkte.

Beispielpfad: mqtt.0.<baseTopic>... (die Zahl 0 ist die Instanz‑Nummer) <baseTopic> ist das Grundtopic, z. B. solar/1121XXXXXX

Schritt 3 – ioBroker‑Client zum Steuern anlegen

Zweite MQTT‑Adapter‑Instanz in ioBroker anlegen.

Unter Instanzen → Verbindung den Modus „Client/Subscriber“ wählen.

Verbindungseinstellungen (IP/Port/Benutzer/Passwort) müssen zum Broker/Server aus Schritt 1 passen.

Starten. Kurz darauf tauchen unter dieser Instanz die gleichen Topics auf – hier kann man schreiben.

Beispielpfad: mqtt.1.<baseTopic>... (Instanz‑Nummer 1)

Schritt 4 – DPL in OpenDTU aktivieren

In der OpenDTU‑Weboberfläche den DPL einschalten und konfigurieren (inkl. oberem Limit, also der maximalen Einspeiseleistung). Erst wenn DPL aktiv ist, reagiert OpenDTU auf „Mode“‑Befehle.

Schritt 5 – Die wichtigen Datenpunkte

Immer die Client/Subscriber‑Instanz (z. B. mqtt.1) benutzen, wenn man schreiben will.

Lesen (aktueller Modus):

mqtt.<clientInst>.<baseTopic>.powerlimiter.status.mode Zeigt 0/1/2. Nur sinnvoll, wenn DPL aktiv ist.

Schreiben (Modus setzen):

mqtt.<clientInst>.<baseTopic>.powerlimiter.cmd.mode Hier schreibt man 0 oder 2 (siehe unten). Wenn noch nie gesetzt, steht der State oft auf (null) → normal.

Oberes Leistungs‑Limit (zum Nachlesen):

mqtt.<clientInst>.<baseTopic>.powerlimiter.status.upper_power_limit Gibt an, wie viel Watt maximal eingespeist werden. Der Wert wird in der OpenDTU‑Weboberfläche eingestellt.

Die drei Modi (zur Einordnung)

0 – Normalbetrieb: DPL regelt gemäß den Einstellungen.

1 – WR aus: Wechselrichter wird abgeschaltet (für diesen Guide nicht nutzen).

2 – Vollgas/Passthrough: Volle PV‑Leistung bis zum eingestellten oberen Limit, keine DPL‑Regelung während Mode:2.

Solar‑WR (ohne Batterie): genau der gewünschte „Bypass“. Batterie‑WR: benötigt funktionierende VE.Direct‑Daten; wenn inaktiv/alt → WR kann abschalten.

Merke: Wir nutzen für die einfache Ein/Aus‑Logik nur 0 (Normal) und 2 (Bypass/Vollgas).

Schritt 6 – Einfache Ein/Aus‑Steuerung (Boolean)

In ioBroker einen booleschen Datenpunkt anlegen, z. B. DPL_Override:

true → schreibe 0 nach ...powerlimiter.cmd.mode
(DPL normal aktiv – geregelt) false → schreibe 2 nach ...powerlimiter.cmd.mode
(Vollgas/Bypass – maximale PV bis zum oberen Limit)

Damit hat man einen Schalter, der DPL im Alltag bequem zwischen Regelung und Vollgas umschaltet.

Wichtige Hinweise

DPL muss dauerhaft aktiv sein – sonst ignoriert OpenDTU den Mode. Web‑UI geändert? Sobald etwas in der OpenDTU‑Weboberfläche geändert wird, setzt OpenDTU den Mode sofort auf 0 zurück. Neustart (WR oder OpenDTU): Der Mode ist danach immer 0 (Sicherheitsverhalten). cmd.mode zeigt (null), wenn noch nie etwas geschrieben wurde → kein Fehler.

Fehlersuche (Quick‑Check)

Mode‑Schreiben ohne Wirkung?
→ Ist DPL aktiv? Richtiges Topic/Instanz verwendet (cmd statt status)? Wert 0/2 als Integer geschrieben? Nach Web‑UI Bedienung wieder Regelung aktiv?
→ Gewollt: Web‑Änderungen setzen Mode auf 0 zurück. Nach Stromausfall plötzlich geregelt statt Vollgas?
→ Nach Neustart stets Mode 0. Optional Automatisierung bauen, die deinen Wunsch‑Mode nach Boot setzt.

Glossar (kurz)

Broker/Server: Zentrale MQTT‑Vermittlung (Mosquitto oder ioBroker‑Adapter im Server‑Modus). Client/Subscriber: Verbindet sich zum Broker, liest/schreibt Topics (zweite ioBroker‑Instanz). Topic: Pfad/Adresse einer Nachricht, z. B. solar/1121XXXXXX/powerlimiter/... BaseTopic: Dein Geräteteil des Pfades, z. B. solar/1121XXXXXX.

Checkliste

Broker/Server läuft (Mosquitto oder ioBroker MQTT im Server‑Modus) OpenDTU‑OnBattery als MQTT‑Client verbunden Zweite ioBroker‑Instanz als Client/Subscriber verbunden DPL in OpenDTU aktiviert, oberes Limit gesetzt status.mode lesen, cmd.mode schreiben Boolean‑Schalter: true → 0 (Normal), false → 2 (Bypass) Web‑UI/Neustart setzt Mode 0 → ggf. Auto‑Set per ioBroker

Fertig!
So lässt sich DPL mit ioBroker einfach als Ein/Aus‑Schalter betreiben – laienfreundlich und robust im Alltag.

Denke das ist die beste Lösung.
Macht genau und schnell, was wir möchten.
Viel Spaß 😉

@jrbwh Danke für die Recherche und Rückmeldung!
Ich versuchs mir zu merken bzw. ans Readme nächstesmal zu denken.