UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[git-kick]

@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:

@ujok
Heute Abend (vermutlich um 02:49 Uhr) wurde eine neue Firmware Version von E3DC hochgeladen und danach hat der e3dc-rscp Adapter keine Verbindung mehr aufgebaut und nur noch laufend eine Warnung in das LOG geschrieben.
Erst durch einen manuellen Neustart vom Adapter funktioniert alles wieder.
Ich weiß nicht, ob das jetzt nur bei mir passiert ist und ob es mit dem Update zusammenhängt.

Das LOG habe ich jetzt nicht ganz kopiert. Der Fehler "Failed writing data to socket" wurde laufend wiedergolt bis zum neustart.

Danke @ArnoD und @PB, das ist wertvoller Input für Issue#74
Mir ist nämlich beim Testen des E3/DC-Reboot auch schon aufgefallen, dass der Adapter sich nicht "erholt", wenn die E3/DC neu startet.
Also, Problem ist im Backlog.

[git-kick]

FYI, v1.0.2 ist released

v1.0.2 - Added SYS namespace (experimental)

• SYS namespace, experimental support - Issue #60
• info.connection is true while no connection - Issue #64
• Compatibility check to js-controller 4.0 - Issue #75
• WB.PM_ACTIVE_PHASES decode values - Issue #76
• WB.MODE decode value 8 - Issue #77
• Dependabot: follow-redirects 1.14.8

[ArnoD]

Habe gerade die Version 1.0.2 installiert und folgende Rückmeldung von mir:

Beim Adapter Start kommt folgende Meldung:

2022-02-17 11:19:13.921 - info: e3dc-rscp.0 (973) starting. Version 1.0.2 in /opt/iobroker/node_modules/iobroker.e3dc-rscp, node: v14.19.0, js-controller: 4.0.8
2022-02-17 11:19:14.116 - info: e3dc-rscp.0 (973) Connection to E3/DC is established
2022-02-17 11:19:14.607 - warn: e3dc-rscp.0 (973) Object e3dc-rscp.0.SYS.IS_SYSTEM_REBOOTING is invalid: obj.common.states has an invalid type! Expected non-null "object", received "null"
2022-02-17 11:19:14.608 - warn: e3dc-rscp.0 (973) This object will not be created in future versions. Please report this to the developer.

e3dc-rscp.0.SYS.SYSTEM_REBOOT funktioniert aber danach der bereits gemeldete Fehler das der Adapter einen manuellen Neustart benötigt.
Der Wert bleibt auf 1 und wird nicht auf 0 zurückgesetzt, kann man aber in VIS über eine Taster Funktion lösen.
e3dc-rscp.0.SYS.IS_SYSTEM_REBOOTING bleibt immer auf false, hier ändert sich nichts, wird der Type wohl auch nicht unterstützt, wenn ich die Meldung beim Start richtig deute.
e3dc-rscp.0.SYS.RESTART_APPLICATION habe ich getestet, konnte aber keine Reaktion am E3DC feststellen, woran erkenne ich, ob es funktioniert? :thinking_face:

[git-kick]

@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:

Habe gerade die Version 1.0.2 installiert und folgende Rückmeldung von mir:

Beim Adapter Start kommt folgende Meldung:
...
e3dc-rscp.0.SYS.IS_SYSTEM_REBOOTING bleibt immer auf false, hier ändert sich nichts, wird der Type wohl auch nicht unterstützt, wenn ich die Meldung beim Start richtig deute.

Das tritt bei mir nicht auf. Kannst du bitte nochmal mit js-controller: 4.0.10 testen (und zuvor wie immer den Adapter komplett incl. Objektbaum löschen...)

e3dc-rscp.0.SYS.SYSTEM_REBOOT funktioniert aber danach der bereits gemeldete Fehler das der Adapter einen manuellen Neustart benötigt.
Der Wert bleibt auf 1 und wird nicht auf 0 zurückgesetzt, kann man aber in VIS über eine Taster Funktion lösen.

Ja, der Objektbaum ist zum Bedienen nur eingeschränkt sinnvoll; ist wohl auch nicht als (vollwertiges) GUI gedacht :wink:

e3dc-rscp.0.SYS.RESTART_APPLICATION habe ich getestet, konnte aber keine Reaktion am E3DC feststellen, woran erkenne ich, ob es funktioniert? :thinking_face:

Bei mir kommen nach RESTART_APPLICATION eine Weile keine neuen Werte zurück, was plausibel ist. Weiter habe ich das nicht erforscht.

[ArnoD]

@ujok
:+1: funktioniert jetzt

[brumark]

@stephan61
Hallo Stephan, konntest du das Problem mit den fehlenden Batteriedaten lösen?
Bei mir sieht es leider genau so aus wie bei dir: Alle Werte, ausser die der Batterien, werden werden korrekt angezeigt.
Im Log auf Level Debug kann ich auch keinen Fehler finden.

@ujok
Mit dem Tool RSCPGui, welches auch via RSCP zugreift, kann ich die Batteriedaten problemlos auslesen. Es muss also mit der Art der Abfrage zusammenhängen oder der Version der Anlage.

Wäre toll, wenn man diese Abfrage noch irgendwie hinbekommen würde. Ansonsten bin ich vom Adapter begeistert.

Vielen Dank!
Christoph

[git-kick]

@brumark said in Test Adapter e3dc-rscp v0.0.x GitHub:

Mit dem Tool RSCPGui, welches auch via RSCP zugreift, kann ich die Batteriedaten problemlos auslesen. Es muss also mit der Art der Abfrage zusammenhängen oder der Version der Anlage.

Wäre toll, wenn man diese Abfrage noch irgendwie hinbekommen würde. Ansonsten bin ich vom Adapter begeistert.

Der Hinweis auf RSCPGui hilft sehr, weil ich da im Code nachschauen kann, wie @rxhan es gelöst hat.
Kannst du bitte unter https://github.com/git-kick/ioBroker.e3dc-rscp/issues einen Bug Report anlegen (in DE oder EN, egal) und die gestellten Fragen beantworten, dann gehe ich das bei Gelegenheit an. Insbesondere ist eine genaue Beschreibung wichtig, was du installiert hast und was bei den Batteriedaten fehlt, außerdem ein debug-log.

(Das Vorgehen "Bug Report" ist entscheidend für die Handhabbarkeit der Rückmeldungen; das Forum hier ist eigenlich ein Relikt aus der Beta-Test-Zeit, das jetzt nur noch für Diskussionen "drum herum" da ist.)

[gyle]

frage zu DB

ich hätte jetzt vermutet, dass ich hier die entsprechenden werte finde, die auch im e3dc-portal zu sehen sind...stattdessen sehe ich nur folgendes:

könnt ihr mich aufklären?

danke

[git-kick]

@gyle README

NB: der Adapter hat nicht den Anspruch, die Daten von der Schnittstelle aufzubereiten - sie werden im Regelfall 1:1 in den Objektbaum übernommen.

[ArnoD]

@gyle
Warum willst du diese Werte wie im E3DC Portal anzeigen? Du hättest dann nur die Diagramme wie im Portal mit Werten, die alle 15 min. einen neuen Datenpunkt hätten.
Im iobroker hast du mit der Kombination von Flot und History Adapter die Möglichkeit jede sek. einen Wert aufzuzeichnen und in einem Diagramm darzustellen.
Damit können dann auch Fehler beim Laden oder entladen aufgezeichnet werden, was bei einer Abtastrate von 15 min. nicht möglich ist.

Meiner Meinung nach bringen die DB Werte in diesem Adapter keinen Mehrwert, aber das kann man gerne hier zur Diskussion stellen und jeder kann das ja bereits jetzt für sich an oder abwählen.

[gyle]

@arnod ggf. verständnisproblem meinerseits...
ich hatte gedacht, dass das S10 die daten bereits intern speichert und dann an das portal schickt...
wenn die daten dort lägen, dann fände ich es eleganter diese aggregation nur auszulesen und im iobroker anzuzeigen.
ansonsten ist die zb sekündliche aufzeichnung ja relativ "teuer" und erzeugt viel last auf meinem raspi...
derzeit zeichne ich das auch per modus/history auf, aber ich dachte, ich könnte das damit umgehen...

[git-kick]

@gyle
Nach meinem Verständnis ist es genau so wie du annimmst: die 15-minütigen Datenpunkte/Aggregationen entstehen in der E3/DC und werden vom Portal abgezogen. Und genau das kannst du auch (ohne Portal und ohne eigene Zeitreihendatenbank) tun: stelle TIME_START, TIME_SPAN und TIME_INTERVAL ein und du wirst im Objektbaum die entsprechenden Datenpunkte sehen. Allerdings ist das Datenformat etwas "schräg" (nur relative Zeitachse), weshalb ich im Adapter einen errechneten Timestamp ergänze.

[gyle]

@ujok ok danke - ich wusste nicht dass ich das damit triggern muss.
habe es mir jetzt mal angesehen und stelle mir nochmal folg frage:

• wenn ich die Daten bspw. in einer Visualisierung anzeigen will - dann muss ich die Daten jedesmal neu triggern, oder?
• TIME_INTERVAL > 900 sek = 15 min. > weniger geht hier nicht, weil das S10 auch nur in diesem Intervall speichert, oder?

[ArnoD]

@gyle
Wenn ich dir auch die Fragen beantworten darf:

1. Immer, wenn du aktuelle Daten haben willst, musst du neu triggern.
2. richtig < 900 sek. geht nicht.

ansonsten ist die zb sekündliche aufzeichnung ja relativ "teuer" und erzeugt viel last auf meinem raspi...
derzeit zeichne ich das auch per modus/history auf, aber ich dachte, ich könnte das damit umgehen...

Warum das teuer sein soll verstehe ich jetzt nicht ganz, aber mit der Last gebe ich dir recht.
Für mich ist aber genau die hohe Abtastrate wichtig (es reichen auch 4 sek.), da nur so Fehler zu erkennen sind.
Als Beispiel ist beim E3DC sporadisch immer Abends die Batterie für 5 bis10 sek. Ausgefallen, was ich nicht bemerkt hätte, nur mit den Aufzeichnungen im Portal.
Das wurde dann von E3DC mit einem Update behoben.

[Matis]

@ujok
„ I tried setting EP_RESERVE, but the S10 returned a weird container with a random index and value -1.
So I removed the setter code.“

Aus der Historie der Anlagen habe ich die Vermutung, dass EP_Reserve nicht eine Watthzahl ist sondern 0-50%.
Denn so war es am Anfang auch angezeigt und musste auch so eingegeben werden und wurde erst später als Wh angezeigt.
Ich könnte mir gut vorstellen, dass es im Hintergrund weiter die % sind.

Also 0-50 % von Gesamtbatteriekapa.
Was hattest Du denn als Eingabewerte ausprobiert?

[git-kick]

@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:

@ujok
„ I tried setting EP_RESERVE, but the S10 returned a weird container with a random index and value -1.
So I removed the setter code.“

Aus der Historie der Anlagen habe ich die Vermutung, dass EP_Reserve nicht eine Watthzahl ist sondern 0-50%.
Denn so war es am Anfang auch angezeigt und musste auch so eingegeben werden und wurde erst später als Wh angezeigt.
Ich könnte mir gut vorstellen, dass es im Hintergrund weiter die % sind.

Also 0-50 % von Gesamtbatteriekapa.
Was hattest Du denn als Eingabewerte ausprobiert?

siehe Issue#89

[ArnoD]

@ujok
Habe die Version 1.0.4 getestet und es werden wieder beide Batteriekreise angezeigt :+1: :-)

[git-kick]

@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:

@ujok
Habe die Version 1.0.4 getestet und es werden wieder beide Batteriekreise angezeigt :+1: :-)

siehe Issue#96

[ArnoD]

Funktioniert bei euch die regelmäßige Abfrage von "e3dc-rscp.0.EMS.POWER_PV" ?
Bei mir wird nur beim Start vom Adapter der Wert eine Zeit lang aktualisiert und dann aber nicht mehr.

Kann jetzt aber auch sein, dass bei mir was mit dem Testen der Version 1.0.4 durcheinander gekommen ist.

[TbsJah]

@arnod Das selbe bei mir auch
Gilt für alle Power Einträge