discussion: extend the dtugateway to a "wifi-dtu" #21
Comments
|
Hi @Lassa333, würde die Diskussion mal in deutsch starten, mit ein wenig mehr Text ;-) Erstmal eingangs, warum habe ich mit dem Projekt gestartet... Frage 2 war dann, wenn schon per WLAN direkt erreichbar, warum nicht direkt vom Raspberry aus, da hier schon mein SmartHome (Openhab) drauf läuft. Damit hatte ich auch ein grundsätzliche Möglichkeit (Lösung in python). In der Anfangsphase hatte ich aber öfters das Problem, das ich die DTU "aus meinem Wifi abgeschossen" habe und damit manuell über die App ("Einbuchen" im AP der DTU und Wifi-Registrierung durchlaufen) wieder im eigenen Wifi anmelden musste... Daher dann die Idee das Ganze auf einem ESP zu migirieren, um hier ein stabiles Basissystem zu haben und ggfs. dann diesen manuellen Vorgang auch auf dem ESP zu realisieren. Also selbständig in den AP zu wechseln die Wiederanmeldung am eigenen Wifi durchzuführen und wieder in den Normalmodus zurück zu kehren. (aktuell nicht implementiert und ebenso nicht "reverse engineered") Damit war dtuGateway geboren und dieses hatte "nur" das Ziel die hoymiles DTU für eine SmartHome-Anwendung mit gängigen APIs zu abstrahieren, sowie die Verbindung so stabil wie möglich zu machen. Daher ein paar Fragen zur weiteren Ausrichtung:
Grundsätzlich könnte man das Projekt aufbohren, wird aber aufgrund des "mal eben schnell zusammen gezimmert" zügig an den Moment des grossen Refactorings rutschen... Daher bin ich erstmal auf die Meinungen gespannt... Gruss |
|
Hallo Andreas,
ich finde Deinen Vorschlag, auf Deutsch weiterzumachen prima 😊 Und auch mehr Worte finde ich gut – reden hilft hab ich mir mal sagen lassen
Danke, dass du mich abgeholt hast, was den Nutzen des Projektes angeht. Ich bin tief beeindruckt, was du hinbekommen hast! Ich selbst habe mal vor Jahren mit Arduinos rumgespielt – bin aber nie an den Wissensstand gekommen, mit dem Dein Projekt voran getrieben worden ist.
Ich bin auch neu in der Balkon-Solar-Welt. Tatsächlich habe ich meins vor 5 Wochen erst in Betrieb genommen. Da ich im Vorfeld viel Zeit hatte (mußte auf die Eigentümer-Versammlung warten), habe ich mich intensiv belesen. Gerade auch in Richtung, Werte aus dem Wechselrichter auslesen und weiter verarbeiten. Nach diesen Vorinfos habe ich dann mein Kraftwerkt bestellt. Und zwar eins mit einem HMS-800-2T. Bekommen habe ich aber einen HMS-800W-2T. 🤬
Nun saß ich da und mußte meine Pläne anpassen. Da bin ich auf Dein Gateway gestoßen – und habe gedacht, jetzt noch MQTT und dann kann ich die Werte in mein SmartHome-System (Homeassistant) reinholen. Das hat ja bekanntlich super funktioniert 😊 (An dieser Stelle nochmals „DANKE“)
Zum jetzigen Zeitpunkt bin ich mit dem Setup super zufrieden. Aber es geht ja auch noch besser. Und (zumindest ist das mein Eindruck) gibt es zunehmend nur noch die WIFI-Variante von HM auf dem Markt. Also wird es noch so einige Leidgenossen mit dem „WIFI-Problem“ geben. Viele werden auch feststellen, dass openDTU oder AhoyDTU da auch nicht weiterhelfen. An dieser Stelle möchte ich auf Deine Fragen eingehen:
1. Welchen Grund gibt es für Euch, das diese Abstraktion auf einem eigenen Gerät (ESPxx) laufen sollte und nicht als "binding" jeweils für die diversen smarthome-Umgebungen integriert wird?
Für mich ist die Frage einfach: Wer kein Smart-Home-System (egal welches) betreibt, ist auf die HM-Cloud angewiesen. Nur so kann man die Werte des Wechselrichters gut auslesen. Die Cloud funktioniert auch gut – ist aber in China. Da hab (zumindest ich) große Bedenken. Deswegen werde ich mich kurzfristig aus der China-Cloud zurückziehen.
2. Wäre es nicht besser, diese Art der Verbindungsmöglichkeit (direkt im wifi über ProtoBuf wie in dtuGateway ) direkt in openDTU oder AhoyDTU zu implementiert? (da diese Projekte auch um Längen weiter sind, bzgl. Feature-Umfang)
Diese Frage finde ich total berechtigt. Den Weg, das Gateway in seiner jetzigen (gut funktionierenden Form) zu einem weiteren DTU voranzubringen, ist m.E. nicht gerade kurz und un-steinig. Zumal ich leider kein substantiellen Betrag bieten kann (außer ich bekomme eine „Schnell-Bleiche was das Arbeiten mit Platformio angeht 😉). Von dem her könnte ich es gut verstehen, wenn du die Entscheidung triffst, den Weg nicht zu gehen (Würde mich dann aber sehr freuen, wenn du dann den Kollegen von Ahoy oder openDTU zumindest Deinen Weg zeigst, so dass die Funktionalität in eine der genannten DTUs aufgenommen werden kann)
3. Bezug auf Erweiterung dtuGateway Was wären denn ganz grob weitere Features neben (HomeAssistant AutoDiscovery und OLED Anzeige) die in diesem Rahmen "sinnvoll" ;-) denkbar wären?
* Aus meiner Sicht wäre noch schön, wenn der gleiche Microprozessor (ESP32) wie bei open und AhoyDTU zum Einsatz käme. Dies nur, damit ggf. ein Umstieg ohne den Kauf neuer Hardware gemeistert werden kann.
* Die Null-Einspeisung juckt mich auch in den Fingern. Aber (soweit ich gelesen haben) scheint es wohl so zu sein, dass vielmaliges Schreiben in den EEPROM (z.B. Anpassung der Leistungsgrenze) diesen irgendwann beschädigt. Dann muss ein neuer Inverter her. Deswegen würde ich damit noch zuwarten
Soviel meine Gedanken zu Deiner Mail. Ich hoffe, diese waren erhellend. Ich würde mich freuen, wenn wir diesen Austausch weiter voran treiben würden
Bis dahin
LG
Roland (Lassa333)
Von: Andreas ***@***.***>
Gesendet: Dienstag, 28. Mai 2024 15:03
An: ohAnd/dtuGateway ***@***.***>
Cc: Lassa333 ***@***.***>; Mention ***@***.***>
Betreff: Re: [ohAnd/dtuGateway] discussion: extend the dtugateway to a "wifi-dtu" (Issue #21)
Hi @Lassa333 <https://github.com/Lassa333> ,
würde die Diskussion mal in deutsch starten, mit ein wenig mehr Text ;-)
Erstmal eingangs, warum habe ich mit dem Projekt gestartet...
Wie viele von Euch hatte ich keine Möglichkeit den Inverter für eine SmartHome-Anwendung verfügbar zu machen, um in meinem Fall mit Nulleinspeisung zu experimentieren. D.h. ich brauchte ein Möglichkeit wie ich die Daten vom Inverter lesen kann und das Leistungsverhältnis vom Inverter aktiv beeinflussen kann.
Frage 2 war dann, wenn schon per WLAN direkt erreichbar, warum nicht direkt vom Raspberry aus, da hier schon mein SmartHome (Openhab) drauf läuft. Damit hatte ich auch ein grundsätzliche Möglichkeit (Lösung in python). In der Anfangsphase hatte ich aber öfters das Problem, das ich die DTU "aus meinem Wifi abgeschossen" habe und damit manuell über die App ("Einbuchen" im AP der DTU und Wifi-Registrierung durchlaufen) wieder im eigenen Wifi anmelden musste...
Daher dann die Idee das Ganze auf einem ESP zu migirieren, um hier ein stabiles Basissystem zu haben und ggfs. dann diesen manuellen Vorgang auch auf dem ESP zu realisieren. Also selbständig in den AP zu wechseln die Wiederanmeldung am eigenen Wifi durchzuführen und wieder in den Normalmodus zurück zu kehren. (aktuell nicht implementiert und ebenso nicht "reverse engineered")
Gleichzeitig auch der Reiz ein vollständiges Projekt auf dem ESP aufzubauen, was mir für weitere Projekte eine Grundlage schafft.
Damit war dtuGateway geboren und dieses hatte "nur" das Ziel die hoymiles DTU für eine SmartHome-Anwendung mit gängigen APIs zu abstrahieren, sowie die Verbindung so stabil wie möglich zu machen.
Daher ein paar Fragen zur weiteren Ausrichtung:
1. Welchen Grund gibt es für Euch, das diese Abstraktion auf einem eigenen Gerät (ESPxx) laufen sollte und nicht als "binding" jeweils für die diversen smarthome-Umgebungen integriert wird?
2. In den o.g. Projekten habe ich noch nicht tief reingeschaut, aber beide, meine ich, sind aus dem grundsätzlich gleichen Grund gestartet, hier aber explizit, als HW-Abstraktion aufgrund der anderen Funkverbindung, die hier eigene HW notwendig macht. Daher die mglw. aktuell noch offene Frage, ob diese Art der Verbindungsmöglichkeit (direkt im wifi über ProtoBuf wie in dtuGateway ) direkt implementiert werden kann und damit der kürzere Weg wäre, um die bereits vorhandenen Features in Richtung SmartHome-Umgebung (HomeAssistant, etc) zu erhalten? (da diese Projekte auch um Längen weiter sind, bzgl. Feature-Umfang)
3. In Bezug auf Erweiterung dtuGateway Was wären denn ganz grob weitere Features neben (HomeAssistant AutoDiscovery und OLED Anzeige) die in diesem Rahmen "sinnvoll" ;-) denkbar wären?
Grundsätzlich könnte man das Projekt aufbohren, wird aber aufgrund des "mal eben schnell zusammen gezimmert" zügig an den Moment des grossen Refactorings rutschen... Daher bin ich erstmal auf die Meinungen gespannt...
Gruss
—
Reply to this email directly, view it on GitHub <#21 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIETLPBVJW4GH7OKRD7EP7DZER57JAVCNFSM6AAAAABIIUUKX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVGE3DIMZUHA> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/BIETLPHS74KYJR4ZKRE7FCLZER57JA5CNFSM6AAAAABIIUUKX2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT7IQC3Y.gif> Message ID: ***@***.*** ***@***.***> >
|
|
Hi @Lassa333 - Roland, danke für die ausführlichen Rückmeldungen! (so wird es für alle transparent...) D.h. beim Display "juckt es mir schon in den Fingern", da es schon lange her ist, dass ich mal eines angesteuert habe. Hier würde ich auch mal mit dem von dir vorgeschlagenen OLED anfangen. Bzgl. ESP32 habe ich in einem Seitenbranch (link - artefacts) mal die ersten Versuche unternommen, den Code zu portieren bzw. vorübergehend in MultiArch auszulegen. Im Zuge der Stabilisierung bin ich hier mit dem SingleCore des ESP8266 auch an gewisse Grenzen gestossen ... daher schaue ich auf jeden Fall nun auch in die ESP32 Richtung - zumal die Preise nur minimal höher liegen als beim ESP8266, aber der DualCore viele Möglichkeiten bzgl. asynchronem Handling bietet. Das HA MQTT AutoDiscovery von @smarthomehomebase Daniel würde ich mal auf der Liste lassen. Bin die Specs mal überflogen und für mich wirkt es im ersten Moment ein wenig "oversized", aber vielleicht ist das auch nur mein erster Eindruck. Was hier mehr interessant ist, das das Thema QoS mit behandelt wird, wo ich dann später mal tiefer eintauchen würde. Hier bin ich dann aber voll auf das Testing Eurerseits angewiesen, da ich wie gesagt HA nicht am Laufen habe und eine Extra-Testinstanz inkl. Einarbeitung den Aufwand extrem treiben würde... (als jahrelanger Nutzer von OpenHab (V1 aufwärts ;-) ) - dazu dann aber später... So far... BR |
|
Hi Andreas,
danke für Deine schnelle Rückantwort. Und auch, dass du dich entschieden hast, das Projekt mit unseren Inputs weiter zu führen. Zumindest ich möchte dich dabei nach Kräften unterstützen!
Dementsprechend werde ich heute meinen bestehenden Test-Setup (ESP8266 + OLED) auf den ESP32 umrüsten.
Vor einiger Zeit habe ich bei AhoyDTU nachgeschaut, wie dort das OLED angesteuert wird. Dabei habe ich folgendes gefunden:
* Dort wird ein ESP32 WROOM32 (38 Pins) eingesetzt
* OLED ein SH 1106
* Bibliothek zur Display-Ansteuerung: U8g2 von Olli Kraus (https://github.com/olikraus/U8g2_Arduino)
Das OLED wurde wie folgt angeschlossen:
Display SCL -> Pin G22
Display SDA -> Pin G21
Genau so werde ich meinen Setup auslegen, weil ich denke, dass dies ein guter „Grundsetup“ auch für sein dürfte.
LG
Lassa333 >
|
|
Hi Andreas,
trotz meiner Versuche, mich in Platformio einzuarbeiten, komme ich nicht weiter. Ich scheitere beim Kompilieren der neuen Firmware(n) ☹
Kannst du mir eine *.bin Version zur Verfügung stellen?
Danke
Lassa333
Von: Andreas ***@***.***>
Gesendet: Donnerstag, 30. Mai 2024 17:20
An: ohAnd/dtuGateway ***@***.***>
Cc: Lassa333 ***@***.***>; Mention ***@***.***>
Betreff: Re: [ohAnd/dtuGateway] discussion: extend the dtugateway to a "wifi-dtu" (Issue #21)
Hi @Lassa333 <https://github.com/Lassa333> - Roland,
danke für die ausführlichen Rückmeldungen! (so wird es für alle transparent...)
Ich würde mal in kleinen Schritten voran gehen und gucken was kommt ;-)
D.h. beim Display "juckt es mir schon in den Fingern", da es schon lange her ist, dass ich mal eines angesteuert habe. Hier würde ich auch mal mit dem von dir vorgeschlagenen OLED anfangen.
Bzgl. ESP32 habe ich in einem Seitenbranch (link <https://github.com/ohAnd/dtuGateway/tree/migrate_ESP32> - artefacts <https://github.com/ohAnd/dtuGateway/actions/runs/9304152657> ) mal die ersten Versuche unternommen, den Code zu portieren bzw. vorübergehend in MultiArch auszulegen. Im Zuge der Stabilisierung bin ich hier mit dem SingleCore des ESP8266 auch an gewisse Grenzen gestossen ... daher schaue ich auf jeden Fall nun auch in die ESP32 Richtung - zumal die Preise nur minimal höher liegen als beim ESP8266, aber der DualCore viele Möglichkeiten bzgl. asynchronem Handling bietet.
Das HA MQTT AutoDiscovery von @smarthomehomebase <https://github.com/smarthomehomebase> Daniel würde ich mal auf der Liste lassen. Bin die Specs mal überflogen und für mich wirkt es im ersten Moment ein wenig "oversized", aber vielleicht ist das auch nur mein erster Eindruck. Was hier mehr interessant ist, das das Thema QoS mit behandelt wird, wo ich dann später mal tiefer eintauchen würde. Hier bin ich dann aber voll auf das Testing Eurerseits angewiesen, da ich wie gesagt HA nicht am Laufen habe und eine Extra-Testinstanz inkl. Einarbeitung den Aufwand extrem treiben würde... (als jahrelanger Nutzer von OpenHab (V1 aufwärts ;-) ) - dazu dann aber später...
So far...
BR
—
Reply to this email directly, view it on GitHub <#21 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIETLPBTPSRSHJ4RDXRTKIDZE47QLAVCNFSM6AAAAABIIUUKX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZZHEYTCMZXHE> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/BIETLPGZCNGPTYMEE2Z2U3LZE47QLA5CNFSM6AAAAABIIUUKX2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT7RR2NG.gif> Message ID: ***@***.*** ***@***.***> >
|
|
Hi @Lassa333 , wenn du dem o.g. Link zu artefacts folgst findest du im unteren Bereich die Downloads - im ZIP sind dann die kompilierten .bin-files jeweils für ESP8266 und ESP32. Aber wie oben schon geschrieben - ist "blind" konvertiert, da meine 32er noch im Zulauf sind ;-) BR btw. versuch mal bitte bei Antwort über Mail den zitierten Text zu löschen, es wird sonst immer schwerer die eigentliche Antwort zu entdecken ;-) |
|
Hi,
das hat mich weitergebracht – danke 😊
Also, folgende aller erste Rückmeldung:
* Zum Flashen der *.bin musste ich auf den „boot“ Knopf des Boards drücken – dann gings aber
* Ein Wlan („hoymilesGW_xxxxxxxx“) wird aufgespannt, jedoch scheint ein stabiler Zugang zu diesem Wlan (noch) nicht möglich zu sein: ich kann es im Handy zwar anwählen, jedoch wird die Verbindung sofort abgebrochen.
Für den ersten „Blindversuch“ ohne die entsprechende Hardware vorliegen zu haben also richtig gut – Respekt !
Bin schon sehr gespannt, wo dieser Weg weiter hinführt
LG
Von: Andreas ***@***.***>
Gesendet: Samstag, 1. Juni 2024 11:07
An: ohAnd/dtuGateway ***@***.***>
Cc: Lassa333 ***@***.***>; Mention ***@***.***>
Betreff: Re: [ohAnd/dtuGateway] discussion: extend the dtugateway to a "wifi-dtu" (Issue #21)
Hi @Lassa333 <https://github.com/Lassa333> ,
wenn du dem o.g. Link zu artefacts folgst findest du im unteren Bereich die Downloads - im ZIP sind dann die kompilierten .bin-files jeweils für ESP8266 und ESP32.
Aber wie oben schon geschrieben - ist "blind" konvertiert, da meine 32er noch im Zulauf sind ;-)
BR
—
Reply to this email directly, view it on GitHub <#21 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIETLPFDHB2BLC42UGBR3K3ZFGFKRAVCNFSM6AAAAABIIUUKX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGM3TCOJQGQ> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/BIETLPDFJNH2RAJKPETFLBDZFGFKRA5CNFSM6AAAAABIIUUKX2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT7YFBIA.gif> Message ID: ***@***.*** ***@***.***> >
|
While contributing to your brilliant work on your dtuGateway, I realised that your gateway is not fare away from existing dtu (e.g. openDTU or AhoyDTU) – but with the WIFI-component. So after the slick adding of the MQTT-functionality, I want to ask you a question:
Are you interested in setting up a “WIFI-dtu”?
I would love to hear your thoughts about this
BR
Roland
Originally posted by @Lassa333 in #11 (comment)
The text was updated successfully, but these errors were encountered: