Closed jnk-cons closed 9 months 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: @. @.> >
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 ;)
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: @. @.> >
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
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: @. @.> >
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?
Ja, im Container TAG_EMS_IDLE_PERIOD
musst du das Tag TAG_EMS_IDLE_PERIOD_ACTIVE
mit Wert true
mitgeben.
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
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.
@git-kick Ich wollte das Dicket gar nicht schließen :( ... SIehe letzten Kommentar
Ich kenne keinen globalen Schalter für IDLE_PERIODS. Bei mir sieht es in der E3/DC App so aus: Da ist eine Checkbox je PERIOD, aber kein globaler Schalter.
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.
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.
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