git-kick / ioBroker.e3dc-rscp

Manage E3/DC power station based on RSCP
GNU General Public License v3.0
26 stars 9 forks source link

RSCP Support -> Zusammenarbeit #173

Closed jnk-cons closed 9 months ago

jnk-cons commented 1 year ago

Moin,

vorweg einmal ein ordentliches Lob an den Adapter. Sauber zusammengestellt!

Warum schreibe ich? Ich arbeite aktuell an einer Software um die Hauskraftwerke besser zu nutzen. Besser in der Form, dass das Batterieladeverhalten optimiert wird um die Lebenszeit zu verlängern, eine Tibber API anzubinden um besser und automatisch entscheiden zu können was wirtschaftlicher ist usw usw.

Allerdings habe ich wirklich ordentlich mit dem RSCP Protokoll zu kämpfen. Vieles bereits mit Try/Error herausgefunden, aber ein paar Dinge sind mir hier tatsächlich unklar.

Daher suche ich Unterstützung, einen Sammelpunkt oder ähnliches, wo die OpenSource Community mal ihre Informationen zusammentragen kann, um das Protkoll besser zu verstehen.

Besteht hier grundsätzlich Interesse an so etwas? Mein RSCP Wissen ist sicherlich deutlich geringer, da die reine Kommunikation mit dem Hauskraftwerk nur einen kleinen Teil meiner Software ausmacht, aber irgendwie würde ich gerne mehr know aufbauen und das auch anderen zur Verfügung stellen.

Vielen Dank Jochen

git-kick commented 1 year ago

Hallo Jochen,

das ist eine gute Idee, zumal vom E3/DC-Hersteller kaum Aktualisierungen kommen.

Also, ich würde schon meinen Teil beitragen, wenn es dazu ein Forum gäbe – allerdings, abhängig von meinem Hauptberuf, mit begrenztem Zeitkontingent und ohne Antwort(zeit)garantie…

Gerne wüsste ich noch, ob Dein Projekt auch Open Source ist und wie es heißt. Wenn es etwas Kommerzielles ist, wäre wohl auch hier ein Bezahlmodell (Beratung) angebrachter.

Viele Grüße

Uli

Von: Jochen Zink @.> Gesendet: Montag, 7. August 2023 16:50 An: git-kick/ioBroker.e3dc-rscp @.> Cc: Subscribed @.***> Betreff: [git-kick/ioBroker.e3dc-rscp] RSCP Support -> Zusammenarbeit (Issue #173)

Moin,

vorweg einmal ein ordentliches Lob an den Adapter. Sauber zusammengestellt!

Warum schreibe ich? Ich arbeite aktuell an einer Software um die Hauskraftwerke besser zu nutzen. Besser in der Form, dass das Batterieladeverhalten optimiert wird um die Lebenszeit zu verlängern, eine Tibber API anzubinden um besser und automatisch entscheiden zu können was wirtschaftlicher ist usw usw.

Allerdings habe ich wirklich ordentlich mit dem RSCP Protokoll zu kämpfen. Vieles bereits mit Try/Error herausgefunden, aber ein paar Dinge sind mir hier tatsächlich unklar.

Daher suche ich Unterstützung, einen Sammelpunkt oder ähnliches, wo die OpenSource Community mal ihre Informationen zusammentragen kann, um das Protkoll besser zu verstehen.

Besteht hier grundsätzlich Interesse an so etwas? Mein RSCP Wissen ist sicherlich deutlich geringer, da die reine Kommunikation mit dem Hauskraftwerk nur einen kleinen Teil meiner Software ausmacht, aber irgendwie würde ich gerne mehr know aufbauen und das auch anderen zur Verfügung stellen.

Vielen Dank Jochen

— Reply to this email directly, view it on GitHub https://github.com/git-kick/ioBroker.e3dc-rscp/issues/173 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEE4SQF7FDRRMO3C6CLBD3XUD6DBANCNFSM6AAAAAA3HDS3NI . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ACEE4SRJQE7FC5O64JOXZOLXUD6DBA5CNFSM6AAAAAA3HDS3NKWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHG3JUGD4.gif Message ID: @. @.> >

jnk-cons commented 1 year ago

Das klingt doch schon mal klasse.

Habe mir sowas wie ein Repository mit kurzer und einfacher Dokumentation auf fachlicher Basis vorgestellt. Also, möglichst Technologieunabhängig. Es gibt so viele SmartHome Hubs, Lösungen usw. die durch kleine Apps massiv aufgewertet werden. Und diese Art von nicht-standard Protokollen macht einfach allen das Leben schwer.

Wie gesagt, wenn man was einfaches hat um das Protokoll näher zu beschreiben, vielleicht ein paar Beispiele und 2-3 Tools dazu, wird es für die Leute einfacher.

Zu meinem Projekt:

Entstanden ist es erstmal aus dem Wunsch heraus, mein Hauskraftwerk besser zu verwaltet. Das bedeutet im SmartHome auf die aktuellen Werte zu reagieren. Dazu kommt der Wunsch das Ladeverhalten zu optimieren, dass Wetterbasierte Laden von E3DC funktioniert einfach ... schlecht. Bisher war das ein privaten Projekt. Ich habe das was da ist, bereits an ein paar andere weitergegeben, die ebenfalls ihr E3DC System auslesen/steuern wollen. Alles mit ein wenig zähneknirschen, weil nicht fertig, man etwas bastelwissen für das Setup braucht und es einfach auf meine persönlichen Needs abgestimmt ist.

Aber: Aktuell plane ich quasi ein Reset des Projekts als Opensource, das ganze in mehrere Module aufgeteilt, damit man nicht ein e3dc System braucht, sondern jedes andere, mit dem passenden Adapter ebenfalls damit arbeiten würde usw.

Ein guter Freund hat mich dann auf die Idee mit Tibber und ähnlichen Anbietern gebracht.

Aktuell ist es ein SpringBoot Rest Service, der eine API bereit stellt und hinten raus per RSCP mit dem HK arbeitet. Vorne gibt es aktuell eine kleine Homey App, zur EInbindung ins Smarthome. Alles noch sehr auf meinen case, dass stelle ich gerade um.

Soweit erstmal als Kickoff ;)

