NEWS
Test Adapter e3dc-rscp v0.0.x GitHub
-
Uli in IDLE_PERIODS_DISCHARGE sind keine Werte enthalten, ist das noch nicht so weit oder liegt es an der v0.0.16-beta2 ?
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Uli in IDLE_PERIODS_DISCHARGE sind keine Werte enthalten, ist das noch nicht so weit oder liegt es an der v0.0.16-beta2 ?
Bei mir sind (mit v0.0.16-beta3) alle Werte da, es gibt aber eine kleine Verzögerung beim ersten Öffnen der Tages-Ordner, bis die Werte angezeigt werden (max. etwa 1 Sekunde). Bist du sicher, dass die Werte dauerhaft nicht erscheinen? Wenn ja, bitte ich wieder um ein silly-log ab Adapter-Start :innocent:
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Uli in IDLE_PERIODS_DISCHARGE sind keine Werte enthalten, ist das noch nicht so weit oder liegt es an der v0.0.16-beta2 ?
Bei mir sind (mit v0.0.16-beta3) alle Werte da, es gibt aber eine kleine Verzögerung beim ersten Öffnen der Tages-Ordner, bis die Werte angezeigt werden (max. etwa 1 Sekunde). Bist du sicher, dass die Werte dauerhaft nicht erscheinen? Wenn ja, bitte ich wieder um ein silly-log ab Adapter-Start :innocent:
Neue WB bugfix Version:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.16-beta3Ich habe ein falsches (PVI) Anfragetag aus der WB-Anfrage entfernt - evtl. hilft das gegen die Doppel im Objektbaum (bin nicht sicher)
Bitte auch die Werte
"WB.WB_0.EXTERN_DATA_SUN",
"WB.WB_0.EXTERN_DATA_NET",
"WB.WB_0.EXTERN_DATA_ALL",
"WB.WB_0.EXTERN_DATA_ALG",
"WB.WB_0.EXTERN_RSP_PARAM_1",
"WB.WB_0.EXTERN_RSP_PARAM_2"
prüfen, denn die kommen alle in extra Containern, da habe ich das Handling jetzt eingebaut. Zudem sollten die ByteArray-Werte jetzt als hex dump (z.B. "FA AB 01 02") dargestellt werden.v0.0.16-beta3
- WB inbound containers are now handled
- ByteArray values are translated to "hex dump" strings
- wrong PVI request tag was removed from WB get data frame
P.S. das silly-log (txt-Datei) war sehr hilfreich, bitte bei WB-Fehlern wieder beilegen, dann habe ich viel bessere Karten bei der Fehlersuche ...
-
Neue WB bugfix Version:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.16-beta3Ich habe ein falsches (PVI) Anfragetag aus der WB-Anfrage entfernt - evtl. hilft das gegen die Doppel im Objektbaum (bin nicht sicher)
Bitte auch die Werte
"WB.WB_0.EXTERN_DATA_SUN",
"WB.WB_0.EXTERN_DATA_NET",
"WB.WB_0.EXTERN_DATA_ALL",
"WB.WB_0.EXTERN_DATA_ALG",
"WB.WB_0.EXTERN_RSP_PARAM_1",
"WB.WB_0.EXTERN_RSP_PARAM_2"
prüfen, denn die kommen alle in extra Containern, da habe ich das Handling jetzt eingebaut. Zudem sollten die ByteArray-Werte jetzt als hex dump (z.B. "FA AB 01 02") dargestellt werden.v0.0.16-beta3
- WB inbound containers are now handled
- ByteArray values are translated to "hex dump" strings
- wrong PVI request tag was removed from WB get data frame
P.S. das silly-log (txt-Datei) war sehr hilfreich, bitte bei WB-Fehlern wieder beilegen, dann habe ich viel bessere Karten bei der Fehlersuche ...
-
@ujok
Habe die neue Version installiert.
Bei den SYS_SPECS ist jetzt was durcheinander gekommen, da sieht die Beschriftung jetzt so aus:
-
LOG Datei Silly:
Neues Textdokument.txt -
Habe jetzt das E-Auto angesteckt, und die Werte L1-L3 sind richtig.
Alle ENERGY Werte werden jetzt in Wh angezeigt.
Durch den Ausfall des Forum-Servers sind ein paar (wenige) Posts verloren gegangen.
Um wieder gemeinsam aufzusetzen, hier meine aktuelle Version:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.16-beta4Ich habe die falsche Darstellung der Namen und Strings (u.a. unter SYS_SPECS) korrigiert.
Bitte die Daten unter WB prüfen, insbesondere die ByteArrays (EXTERN_..., RSP_PARAM_...), diese Werte sollten jetzt in Hex-Darstellung (z.B. "F0 11 00 0D") erscheinen. -
Version 0.6.16-beta4 installiert.
Falsche Darstellung der Namen unter SYS_SPECS :+1:
Keine Warnungen oder Fehlermeldungen im LOG :+1:Bei EMS.IDLE_PERIODS_DISCHARGE werden keine States angelegt.
Bitte die Daten unter WB prüfen, insbesondere die ByteArrays (EXTERN_..., RSP_PARAM_...), diese Werte sollten jetzt in Hex-Darstellung (z.B. "F0 11 00 0D") erscheinen.
Ja ist so, da ich nicht weiß, was du genau benötigst, hier ein Screenshot:
-
Version 0.6.16-beta4 installiert.
Falsche Darstellung der Namen unter SYS_SPECS :+1:
Keine Warnungen oder Fehlermeldungen im LOG :+1:Bei EMS.IDLE_PERIODS_DISCHARGE werden keine States angelegt.
Bitte die Daten unter WB prüfen, insbesondere die ByteArrays (EXTERN_..., RSP_PARAM_...), diese Werte sollten jetzt in Hex-Darstellung (z.B. "F0 11 00 0D") erscheinen.
Ja ist so, da ich nicht weiß, was du genau benötigst, hier ein Screenshot:
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Version 0.6.16-beta4 installiert.
Bei EMS.IDLE_PERIODS_DISCHARGE werden keine States angelegt.
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
-
Version 0.6.16-beta4 installiert.
Falsche Darstellung der Namen unter SYS_SPECS :+1:
Keine Warnungen oder Fehlermeldungen im LOG :+1:Bei EMS.IDLE_PERIODS_DISCHARGE werden keine States angelegt.
Bitte die Daten unter WB prüfen, insbesondere die ByteArrays (EXTERN_..., RSP_PARAM_...), diese Werte sollten jetzt in Hex-Darstellung (z.B. "F0 11 00 0D") erscheinen.
Ja ist so, da ich nicht weiß, was du genau benötigst, hier ein Screenshot:
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Version 0.6.16-beta4 installiert.
Bitte die Daten unter WB prüfen, insbesondere die ByteArrays (EXTERN_..., RSP_PARAM_...), diese Werte sollten jetzt in Hex-Darstellung (z.B. "F0 11 00 0D") erscheinen.
Ja ist so, da ich nicht weiß, was du genau benötigst, hier ein Screenshot:
Danke, ich wollte zunächst nur wissen, ob die ByteArrays jetzt ordentlich dargestellt werden, denn diesen RSCP-Datentyp hatten wir bisher noch nicht. Was die Bytefolgen bedeuten, ist ein anderesThema, da müssen die E3/DC oder Easyconnect Wallbox-Besitzer ran, soweit das überhaupt relevant ist...
Um die noch fehlenden Namen im Screenshot kümmere ich mich.
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Version 0.6.16-beta4 installiert.
Bitte die Daten unter WB prüfen, insbesondere die ByteArrays (EXTERN_..., RSP_PARAM_...), diese Werte sollten jetzt in Hex-Darstellung (z.B. "F0 11 00 0D") erscheinen.
Ja ist so, da ich nicht weiß, was du genau benötigst, hier ein Screenshot:
Danke, ich wollte zunächst nur wissen, ob die ByteArrays jetzt ordentlich dargestellt werden, denn diesen RSCP-Datentyp hatten wir bisher noch nicht. Was die Bytefolgen bedeuten, ist ein anderesThema, da müssen die E3/DC oder Easyconnect Wallbox-Besitzer ran, soweit das überhaupt relevant ist...
Um die noch fehlenden Namen im Screenshot kümmere ich mich.
@ujok
Ok habe mir jetzt mal EXTERN_DATA_ALG genauer angesehen.
In der Tag Liste ist folgende Beschreibung enthalten:
contains EXTERN_DATA (length 7) and EXTERN_DATA_LEN =7 / Byte 1: uint8, PreCharge in [%] / Byte 2: uint8, 1: Sonnenmode, 0: Misch. / Byte 3: uint8, 1: Auto l„dt, 0: l„dt nicht / Byte 4: uint8, 1: Typ2 verriegelt, 0: entr. / Byte 5: uint8, Anzahl akt. Phasen [0-3] / Byte 6: uint4 low, 1: Schuko belegt / uint4 high, 1: Schuko an /Jetzt bin ich nicht so fit in HEX und umwandlung in Byte :-)
Beim HEX Wert beginnend von links sind die ersten beiden Stellen PreCharge in [%]
Die Stelle 3 und 4 die Phasen mit denen geladen wird.
Die Stelle 5 und 6 vereint mehrere Bedeutungen. Stecker gesteckt, Stecker verriegel/entriegelt, Sonnenmode/Mischmode, Auto lädt/lädt nicht
Die Stelle 7 und 8 ist der aktuelle Ladestrom.HEX Wert 32 03 28 14 00 00 00 00 bedeutet demnach
32 = 50% (gleich mit Wert e3dc-rscp.0.WB.WB_0.SOC)
03 = drei Phasen
28 = angesteckt, verriegelt, Mischmode, Auto lädt (Hier weiß ich noch nicht wie sich das zusammensetzt)
14 = Laden mit 20ADie restlichen Stellen haben keine Bedeutung.
EXTERN_DATA ist anscheinend der Rückgabewert der Ladeleistung, hier hat von links nur die Stelle 5 und 6 eine Bedeutung und ist immer gleich mit EXTERN_DATA_ALG Stelle 7 und 8
EXTERN_DATA_ALL ist gleich mit EXTERN_DATA_NET und Zeigt die Ladeleistung an, bei EXTERN_DATA_ALL wird auf den letzten beiden Stellen von links noch PreCharge in [%] angezeigt.
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Version 0.6.16-beta4 installiert.
Bei EMS.IDLE_PERIODS_DISCHARGE werden keine States angelegt.
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
Hier der LOG File:
Neues Textdokument.txt -
@ujok
Ok habe mir jetzt mal EXTERN_DATA_ALG genauer angesehen.
In der Tag Liste ist folgende Beschreibung enthalten:
contains EXTERN_DATA (length 7) and EXTERN_DATA_LEN =7 / Byte 1: uint8, PreCharge in [%] / Byte 2: uint8, 1: Sonnenmode, 0: Misch. / Byte 3: uint8, 1: Auto l„dt, 0: l„dt nicht / Byte 4: uint8, 1: Typ2 verriegelt, 0: entr. / Byte 5: uint8, Anzahl akt. Phasen [0-3] / Byte 6: uint4 low, 1: Schuko belegt / uint4 high, 1: Schuko an /Jetzt bin ich nicht so fit in HEX und umwandlung in Byte :-)
Beim HEX Wert beginnend von links sind die ersten beiden Stellen PreCharge in [%]
Die Stelle 3 und 4 die Phasen mit denen geladen wird.
Die Stelle 5 und 6 vereint mehrere Bedeutungen. Stecker gesteckt, Stecker verriegel/entriegelt, Sonnenmode/Mischmode, Auto lädt/lädt nicht
Die Stelle 7 und 8 ist der aktuelle Ladestrom.HEX Wert 32 03 28 14 00 00 00 00 bedeutet demnach
32 = 50% (gleich mit Wert e3dc-rscp.0.WB.WB_0.SOC)
03 = drei Phasen
28 = angesteckt, verriegelt, Mischmode, Auto lädt (Hier weiß ich noch nicht wie sich das zusammensetzt)
14 = Laden mit 20ADie restlichen Stellen haben keine Bedeutung.
EXTERN_DATA ist anscheinend der Rückgabewert der Ladeleistung, hier hat von links nur die Stelle 5 und 6 eine Bedeutung und ist immer gleich mit EXTERN_DATA_ALG Stelle 7 und 8
EXTERN_DATA_ALL ist gleich mit EXTERN_DATA_NET und Zeigt die Ladeleistung an, bei EXTERN_DATA_ALL wird auf den letzten beiden Stellen von links noch PreCharge in [%] angezeigt.
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok
Ok habe mir jetzt mal EXTERN_DATA_ALG genauer angesehen.
In der Tag Liste ist folgende Beschreibung enthalten:
contains EXTERN_DATA (length 7) and EXTERN_DATA_LEN =7 / Byte 1: uint8, PreCharge in [%] / Byte 2: uint8, 1: Sonnenmode, 0: Misch. / Byte 3: uint8, 1: Auto l„dt, 0: l„dt nicht / Byte 4: uint8, 1: Typ2 verriegelt, 0: entr. / Byte 5: uint8, Anzahl akt. Phasen [0-3] / Byte 6: uint4 low, 1: Schuko belegt / uint4 high, 1: Schuko an /Jetzt bin ich nicht so fit in HEX und umwandlung in Byte :-)
Beim HEX Wert beginnend von links sind die ersten beiden Stellen PreCharge in [%]
Die Stelle 3 und 4 die Phasen mit denen geladen wird.
Die Stelle 5 und 6 vereint mehrere Bedeutungen. Stecker gesteckt, Stecker verriegel/entriegelt, Sonnenmode/Mischmode, Auto lädt/lädt nicht
Die Stelle 7 und 8 ist der aktuelle Ladestrom.HEX Wert 32 03 28 14 00 00 00 00 bedeutet demnach
32 = 50% (gleich mit Wert e3dc-rscp.0.WB.WB_0.SOC)
03 = drei Phasen
28 = angesteckt, verriegelt, Mischmode, Auto lädt (Hier weiß ich noch nicht wie sich das zusammensetzt)
14 = Laden mit 20ADie restlichen Stellen haben keine Bedeutung.
EXTERN_DATA ist anscheinend der Rückgabewert der Ladeleistung, hier hat von links nur die Stelle 5 und 6 eine Bedeutung und ist immer gleich mit EXTERN_DATA_ALG Stelle 7 und 8
EXTERN_DATA_ALL ist gleich mit EXTERN_DATA_NET und Zeigt die Ladeleistung an, bei EXTERN_DATA_ALL wird auf den letzten beiden Stellen von links noch PreCharge in [%] angezeigt.
Da steckt ja einiges an Information drin und z.T. auch redundant. Ich könnte das im Adapter zerlegen, aber ist das wichtig und sinnvoll? Ich habe da Bedenken, weil ich nicht weiß, ob (je nach Wallbox-Typ) die EXTERN_... Felder wirklich immer gleich codiert sind.
Was denkst du @ArnoD , was denkt ihr (alle anderen)? Soll ich das einbauen oder macht man das besser mit Scripts "nach" dem Adapter?
-
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
Hier der LOG File:
Neues Textdokument.txt@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
Hier der LOG File:
Neues Textdokument.txtIch habe mir das angesehen und es ist noch rätselhaft:
- tatsächlich sind im LOG nur Antworten mit IDLE_PERIOD_TYPE = 0 enthalten, also nur IDLE_PERIODS_CHARGE, keine IDLE_PERIODS_DISCHARGE
- es gibt meines Wissens nur ein Anfrage-Tag für IDLE_PERIODS, nämlich TAG_EMS_REQ_GET_IDLE_PERIODS
- als Antwort auf TAG_EMS_REQ_GET_IDLE_PERIODS sendet mein E3/DC die Daten sowohl zu IDLE_PERIODS_CHARGE als auch zu IDLE_PERIODS_DISCHARGE
Frage an @ArnoD: kannst du in RscpGUI und im e3dc-Portal die IDLE_PERIODS_DISCHARGE sehen und verändern?(erledigt)Frage an alle: hat noch jemand den Effekt, dass IDLE_PERIODS_DISCHARGE nicht angezeigt werden?(erledigt) -
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
Hier der LOG File:
Neues Textdokument.txtIch habe mir das angesehen und es ist noch rätselhaft:
- tatsächlich sind im LOG nur Antworten mit IDLE_PERIOD_TYPE = 0 enthalten, also nur IDLE_PERIODS_CHARGE, keine IDLE_PERIODS_DISCHARGE
- es gibt meines Wissens nur ein Anfrage-Tag für IDLE_PERIODS, nämlich TAG_EMS_REQ_GET_IDLE_PERIODS
- als Antwort auf TAG_EMS_REQ_GET_IDLE_PERIODS sendet mein E3/DC die Daten sowohl zu IDLE_PERIODS_CHARGE als auch zu IDLE_PERIODS_DISCHARGE
Frage an @ArnoD: kannst du in RscpGUI und im e3dc-Portal die IDLE_PERIODS_DISCHARGE sehen und verändern?(erledigt)Frage an alle: hat noch jemand den Effekt, dass IDLE_PERIODS_DISCHARGE nicht angezeigt werden?(erledigt)@ujok
Bei mir sind
((e3dc-rscp.0.EMS.IDLE_PERIODS_CHARGE und e3dc-rscp.0.EMS.IDLE_PERIODS_DISCHARGE leer.))
Sorry, mein Fehler, ich habe die Daten, Charge geht beschreiben, Discharge nicht.TAG_EMS_REQ_GET_IDLE_PERIODS kann ich überhaupt nicht finden ??
Noch ne andere Frage: kannst du auch die labels "Derate at percent value" und "Derate at Power value" beschreibbar machen? Mit dem richtigen Login sollte das beschreibbar sein und könnte remote ganz hilfreich sein.
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Bei mir werden die EMS.IDLE_PERIODS_DISCHARGE immer sauber angelegt, deshalb tu ich mich schwer mit der Fehlersuche. Kannst du dazu bitte ein silly-Log posten?
Hier der LOG File:
Neues Textdokument.txtIch habe mir das angesehen und es ist noch rätselhaft:
- tatsächlich sind im LOG nur Antworten mit IDLE_PERIOD_TYPE = 0 enthalten, also nur IDLE_PERIODS_CHARGE, keine IDLE_PERIODS_DISCHARGE
- es gibt meines Wissens nur ein Anfrage-Tag für IDLE_PERIODS, nämlich TAG_EMS_REQ_GET_IDLE_PERIODS
- als Antwort auf TAG_EMS_REQ_GET_IDLE_PERIODS sendet mein E3/DC die Daten sowohl zu IDLE_PERIODS_CHARGE als auch zu IDLE_PERIODS_DISCHARGE
Frage an @ArnoD: kannst du in RscpGUI und im e3dc-Portal die IDLE_PERIODS_DISCHARGE sehen und verändern?(erledigt)Frage an alle: hat noch jemand den Effekt, dass IDLE_PERIODS_DISCHARGE nicht angezeigt werden?(erledigt)@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
kannst du in RscpGUI und im e3dc-Portal die IDLE_PERIODS_DISCHARGE sehen und verändern?
Ja, geht beides.
in RscpGui ist bei Discharge nur die Tagesreihenfolge falsch, aber es geht.Sorry, ich war nur zu doof, ich hab die Werte, Charge kann ich beschreiben, DISCHarge nicht!
-
@ujok
Bei mir sind
((e3dc-rscp.0.EMS.IDLE_PERIODS_CHARGE und e3dc-rscp.0.EMS.IDLE_PERIODS_DISCHARGE leer.))
Sorry, mein Fehler, ich habe die Daten, Charge geht beschreiben, Discharge nicht.TAG_EMS_REQ_GET_IDLE_PERIODS kann ich überhaupt nicht finden ??
Noch ne andere Frage: kannst du auch die labels "Derate at percent value" und "Derate at Power value" beschreibbar machen? Mit dem richtigen Login sollte das beschreibbar sein und könnte remote ganz hilfreich sein.
@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok
Bei mir sind
e3dc-rscp.0.EMS.IDLE_PERIODS_CHARGE und e3dc-rscp.0.EMS.IDLE_PERIODS_DISCHARGE leer.
TAG_EMS_REQ_GET_IDLE_PERIODS kann ich überhaupt nicht finden ??TAG_EMS_REQ_GET_IDLE_PERIODS ist das Anfrage-Tag, das erscheint nicht in der Antwort und damit auch (gewollt) nicht im Objektbaum. Wenn ich das losschicke, bekomme ich als Antwort alle idle periods Daten für Laden und Entladen.
Das Log zeigt, dass bei Dir die idle periods für das Laden ankommen, nicht aber die für das Entladen. Jetzt habe ich schon zwei offene Fragen
- Warum kommen bei dir nicht auch die Entlade idle periods zurück?
- Warum werden die (im LOG sichtbaren) Werte zu den Lade idle periods bei dir nicht angezeigt?
Zu Nr 1 sehe ich im Moment gar keinen Anhaltspunkt, zu Nr 2 werde ich mir das Log nochmal genauer ansehen.
-
@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok
Bei mir sind
e3dc-rscp.0.EMS.IDLE_PERIODS_CHARGE und e3dc-rscp.0.EMS.IDLE_PERIODS_DISCHARGE leer.
TAG_EMS_REQ_GET_IDLE_PERIODS kann ich überhaupt nicht finden ??TAG_EMS_REQ_GET_IDLE_PERIODS ist das Anfrage-Tag, das erscheint nicht in der Antwort und damit auch (gewollt) nicht im Objektbaum. Wenn ich das losschicke, bekomme ich als Antwort alle idle periods Daten für Laden und Entladen.
Das Log zeigt, dass bei Dir die idle periods für das Laden ankommen, nicht aber die für das Entladen. Jetzt habe ich schon zwei offene Fragen
- Warum kommen bei dir nicht auch die Entlade idle periods zurück?
- Warum werden die (im LOG sichtbaren) Werte zu den Lade idle periods bei dir nicht angezeigt?
Zu Nr 1 sehe ich im Moment gar keinen Anhaltspunkt, zu Nr 2 werde ich mir das Log nochmal genauer ansehen.
-
@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok Sorry, war mein Fehler, ich kann beide sehen, nur Discharge nicht editieren!
Hm, jetzt bin ich komplett verwirrt: laut LOG wurden bei dir keine IDLE_PERIODS_DISCHARGE Daten geliefert, wie kannst du die dann sehen?
Ich glaube ich steh grade auf der Leitung...Aber ich schau mir auf jeden Fall das Schreiben der IDLE_PERIODS_DISCHARGE Daten mal an, also ob es bei mir sauber funktioniert und ob da im Code womöglich ein Bug ist.
-
@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok Sorry, war mein Fehler, ich kann beide sehen, nur Discharge nicht editieren!
Hm, jetzt bin ich komplett verwirrt: laut LOG wurden bei dir keine IDLE_PERIODS_DISCHARGE Daten geliefert, wie kannst du die dann sehen?
Ich glaube ich steh grade auf der Leitung...Aber ich schau mir auf jeden Fall das Schreiben der IDLE_PERIODS_DISCHARGE Daten mal an, also ob es bei mir sauber funktioniert und ob da im Code womöglich ein Bug ist.
Support us
522
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge