@saarlanduhu
Um zu verhindern, dass über DHCP neue IP-Adressen zugewiesen werden, kannst Du in der FB die Adresse reservieren.
Unter Heimnetz/Netzwerk/Netzverbindungen geht Du bei dem betroffenen links auf das Bleistift:
dort dann das Häkchen setzen:
Oben auf der Seite kannst Du auch einen eindeutigen Gerätenamen vergeben:
@joergh
Jetzt hab ich's verstanden
vielen Dank für Deine Geduld
@ilovegym
Der Tipp mit dem Blockly war zielführend, danke dafür 
@gombersiob
Die Quelle finde für die Register finde ich nicht mehr. Aber hier sind die Einträge aus meiner Modbus-Instanz zum DTSU666:
Die von Sungrow ausgelieferten DTSU666 haben wohl eine Sungrow-spezifische Firmware, sodass die entsprechenden Register direkt über den Modbus verfügbar sind. Es gibt zum DTSU noch mehr Register, die z.B. die Ströme der einzelnen Phasen anzeigen.
Näheres dazu hier:
https://www.photovoltaikforum.com/thread/158136-sungrow-sammelthread-produktmanagement/?postID=2697060#post2697060
Nur um Missverständnisse zu vermeiden: Nach meinem Verständnis beschreibt der Hausverbrauch die Leistung, die im Haus "verbraucht" wird. Der Wert ist daher immer positiv. Der Hausverbrauch kann mit dem Standardaufbau des Systems nicht direkt gemessen werden (Pfad 4 in der physikalischen Darstellung). Register 13007 könnte einen entsprechend berechneten Wert haben.
Register 5600 zeigt eindeutig den vorzeichenbehafteten Leistungsfluss vom/zum Netz (Pfad 3)
Die in meinen System angezeigten Regsiterwerte lassen den Schluss zu, dass Register 5600 eher 13009 mit umgekehrten Vorzeichen entspricht.
Wenn Register 13009 negativ ist (5600 positiv), entspräche das Strompfad 10, positive Werte von 13009 (5600 negativ) dementsprechend Strompfad 9. Der jeweils andere ist dann natürlich 0.
Bleiben immer noch die Strompfade 7 und 8 zu klären, für die es ja eine Messung im WR geben müsste...
Hast Du eine verständliche Erklärung zu den Bits 4 und 7?
Für alle, die vor dem gleichen Problem stehen, hier eine Lösung zur Ermittlung des Tokens:
'use strict'
// Token für Kamera 3 ermitteln aund speichern
schedule("*/30 * * * *", async () => {
httpPost('http://192.168.22.42/api.cgi?cmd=Login', '[{ "cmd":"Login", "param":{ "User":{ "Version": 0, "userName":"YYYYYY", "password":"XXXXXXXX"}}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
let ergebnis=('' + response.data)
let position=0;
let suche = ergebnis.indexOf('"name" : "', position);
//Hier ist noch zu prüfen, on das Token IMMER genau 15 Zeichen lang ist. Ggf. muss der Filter angepasst werden!
let Token = ergebnis.slice(suche+10, suche + 25);
setState('0_userdata.0.Token_Kamera3', Token, true);
});
});
offensichtlich kommen die Daten der beiden Sensoren in zwei Arrays, von denen nur das erste vom Sonoff-Adapter ausgewertet wird.
Lösung (bzw. Workaround):
Wenn der Adapter sich nicht um dieses zweite Array kümmert, bietet man ihm die die Werte des zweiten Sensors eben mittels des Tasmota-Scripts einfach im ersten Array an.
Folgendes Tasmota-Script bringt das gewünschte Ergebnis:
>D
var1=0
var2=0
var3=0
var4=0
>B
->sensor53 r
>T
var1=EMH#serialnr
var2=EMH#Bezug
var3=EMH#Einspeisung
var4=EMH#Leistung
>J
;MQTT
,"":{"Zählernummer":%var1%}
,"":{"Bezug":%var2%}
,"":{"Einspeisung":%var3%}
,"":{"Leistung":%var4%}
>M 2
+1,3,m,0,9600,SDM120,1,1,0104000C,01040048,0204000C,02040048
1,010404ffffffff@i0:1,Leistung Klima,W,Leistung_1,2
1,010404ffffffff@i1:1,Verbrauch Klima,kWh,Verbrauch_1,2
1,=h ---------------------------------
1,020404ffffffff@i2:1,Leistung WaMa,W,Leistung_2,2
1,020404ffffffff@i3:1,Verbrauch WaMa,kWh,Verbrauch_2,2
1,=h ---------------------------------
+2,5,s,0,9600,EMH,
2,77070100600100FF@#,Zaehlernummer,,serialnr,16
2,77070100010800FF@1000,Bezug,kWh,Bezug,1
2,77070100020800FF@1000,Einspeisung, kWh,Einspeisung,1
2,77070100100700FF@1,Leistung,W,Leistung,1
#
und hier die Datenpunkte im Sonoff-Adapter:
Jetzt kümmere ich mich mal um die Konstruktion eines Gehäuses für den 3D-Drucker, baue das Teil dann zusammen und nehme es in den Produktivbetrieb.
Wenn Interesse besteht, stelle ich Druckdatei und Schaltplan hier ein.
@oliverio
danke für den Tipp, habs so umgesetzt.
Hier mal für alle die ähnliches vorhaben zusätzlich der Code mit dem dann auf Grundlage des ermittelten Tokens die Steuerbefehle abgesetzt werden.
Auch in dem Code gibt es sicher Optimierungsmöglichkeiten, aber er funktioniert
'use strict'
// Token für Kamera 3 ermitteln aund speichern
schedule("*/30 * * * *", async () => {
httpPost('http://192.168.22.42/api.cgi?cmd=Login', '[{ "cmd":"Login", "param":{ "User":{ "Version": 0, "userName":"XXX", "password":"YYY"}}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
let ergebnis = JSON.parse(response.data);
let Token = ergebnis.find(el=>el.cmd=="Login").value.Token.name
setState('0_userdata.0.Token_Kamera3', Token, true);
});
});
// Kamara Links
on({id: '0_userdata.0.Kamera3_Links', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Left", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Links', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
// Kamara Rechts
on({id: '0_userdata.0.Kamera3_Rechts', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Right", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Rechts', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
// Kamara Auf
on({id: '0_userdata.0.Kamera3_Auf', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Up", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Auf', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
// Kamara Ab
on({id: '0_userdata.0.Kamera3_Ab', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Down", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Ab', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
Hallo zusammen,
ich habe meine Elektroverteilung über einen ESP8266 an IOB angebunden. In der Verteilung liefern ein Hichi IR TTL Lesekopf Daten der "modernen Messeinrichtung" sowie zwei SDM120 Daten von zwei einzelnen Stromkreisen. In Tasmota werden alle Daten korrekt angezeigt:
Die oberen beiden Blöcke sind die beiden SDM120 (der 2. ist noch neu, daher kein Verbrauchswert)
Der untere Block zeigt die Daten des Hichi (Hier stehen keine Werte, da der Kopf derzeit nicht an der Messeinrichtung hängt)
Im Sonoff Adapter werden folgende Datenpunkte angelegt:
Wie zu sehen ist, werden außer den "amtlich angelegten" Datenpunkten nur die Datenpunkte des Hichi angelegt.
Die Datenpunkte der beiden SDM120 fehlen obwohl sie gem. Log übertragen werden (Zeile 20):
2025-06-09 07:10:17.634 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Time - 1
2025-06-09 07:10:17.634 - debug: sonoff.0 (1242) process task: {"type":"addObject","id":"sonoff.0.DVES_C06A45.Time","data":{"_id":"sonoff.0.DVES_C06A45.Time","common":{"type":"string","role":"state","read":true,"write":true,"name":"DVES_C06A45 Time"},"native":{},"type":"state"},"cbArg":"2025-06-09T06:10:17"}
2025-06-09 07:10:17.634 - debug: sonoff.0 (1242) Set state after task: sonoff.0.DVES_C06A45.Time
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Uptime - 2
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.UptimeSec - 3
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Heap - 4
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.SleepMode - 5
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Sleep - 6
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.LoadAvg - 7
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.MqttCount - 8
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_AP - 9
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_SSId - 10
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_BSSId - 11
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Channel - 12
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Mode - 13
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_RSSI - 14
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Signal - 15
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_LinkCount - 16
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Downtime - 17
2025-06-09 07:10:17.639 - debug: sonoff.0 (1242) Client [DVES_C06A45] received: tele/tasmota_C06A45/SENSOR = {"Time":"2025-06-09T06:10:17","":{"Spannung_Klima":227.00,"Strom_Klima":0.00,"Leistung_Klima":0.00,"Verbrauch_Klima":737.81,"Spannung_WaMa":226.72,"Strom_WaMa":0.03,"Leistung_WaMa":0.46,"Verbrauch_WaMa":0.00},"":{"Bezug":0.0,"Einspeisung":0.0,"Leistung":0}}
2025-06-09 07:10:17.639 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Time - 18
2025-06-09 07:10:17.640 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45._Bezug - 19
2025-06-09 07:10:17.640 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45._Einspeisung - 20
2025-06-09 07:10:17.640 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45._Leistung - 21
2025-06-09 07:10:17.696 - silly: sonoff.0 (1242) States user redis pmessage sonoff.0.*/sonoff.0.DVES_C06A45.Time:{"val":"2025-06-09T06:10:17","ack":true,"ts":1749445817693,"q":0,"from":"system.adapter.sonoff.0","user":"system.user.admin","lc":1749445817693}
2025-06-09 07:10:17.697 - debug: sonoff.0 (1242) stateChange sonoff.0.DVES_C06A45.Time: {"val":"2025-06-09T06:10:17","ack":true,"ts":1749445817693,"q":0,"from":"system.adapter.sonoff.0","user":"system.user.admin","lc":1749445817693}
2025-06-09 07:10:17.699 - debug: sonoff.0 (1242) process task: {"type":"addObject","id":"sonoff.0.DVES_C06A45.Uptime","data":{"_id":"sonoff.0.DVES_C06A45.Uptime","common":{"type":"mixed","role":"state","read":true,"write":false,"name":"DVES_C06A45 Uptime"},"native":{},"type":"state"},"cbArg":"0T00:38:50"}
2025-06-09 07:10:17.699 - debug: sonoff.0 (1242) Set state after task: sonoff.0.DVES_C06A45.Uptime
er.sonoff.0","user":"system.user.admin","lc":1749444439013}
Da die Datenstruktur der beiden SDM von der des Hichi abweicht, gehe ich mal davon aus, dass es daran liegt.
Hier noch das Skript aus Tasmota:
>D
>B
->sensor53 r
>M 2
+1,3,m,0,9600,,1,1,01040000,01040006,0104000C,01040048,02040000,02040006,0204000C,02040048
1,010404ffffffff@i0:1,Spannung Klima,V,Spannung_Klima,2
1,010404ffffffff@i1:1,Strom Klima,A,Strom_Klima,2
1,010404ffffffff@i2:1,Leistung Klima,W,Leistung_Klima,2
1,010404ffffffff@i3:1,Verbrauch Klima,kWh,Verbrauch_Klima,2
1,=h ---------------------------------
1,020404ffffffff@i4:1,Spannung WaMa,V,Spannung_WaMa,2
1,020404ffffffff@i5:1,Strom WaMa,A,Strom_WaMa,2
1,020404ffffffff@i6:1,Leistung WaMa,W,Leistung_WaMa,2
1,020404ffffffff@i7:1,Verbrauch WaMa,kWh,Verbrauch_WaMa,2
1,=h ---------------------------------
+2,5,s,0,9600,
2,77070100010800FF@1000,Bezug,kWh,Bezug,1
2,77070100020800FF@1000,Einspeisung, kWh,Einspeisung,1
2,77070100100700FF@1,Leistung,W,Leistung,0
#
Hat jemand eine Idee was hier zu tun ist?
Ergänzung:
Wenn ich im Tasmota Skript den Sensor des Hichi entferne...
>D
>B
->sensor53 r
>M 1
+1,3,m,0,9600,,1,1,01040000,01040006,0104000C,01040048,02040000,02040006,0204000C,02040048
1,010404ffffffff@i0:1,Spannung Klima,V,Spannung_Klima,2
1,010404ffffffff@i1:1,Strom Klima,A,Strom_Klima,2
1,010404ffffffff@i2:1,Leistung Klima,W,Leistung_Klima,2
1,010404ffffffff@i3:1,Verbrauch Klima,kWh,Verbrauch_Klima,2
1,=h ---------------------------------
1,020404ffffffff@i4:1,Spannung WaMa,V,Spannung_WaMa,2
1,020404ffffffff@i5:1,Strom WaMa,A,Strom_WaMa,2
1,020404ffffffff@i6:1,Leistung WaMa,W,Leistung_WaMa,2
1,020404ffffffff@i7:1,Verbrauch WaMa,kWh,Verbrauch_WaMa,2
#
... werden die Datenpunkte der beiden SDM120 angelegt:
offensichtlich kommen die Daten der beiden Sensoren in zwei Arrays, von denen nur das erste vom Sonoff-Adapter ausgewertet wird.
Lösung (bzw. Workaround):
Wenn der Adapter sich nicht um dieses zweite Array kümmert, bietet man ihm die die Werte des zweiten Sensors eben mittels des Tasmota-Scripts einfach im ersten Array an.
Folgendes Tasmota-Script bringt das gewünschte Ergebnis:
>D
var1=0
var2=0
var3=0
var4=0
>B
->sensor53 r
>T
var1=EMH#serialnr
var2=EMH#Bezug
var3=EMH#Einspeisung
var4=EMH#Leistung
>J
;MQTT
,"":{"Zählernummer":%var1%}
,"":{"Bezug":%var2%}
,"":{"Einspeisung":%var3%}
,"":{"Leistung":%var4%}
>M 2
+1,3,m,0,9600,SDM120,1,1,0104000C,01040048,0204000C,02040048
1,010404ffffffff@i0:1,Leistung Klima,W,Leistung_1,2
1,010404ffffffff@i1:1,Verbrauch Klima,kWh,Verbrauch_1,2
1,=h ---------------------------------
1,020404ffffffff@i2:1,Leistung WaMa,W,Leistung_2,2
1,020404ffffffff@i3:1,Verbrauch WaMa,kWh,Verbrauch_2,2
1,=h ---------------------------------
+2,5,s,0,9600,EMH,
2,77070100600100FF@#,Zaehlernummer,,serialnr,16
2,77070100010800FF@1000,Bezug,kWh,Bezug,1
2,77070100020800FF@1000,Einspeisung, kWh,Einspeisung,1
2,77070100100700FF@1,Leistung,W,Leistung,1
#
und hier die Datenpunkte im Sonoff-Adapter:
Jetzt kümmere ich mich mal um die Konstruktion eines Gehäuses für den 3D-Drucker, baue das Teil dann zusammen und nehme es in den Produktivbetrieb.
Wenn Interesse besteht, stelle ich Druckdatei und Schaltplan hier ein.
Hallo zusammen,
ich habe meine Elektroverteilung über einen ESP8266 an IOB angebunden. In der Verteilung liefern ein Hichi IR TTL Lesekopf Daten der "modernen Messeinrichtung" sowie zwei SDM120 Daten von zwei einzelnen Stromkreisen. In Tasmota werden alle Daten korrekt angezeigt:
Die oberen beiden Blöcke sind die beiden SDM120 (der 2. ist noch neu, daher kein Verbrauchswert)
Der untere Block zeigt die Daten des Hichi (Hier stehen keine Werte, da der Kopf derzeit nicht an der Messeinrichtung hängt)
Im Sonoff Adapter werden folgende Datenpunkte angelegt:
Wie zu sehen ist, werden außer den "amtlich angelegten" Datenpunkten nur die Datenpunkte des Hichi angelegt.
Die Datenpunkte der beiden SDM120 fehlen obwohl sie gem. Log übertragen werden (Zeile 20):
2025-06-09 07:10:17.634 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Time - 1
2025-06-09 07:10:17.634 - debug: sonoff.0 (1242) process task: {"type":"addObject","id":"sonoff.0.DVES_C06A45.Time","data":{"_id":"sonoff.0.DVES_C06A45.Time","common":{"type":"string","role":"state","read":true,"write":true,"name":"DVES_C06A45 Time"},"native":{},"type":"state"},"cbArg":"2025-06-09T06:10:17"}
2025-06-09 07:10:17.634 - debug: sonoff.0 (1242) Set state after task: sonoff.0.DVES_C06A45.Time
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Uptime - 2
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.UptimeSec - 3
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Heap - 4
2025-06-09 07:10:17.635 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.SleepMode - 5
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Sleep - 6
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.LoadAvg - 7
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.MqttCount - 8
2025-06-09 07:10:17.636 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_AP - 9
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_SSId - 10
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_BSSId - 11
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Channel - 12
2025-06-09 07:10:17.637 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Mode - 13
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_RSSI - 14
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Signal - 15
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_LinkCount - 16
2025-06-09 07:10:17.638 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Wifi_Downtime - 17
2025-06-09 07:10:17.639 - debug: sonoff.0 (1242) Client [DVES_C06A45] received: tele/tasmota_C06A45/SENSOR = {"Time":"2025-06-09T06:10:17","":{"Spannung_Klima":227.00,"Strom_Klima":0.00,"Leistung_Klima":0.00,"Verbrauch_Klima":737.81,"Spannung_WaMa":226.72,"Strom_WaMa":0.03,"Leistung_WaMa":0.46,"Verbrauch_WaMa":0.00},"":{"Bezug":0.0,"Einspeisung":0.0,"Leistung":0}}
2025-06-09 07:10:17.639 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45.Time - 18
2025-06-09 07:10:17.640 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45._Bezug - 19
2025-06-09 07:10:17.640 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45._Einspeisung - 20
2025-06-09 07:10:17.640 - debug: sonoff.0 (1242) Update state sonoff.0.DVES_C06A45._Leistung - 21
2025-06-09 07:10:17.696 - silly: sonoff.0 (1242) States user redis pmessage sonoff.0.*/sonoff.0.DVES_C06A45.Time:{"val":"2025-06-09T06:10:17","ack":true,"ts":1749445817693,"q":0,"from":"system.adapter.sonoff.0","user":"system.user.admin","lc":1749445817693}
2025-06-09 07:10:17.697 - debug: sonoff.0 (1242) stateChange sonoff.0.DVES_C06A45.Time: {"val":"2025-06-09T06:10:17","ack":true,"ts":1749445817693,"q":0,"from":"system.adapter.sonoff.0","user":"system.user.admin","lc":1749445817693}
2025-06-09 07:10:17.699 - debug: sonoff.0 (1242) process task: {"type":"addObject","id":"sonoff.0.DVES_C06A45.Uptime","data":{"_id":"sonoff.0.DVES_C06A45.Uptime","common":{"type":"mixed","role":"state","read":true,"write":false,"name":"DVES_C06A45 Uptime"},"native":{},"type":"state"},"cbArg":"0T00:38:50"}
2025-06-09 07:10:17.699 - debug: sonoff.0 (1242) Set state after task: sonoff.0.DVES_C06A45.Uptime
er.sonoff.0","user":"system.user.admin","lc":1749444439013}
Da die Datenstruktur der beiden SDM von der des Hichi abweicht, gehe ich mal davon aus, dass es daran liegt.
Hier noch das Skript aus Tasmota:
>D
>B
->sensor53 r
>M 2
+1,3,m,0,9600,,1,1,01040000,01040006,0104000C,01040048,02040000,02040006,0204000C,02040048
1,010404ffffffff@i0:1,Spannung Klima,V,Spannung_Klima,2
1,010404ffffffff@i1:1,Strom Klima,A,Strom_Klima,2
1,010404ffffffff@i2:1,Leistung Klima,W,Leistung_Klima,2
1,010404ffffffff@i3:1,Verbrauch Klima,kWh,Verbrauch_Klima,2
1,=h ---------------------------------
1,020404ffffffff@i4:1,Spannung WaMa,V,Spannung_WaMa,2
1,020404ffffffff@i5:1,Strom WaMa,A,Strom_WaMa,2
1,020404ffffffff@i6:1,Leistung WaMa,W,Leistung_WaMa,2
1,020404ffffffff@i7:1,Verbrauch WaMa,kWh,Verbrauch_WaMa,2
1,=h ---------------------------------
+2,5,s,0,9600,
2,77070100010800FF@1000,Bezug,kWh,Bezug,1
2,77070100020800FF@1000,Einspeisung, kWh,Einspeisung,1
2,77070100100700FF@1,Leistung,W,Leistung,0
#
Hat jemand eine Idee was hier zu tun ist?
Ergänzung:
Wenn ich im Tasmota Skript den Sensor des Hichi entferne...
>D
>B
->sensor53 r
>M 1
+1,3,m,0,9600,,1,1,01040000,01040006,0104000C,01040048,02040000,02040006,0204000C,02040048
1,010404ffffffff@i0:1,Spannung Klima,V,Spannung_Klima,2
1,010404ffffffff@i1:1,Strom Klima,A,Strom_Klima,2
1,010404ffffffff@i2:1,Leistung Klima,W,Leistung_Klima,2
1,010404ffffffff@i3:1,Verbrauch Klima,kWh,Verbrauch_Klima,2
1,=h ---------------------------------
1,020404ffffffff@i4:1,Spannung WaMa,V,Spannung_WaMa,2
1,020404ffffffff@i5:1,Strom WaMa,A,Strom_WaMa,2
1,020404ffffffff@i6:1,Leistung WaMa,W,Leistung_WaMa,2
1,020404ffffffff@i7:1,Verbrauch WaMa,kWh,Verbrauch_WaMa,2
#
... werden die Datenpunkte der beiden SDM120 angelegt:
@joergh
Jetzt hab ich's verstanden
vielen Dank für Deine Geduld
@joergh
@paul53
Danke Euch, mittlerweile funktioniert es. Es lag am "true" bei setState.
Es funktionieren beide Varianten (ohne und mit "false" als ack-Parameter)
Die Aktualisierung in die Cloud erfolgt nicht sofort, sondern im Rahmen des Abfragezyklus (in meinem Fall alle 10 Minuten).
@joergh
danke, ich sehe es mir mal an.
Wie ist Deine Einstellung im Adapter bei "Dieselben Werte noch einmal senden?"
@joergh
hab es mal mit "false" probiert, gleiches Ergebnis 
Kannst Du mal bitte Dein Blockly einstellen?
Also einschließlich der Parameter, die Du da übergibst. Ich übergebe derzeit nur Ziffern 0 bis 4
@joergh
Was meinst du mit "steuere"? ich mache das mit dem oben gezeigten Script. Ist da ein Fehler drin oder fehlt da ein Parameter?
@joergh
Wenn ich mit dem Script den operationMode z.B. auf 2 stelle (cooling), dann wird das auch so in den Objekten angezeigt.
In der App steht der Modus aber auch nach einer Stunde weiterhin auf "Heizen".
Im Objekt "lastUpdateReceived" wird aber alle 10 Minuten die Uhrzeit aktualisiert. Eine Synchronisation erfolgt jedoch in keine Richtung. (Objekt "operationMode" steht auf "Kühlen", in der App wird "Heizen" angezeigt)
Hallo zusammen,
ich versuche gerade meine Daikin Klimaanlagen zu visualisieren und auch mit einem Script zu steuern.
Der Adapter läuft, die Steuerung und die Visualisierung funktionieren.
Allerdings bekomme ich die Änderungen in den Objekten nicht mit der Cloud synchronisiert. Dass ist notwendig, um die Einstellungen auch in der Daikin App auf Handys und Tabletts zu aktualisieren.
Offenbar muss man im Adapter hier...
... etwas einstellen. Allerdings gibt es da keine Eingabemöglichkeiten
Gibt es da einen Weg, bzw. was habe ich übersehen?
Hier mein Script dazu:
on ({id: '0_userdata.0.Klimaanlage.Betriebsmodus', change: 'any'}, function(obj){
let modus = getState("0_userdata.0.Klimaanlage.Betriebsmodus").val;
setState("daikin-cloud.0.zzzzzzzzzzzzzz.climateControl.operationMode", modus, true); //Modus Schlafzimmer
setState("daikin-cloud.0.yyyyyyyyyyyy.climateControl.operationMode", modus, true); //Modus Wohnzimmer
setState("daikin-cloud.0.xxxxxx.climateControl.operationMode", modus, true); //Modus Arbeitszimmer
})
Muss man da ggf. noch ein anderes Objekt setzen, damit die Übertragung in die Cloud erfolgt?
@homoran
@arteck
Danke Euch,
nach Verschieben der Instanz vom Slave zum Master wurde der Adapter weiterhin nur auf dem Slave angezeigt. Meine Befürchtung war, dass nach Herausnahme des Slaves die Instanz auf dem Master nicht läuft, da dort dann vermutlich einige Komponenten fehlen.
Nach einem Reboot war der Adapter dann aber auch auf dem Master zu sehen.
Sobald meine übrigen Vorbereitungen abgeschlossen sind, werde ich den Slave dann außer Betrieb nehmen.