git-kick commented 1 year ago

Danke für die ausführliche Info, ein interessantes Projekt.#

Also ich bin dabei, wenn es Diskussionen zu RSCP gibt.

VG, Uli

Von: Jochen Zink @.> Gesendet: Montag, 7. August 2023 18:38 An: git-kick/ioBroker.e3dc-rscp @.> Cc: Uli Kick @.>; Comment @.> Betreff: Re: [git-kick/ioBroker.e3dc-rscp] RSCP Support -> Zusammenarbeit (Issue #173)

Das klingt doch schon mal klasse.

Habe mir sowas wie ein Repository mit kurzer und einfacher Dokumentation auf fachlicher Basis vorgestellt. Also, möglichst Technologieunabhängig. Es gibt so viele SmartHome Hubs, Lösungen usw. die durch kleine Apps massiv aufgewertet werden. Und diese Art von nicht-standard Protokollen macht einfach allen das Leben schwer.

Wie gesagt, wenn man was einfaches hat um das Protokoll näher zu beschreiben, vielleicht ein paar Beispiele und 2-3 Tools dazu, wird es für die Leute einfacher.

Zu meinem Projekt:

Entstanden ist es erstmal aus dem Wunsch heraus, mein Hauskraftwerk besser zu verwaltet. Das bedeutet im SmartHome auf die aktuellen Werte zu reagieren. Dazu kommt der Wunsch das Ladeverhalten zu optimieren, dass Wetterbasierte Laden von E3DC funktioniert einfach ... schlecht. Bisher war das ein privaten Projekt. Ich habe das was da ist, bereits an ein paar andere weitergegeben, die ebenfalls ihr E3DC System auslesen/steuern wollen. Alles mit ein wenig zähneknirschen, weil nicht fertig, man etwas bastelwissen für das Setup braucht und es einfach auf meine persönlichen Needs abgestimmt ist.

Aber: Aktuell plane ich quasi ein Reset des Projekts als Opensource, das ganze in mehrere Module aufgeteilt, damit man nicht ein e3dc System braucht, sondern jedes andere, mit dem passenden Adapter ebenfalls damit arbeiten würde usw.

Ein guter Freund hat mich dann auf die Idee mit Tibber und ähnlichen Anbietern gebracht.

Aktuell ist es ein SpringBoot Rest Service, der eine API bereit stellt und hinten raus per RSCP mit dem HK arbeitet. Vorne gibt es aktuell eine kleine Homey App, zur EInbindung ins Smarthome. Alles noch sehr auf meinen case, dass stelle ich gerade um.

Soweit erstmal als Kickoff ;)

— Reply to this email directly, view it on GitHub https://github.com/git-kick/ioBroker.e3dc-rscp/issues/173#issuecomment-1668232883 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEE4SXK7SIJSHF7AA6IO7DXUEKWZANCNFSM6AAAAAA3HDS3NI . You are receiving this because you commented. https://github.com/notifications/beacon/ACEE4SRZGEFUDRLEQUBTXGLXUEKWZA5CNFSM6AAAAAA3HDS3NKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTDN43LG.gif Message ID: @. @.> >

jnk-cons commented 11 months ago

So, viele Stunden später ...

ich hab einen ersten Wurf gestartet: https://github.com/jnk-cons/easy-rscp

das ist erstmal "nur" eine Kotlin lib, mit einer ausführlichen Doku. Auch zum Thema RSCP. Als nächstes möchte ich eine Trainings applikation schreiben. Ziel wäre, dass man sich im webfrontend die RSCP Requests zusammen klicken kann, direkt absenden und man bekommt dann die ganze Sch... mit den bytes etc. pp. augeschlüsselt. tbc

git-kick commented 11 months ago

Schönes Repo, super strukturiert!

Ich habe mal ein Issue RSCP#1 angelegt – passt das so?

Anregung: schön wäre es, auf jeder Doku-Seite einen direkten Link zu „New Issue“ zu haben. Geht aber auch in einem zweiten Tab.

Viele Grüße

Uli

Von: Jochen Zink @.> Gesendet: Donnerstag, 21. September 2023 22:04 An: git-kick/ioBroker.e3dc-rscp @.> Cc: Uli Kick @.>; Comment @.> Betreff: Re: [git-kick/ioBroker.e3dc-rscp] RSCP Support -> Zusammenarbeit (Issue #173)

So, viele Stunden später ...

ich hab einen ersten Wurf gestartet: https://github.com/jnk-cons/easy-rscp

das ist erstmal "nur" eine Kotlin lib, mit einer ausführlichen Doku. Auch zum Thema RSCP. Als nächstes möchte ich eine Trainings applikation schreiben. Ziel wäre, dass man sich im webfrontend die RSCP Requests zusammen klicken kann, direkt absenden und man bekommt dann die ganze Sch... mit den bytes etc. pp. augeschlüsselt. tbc

— Reply to this email directly, view it on GitHub https://github.com/git-kick/ioBroker.e3dc-rscp/issues/173#issuecomment-1730223109 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEE4STQJUOSQ5GPHCYNVIDX3SMTTANCNFSM6AAAAAA3HDS3NI . You are receiving this because you commented. https://github.com/notifications/beacon/ACEE4SUZE3MAZGXIK2MCLITX3SMTTA5CNFSM6AAAAAA3HDS3NKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTHEEOAK.gif Message ID: @. @.> >

jnk-cons commented 11 months ago

Hi @git-kick,

sag mal, weißt du wie man die IdlePeriods aktiviert? Ich kann die komplett lesen und schreiben. Aber ich bekomme sie nicht aktiviert. Gibt es dazu einen extra Tag?

git-kick commented 11 months ago

Ja, im Container TAG_EMS_IDLE_PERIOD musst du das Tag TAG_EMS_IDLE_PERIOD_ACTIVE mit Wert true mitgeben.

jnk-cons commented 11 months ago

Oh man, ich hab den Tag nur zum aktivieren/deaktivieren der einzelenen periods gesehen und nicht vom ganzen Block. Das probier ich nachher mal aus. Danke

jnk-cons commented 11 months ago

Ok, ich glaube es war noch ein Missverständnis.

Man kann ja jede einzelne IdlePeriod aktivieren/deaktivieren. Also, zum Beispiel Montags, 15-17 Uhr Ladesperrung, aktiv/inaktiv. Das funktioniert.

Im System gibt es aber noch einen globalen Schalter, der die gesamte Funktion aktiviert/deaktiviert. Den bekomme ich weder gelesen, noch geschrieben.

Mit einer EMS.REQ_GET_IDLE_PERIODS Anfrage, bekomme ich als Antwort einen Block mit Tag EMS.GET_IDLE_PERIODS, der eine Liste von EMS.IDLE_PERIOD Blöcken enthält. Hier ist aktiv/inaktiv klar zu erkennen und umgekehrt auch wieder zu schreiben. Aber den globalen Schalter.... den finde ich irgendwie nicht.

jnk-cons commented 11 months ago

@git-kick Ich wollte das Dicket gar nicht schließen :( ... SIehe letzten Kommentar

git-kick commented 11 months ago

Ich kenne keinen globalen Schalter für IDLE_PERIODS. Bei mir sieht es in der E3/DC App so aus: Screenshot_20231002-221627 Da ist eine Checkbox je PERIOD, aber kein globaler Schalter.

jnk-cons commented 11 months ago

In der App habe ich diesen Schalter auch nicht. Aber am Hauskraftwerk.

Wenn ich die Sperrzeiten per RSCP konfiguriere, kann ich zwar jede einzele Periode dort sehen, aktivieren usw. Aber über den globalen Schalter sind sie deaktiviert. Und ich finde nicht raus, wie der Schalter gesetzt wird.

Grün ist aktiviert, rot deaktiviert. Das schaffe ich aber nur direkt am Hauskraftwerk.

IMG_0506 IMG_0507

git-kick commented 10 months ago

Leider ist REQ_SET_IDLE_PERIODS nicht weiter dokumentiert. Denkbar ist, dass es hier einen "globalen Schalter" gibt, den man im Container einbetten kann: muss man raten oder bei Fa. Hager erfragen (letzteres hat meines Wissens bisher nicht geholfen). Vielleicht mal probieren, ein TAG_EMS_IDLE_PERIOD_ACTIVE im TAG_EMS_REQ_SET_IDLE_PERIODS-Container zu senden (aktuell sende ich TAG_EMS_IDLE_PERIOD_ACTIVE im untergeordneten TAG_EMS_IDLE_PERIOD-Container, also je Periode).

@jnk-cons, ich würde gerne #173 mit Ende dieser Diskussion schließen und für weitere Themen jeweils ein neues Issue anlegen, weil das besser für den Überblick ist.