Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?

Claus T. schrieb:
> Irgendwie gibt es wohl ab der Version 0.5.xx ein Problem mit der
> Formatierung/Partitionierung des Flashlayouts? Oder dem Zugriff auf den
> Speicherbereiche der Default Werte?

Ähnliches bei mir. Habe gerade über OTA auf die 0.5.14 geflasht und die 
Inverter-Einstellungen werden nicht übernommen. Wenn ich auf Save klicke 
und die Seite neugeladen hat, sind die Einträge wieder weg. Erase all 
Settings schafft keine Abhilfe.

Jetzt habe ich 0.5.14 zum laufen bekommen.
Eigentlich lief er, nur das automatische Anmeldefenster kam nicht. Mit 
192.168.x.1 konnte ich es aufrufen und WiFi einstellen.

Aber in 0.5.14 werden bei mir auch die Invertereinstellungen nicht 
gespeichert!

Ich konnte aber von 0.5.14 auf 0.5.13 per OTA gehen (dabei blieben die 
WiFi Einstellungen erhalten) und in der Version übernimmt er die 
Invertereinstellungen.

Die 0.5.14 hat aber z.B. die Einstellung für den NRF24 übernommen, nur 
die Invertereinstellungen nicht.

Dirk S. schrieb:
> Eigentlich lief er, nur das automatische Anmeldefenster kam nicht. Mit
> 192.168.x.1 konnte ich es aufrufen und WiFi einstellen.

Wie auch sonst?
Natürlich mußt Du im Browser eine gültige IP eingeben.
Die sieht man doch in den WLAN Settings des AP im Hostsystem (bei mir 
WIN 11).

Nicht natürlich, die Version 0.5.10 ruft die Anmeldeseite automatisch 
auf, sobald man sich mit dem AP verbindet. Die nachfolgenden Versionen 
nicht mehr, daher war nicht klar ob es überhaupt läuft.
Ist natürlich ein Anfängerfehler, aber im Nachhinein ist es immer 
einfach.

Dirk S. schrieb:
> Nicht natürlich, die Version 0.5.10 ruft die Anmeldeseite automatisch
> auf, sobald man sich mit dem AP verbindet.

Interessant, erkläre mal den Mechanismus wenn Dein Endgerät noch mit 
einem weiteren Netzwerk verbunden ist, wovon ich stark ausgehe.
Kenne das nur als "Captive Portal"...

Bei mir hat das auch nicht automatisch funktioniert.
Daher habe ich in den WLAN Einstellungen das DG gesehen und die IP im 
Browser eingegeben...

Aber das scheint ja nur eine Hürde bis zu den weiteren Problemen zu 
sein.
Das alles funktioniert bei mir einwandfrei. Bei Dir nicht mit gleicher 
Codebasis.

Suche den Fehler, wenn Dein Monitor entspiegelt ist wird es schwer;-)

Ich verstehe nicht ganz warum Du hier unterschwellig pissig wirst.

Warum sollte ich noch mit einem anderen Netzwerk verbunden sein, wenn 
ich mich mit dem ESP im AccessPoint Modus verbinde? Bei 0.5.10 wurde man 
automatisch auf die Anmeldeseite (siehe 4.) weitergeleitet, danach nicht 
mehr. Das ist alles was ich festgestellt habe. Genau wie die Tatsache, 
dass es mein Fehler war dies nicht zu erkennen.

Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die 
Inverter Einstellungen nicht und das nicht nur bei mir.

Ich versuche hier nur etwas als unbedarfter Anwender beizutragen, falls 
dies nicht erwünscht ist, kann ich mich auch raushalten.

Dirk S. schrieb:
> Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die
> Inverter Einstellungen nicht und das nicht nur bei mir.

Bei mir schon.
Wir halten also fest:
Es kann nicht am Code liegen.

Sigi S. schrieb:
> Dirk S. schrieb:
>> Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die
>> Inverter Einstellungen nicht und das nicht nur bei mir.
>
> Bei mir schon.
> Wir halten also fest:
> Es kann nicht am Code liegen.

Moin,
hm...
bei ist das gleiche.
Die Inverter lassen sich nicht speichern.
Und nein mein Monitor ist nicht entspiegelt.
Ich habe 2x die gleiche Hardware (NodeMCU+NRF24)

AHOY,

ich habe nun auch die Probleme, das auch in der akktuellen Version, 
keine Werte gespeichert werden.

Bei Inverter werden Address* und Name* nicht gespeichert.
Diverse Browser probiert, diverse Reihenfolgen, SAVE mit reboot, ohne 
reboot...

Device Name und WLAN Settings bleiben erhalten.

Was ist nur los?

Habe bei Github ein ISSUE dazu erstellt.

Also ich bin auch zu blöd dazu den Datenpunkt für die 
Leistungsbegrenzung im iobroker anzulegen.

Anbei mal ein paar Screenshots.
Die MQQT Instanz ist als Server konfiguriert. Die Daten kommen auch von 
der Ahoy-DTU an.

Das Topic ist "Solaranlage"

Ich kann aber überhaupt keine Ordner erstellen!
Ja Expertenmodus ist an.

Kann mir da jemand helfen?

Hat schon jemand Erfahrungen mit diesem Funk-Modul sammeln können?
Laut Beschreibung soll es ein Original Nordic Chip sein.

https://de.aliexpress.com/item/1005001803228202.html

tastendruecker schrieb:
> -die .bin Datei mit der aktuellen ahoy Software aus dem grindylow/ahoy
> repo bei github (links unter releases)

Finde ich nicht mehr.
Unter Actions kann ich auch nichts runterladen?!

Entwarnung, gefunden!

Nachdem ich die ESP8266-Version 0.4.20 seit über einen Monat produktiv 
im Einsatz habe und damit auch zufrieden bin, habe ich mir auf ein 
zweites System testweise die neue 0.5.x Version installiert.
Da stellen sich folgende Fragen:
was bedeuten die neuen Felder P_ACr  und die Einheit VAr bzw. 
ALARM_MES_IS ?
Kann man irgendwo etwas darüber nachlesen?

Gruß
Herbert

Hubert schrieb:
> Hallo Leute!
>
> vielen Dank für Eure tolle Arbeit! Habe es endlich geschafft, die .bin
> Datei zu flashen, und habe jetzt die version 5.14 oben.
> Beim Zugriff auf den AP werde ich jedoch noch einem Passwort gefragt!
> Gibt es denn eines, oder hat das flashen hier denn irgendwie nicht
> richtig funktioniert?

Das AP Standardpasswort ist "esp_8266"

Andi K. schrieb:
> Hat schon jemand Erfahrungen mit diesem Funk-Modul sammeln können?
> Laut Beschreibung soll es ein Original Nordic Chip sein.
>
> https://de.aliexpress.com/item/1005001803228202.html

Ich hatte hier bestellt:

https://de.aliexpress.com/item/4000516282921.html?spm=a2g0o.order_list.0.0.21ef5c5fwq0ieL&gatewayAdapt=glo2deu

Lieferung innerhalb von zwei Wochen!

Das Modul macht einen sehr guten Eindruck, funktioniert bei mir auch 
einwandfrei - allerdings habe ich nur ca. 1 m und eine Betondecke 
zwischen WR und "DTU", alle anderen Versionen der von mir getesteten 
nRF24L01+-Module machen da auch keine Probleme. Und die Chips sind 
hinter der Abschirmung "versteckt".

Hubert schrieb:
> Hallo Leute!
>
> vielen Dank für Eure tolle Arbeit! Habe es endlich geschafft, die .bin
> Datei zu flashen, und habe jetzt die version 5.14 oben.
> Beim Zugriff auf den AP werde ich jedoch noch einem Passwort gefragt!
> Gibt es denn eines, oder hat das flashen hier denn irgendwie nicht
> richtig funktioniert?

Moin,

PW ist esp_8266

Ich komme auf die Startseite, auf die setup Seite komme ich nach dem 
flashe des D1 Mini immer nur 1mal und diese wird nicht richtig 
angezeigt. Rufe ich Setup ein zweites mal auf rebootet der D1.

Grüsse

AD

Ich habe ahoy auf einem ESP8266 mit NRF24L01+ installiert (Ahoy sieht 
super aus). NRF wird erkannt, allerdings reagiert der Wechselrichter 
nicht, obwohl die korrekte Seriennummer eingetagen ist.

Es ist ein MI-1500 mit 1062xxxxxxxx aus 2021 (gekauft als HM-1500). Ich 
habe gelesen:
"Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann 
nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer: 
10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und 
DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren"

Was bedeutet dies genau? An welchen Stellen sind Änderungen im Code 
vorzunehmen, bzw. hat jemand diese Type schon zum Laufen gebracht mit 
irgendeiner Plattform?

Ich könnte mit ESP8266, Arduino Nano, or Raspberry PI 3B das Debugging 
unterstützen. Wie würdet ihr vorgehen?

Moin,

ich hatte mit 0.5.12 Probleme das die Setup seite nicht geöffnet wurde 
und der D1 mini offensichtlich eine reset durgeführt hat! Habe jetzt die 
5.15 drauf und die nun scheints zu gehen!
Beim compilieren können 2 Datein nicht erstellt werden aber die brauche 
ich wohl nicht!

AD

Reinhard schrieb:
> Ich habe ahoy auf einem ESP8266 mit NRF24L01+ installiert (Ahoy sieht
> super aus). NRF wird erkannt, allerdings reagiert der Wechselrichter
> nicht, obwohl die korrekte Seriennummer eingetagen ist.
>
> Es ist ein MI-1500 mit 1062xxxxxxxx aus 2021 (gekauft als HM-1500). Ich
> habe gelesen:
> "Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann
> nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer:
> 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und
> DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren"

Suche mal in diesem Thread (ggf. Seitenaufteilung abschalten) nach 
"MI-1500" bzw. Beiträgen von "Ziyat T. (toe_c)" und "Jörg R. (rejoe2)". 
Die beiden haben sich intensiv mit dem MI-1500 beschäftigt.

Ralla66 schrieb:
> Dann müsste ja
> WRSer in dec 6 77 21
> ESP Dtu      4 56 78
> ergibt Ch    3 23 40 61 75
> wobei ja DTU fest ist und die CH immer ähnlich sind bei HM600.

Hallo zusammen!
Gibt es zu den Kanalwechseln schon weitere Erkenntnisse?
(Leider kann ich die Rechnung zu den genannten Werten nicht folgen)

Reinhard schrieb:
> Ich habe ahoy auf einem ESP8266 mit NRF24L01+ installiert (Ahoy sieht
> super aus). NRF wird erkannt, allerdings reagiert der Wechselrichter
> nicht, obwohl die korrekte Seriennummer eingetagen ist.
>
> Es ist ein MI-1500 mit 1062xxxxxxxx aus 2021 (gekauft als HM-1500). Ich
> habe gelesen:
> "Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann
> nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer:
> 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und
> DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren"
>
> Was bedeutet dies genau? An welchen Stellen sind Änderungen im Code
> vorzunehmen, bzw. hat jemand diese Type schon zum Laufen gebracht mit
> irgendeiner Plattform?
>
> Ich könnte mit ESP8266, Arduino Nano, or Raspberry PI 3B das Debugging
> unterstützen. Wie würdet ihr vorgehen?

Hi,

ändere einfach mal deine Seriennummer im Setup/Eingabe von 1062xxxxxx 
auf 1161xxxxxxx (die "xxxxx" sind natürlich in beiden Fällen die 
gleichen die für dich gelten)

Grüße

Danke sehr. Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen 
HM-1500? Der Wechselrichter sieht genau wie ein MI-1500 aus, gelabelt 
ist er mit MSC Grid Tie Inverter 1500W.

Ziyat T. (toe_c) oder Jörg R. (rejoe2), könnt ihr mir einen Link 
schicken von einem kompletten Sketch, den ich testen kann?

Reinhard schrieb:
> Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen
> HM-1500?

Nach der Übersicht hier

https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx

ist es eher **kein** HM-1500.

Vielen Dank für den tollen Support. Leider habe ich noch nicht mit dem 
Wechselrichter (MI-1500 höchstwahrscheinlich) kommunizieren können.

Ich werde Ziyatoes code 
(https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles) die nächsten Tage 
testen - kompilieren konnte ich ihn schon (BTW: in Sonne.h fehlt ein l 
für long). Vermutlich macht es sogar Sinn mit einem zweiten ESP8266 zu 
sniffen um zu sehen, dass die Nordic Module richtig funktionieren - Ich 
habe welche mit power amplifier und welche ohne.

Die Seriennummer beim Setup > Adresse
Der Empfänger darf nicht zu weit vom Inverter sein!

Sermon schrieb:
> Receive success: 1
> Receive fail: 72
> Frames received: 7
> Send Cnt: 434
>
> Inverter 'HM1500 (FW-Version: 0)' is not available and is not producing
> -> last successful transmission: 2022-08-24 07:31:17
>
>
> Welche Einträge muss ich wie setzen?
>
> Der WR produziert sehr wohl Energie, aber fälschlicher Weise steht im
> Webinterface obige Anzeige.
>
> BG

Einfach mal laufen lassen. Hatte ich auch schon. Dauerte teilweise schon
sehr lange bis dann  plötzlich Daten empfangen wurden. Und dass ohne
etwas am Standort der Geräte, WLAN etc geändert wurde.

Martin Ecker schrieb:
> Guten Tag zusammen,
>
> ich stelle jetzt mal eine Frage aus der Sicht eines Webentwicklers der
> von Mikrokontrollern keine und von Elektrotechnik wenig Ahnung hat ...
> also nicht wundern ;-)
>
> Der Hoymiles USB Stick Lite schickt die Daten ja an die Hoymiles Cloud
> und wir wollen die Daten ja lokal haben.
>
> Zum Transfer der Daten muss dann ja eine Ziel Domain oder -IP angegeben
> sein, damit die Daten dann auch dorthin versendet werden können.
>
> Jetzt stellt sich mir die Frage:
>  * Könnte man die IP/Domain nicht einfach so verändern, das die Daten
> lokal landen? Also eben nicht Cloud, sondern z.B. 192.168.1.123 etc ...
> ?
>
>  * Oder wäre es möglich die IP im Datenstrom durch einen Proxy
> umschreiben zu lassen? So könnten die Daten dann auc lokal verarbeitet
> werden.
> Mit WireShark müssten die Daten ja sichtbar sein, oder sind die
> verschlüsselt?
>
> Was meint Ihr dazu?
>
> Die Verarbeitung der Daten ist dann natürlich noch was anderes,
> aber es ging ja primär darum, die Cloud zu umgehen und die Daten lokal
> zuhaben.

Moin,
genau darum geht hier in dem Thread, aber halt nicht mit dem Hoymiles 
DTu sondern mit einem Eigenbau.
Du solltet Dir so was basteln und dann dmit "rumspielen" die Lösung mit 
dem ESP8266 ist recht einfach! Falls du dir das nicht zutraust kann ich 
helfen!
Grüsse

Andreas

Hallo,

ich habe seit ein paar Tagen die Version 0.5.15 im Einsatz. Ich habe 
zwei Inverter definiert, jedoch nach einen Reboot erscheinen Angaben im 
3. Inverter, [Address: 52656368, Name: n],die ich nicht gemacht habe. 
Durch einen Save(ohne Boot) kann man dies löschen und das wird auch 
richtig verarbeitet.
Aber bei einen erneuten Reboot tauchen die Angaben wieder auf.
Die Limit-Angabe in der Visualization-Seite wechselt ohne das ich eine 
entsprechende Eingabe gemacht habe, manchmal auf 32%. Das hat aber 
keinen Einfluss auf die Einsspeise-Leistung des WR.

Gruß
Herbert

Herbert S. schrieb:
> Hallo,
>
> ich habe seit ein paar Tagen die Version 0.5.15 im Einsatz. Ich habe
> zwei Inverter definiert, jedoch nach einen Reboot erscheinen Angaben im
> 3. Inverter, [Address: 52656368, Name: n],die ich nicht gemacht habe.
> Durch einen Save(ohne Boot) kann man dies löschen und das wird auch
> richtig verarbeitet.
> Aber bei einen erneuten Reboot tauchen die Angaben wieder auf.
> Die Limit-Angabe in der Visualization-Seite wechselt ohne das ich eine
> entsprechende Eingabe gemacht habe, manchmal auf 32%. Das hat aber
> keinen Einfluss auf die Einsspeise-Leistung des WR.
>
> Gruß
> Herbert

Das kann ich so bestätigen, hatte nach Inbetriebnahme das gleiche 
Problem. Lösche doch mal den gesamten Flash des ESP8266 nach folgender 
Anleitung:

http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers

Danach die aktuellste *.bin - Datei flashen.

Reinhard schrieb:
> Danke sehr. Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen
> HM-1500? Der Wechselrichter sieht genau wie ein MI-1500 aus, gelabelt
> ist er mit MSC Grid Tie Inverter 1500W.
>
> Ziyat T. (toe_c) oder Jörg R. (rejoe2), könnt ihr mir einen Link
> schicken von einem kompletten Sketch, den ich testen kann?

Hi,
Es ist ein hm1500.
Nutze einfach ein esp8266 board mit ahoy Firmware 0.5.15 und schreibe 
die Seriennummer immer als 1161xxxx

Hallo, nach durchforsten dieses threads und einigem Ausprobieren mit 
ahoy (esp8266) und openDTU (esp32) wollte ich mal fragen ob mittlerweile 
jemand den

TSUN TSOL-M800 mit ner 104161xxxxxx Seriennummer ans laufen gebracht?

Ich bekomme da einfach keine Verbindung zum Inverter. Hardware sollte 
passen.
Der Inverter läuft hier seit 2 Jahren prima, würde ihn nur gerne in die 
restliche Infrastruktur (diverse Tasmotas und Eigenbauten mit ESPs/MQTT) 
per mqtt einbinden.

Gruß
    Johannes

Johannes schrieb:
> Hallo, nach durchforsten dieses threads und einigem Ausprobieren mit
> ahoy (esp8266) und openDTU (esp32) wollte ich mal fragen ob mittlerweile
> jemand den
>
> TSUN TSOL-M800 mit ner 104161xxxxxx Seriennummer ans laufen gebracht?

Ich warte aktuell noch auf die Lieferung eines TSUN M800, bin aber guter 
Hoffnung, dass dieser mit ahoy kommunizieren kann.

Bei Raik E. soll es zumindest funktionieren:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Ja, seiner hat auch ne 114173307xxx Seriennummer, meiner eine mit 1041 
startende...

Woran kann es liegen dass ich den Ahoy nicht in Home Assistant bekomme?
Addon Mosquitto broker: installliert
-Integration: installiert und aktiviert
-mehrfach HA neugestartet
-Ahoy DTU mehrfach neugestartet
-IP, Port, Passwort und Benutzername ebenfalls richtig

Ahoy sagt MQTT: connected
Ich bekomme auch alles mit den gleichen Daten im mqtt-explorer 
angezeigt.

Nur taucht es eben in HA nicht auf, bin auch mit jemanden durchgegangen 
der es gestern installiert hat und bei dem es läuft, bei ihm geht es, 
bei mir nicht.

Ich bin auch auf ein Video gestoßen wo gesagt wurde man solle einen 
neuen benutzer anlegen "mqtt-user" auch mit dem geht es einfach nicht.

Jemand eine Idee?

Sören S. schrieb:
> Woran kann es liegen dass ich den Ahoy nicht in Home Assistant
> bekomme?
> Addon Mosquitto broker: installliert
> -Integration: installiert und aktiviert
> -mehrfach HA neugestartet
> -Ahoy DTU mehrfach neugestartet
> -IP, Port, Passwort und Benutzername ebenfalls richtig
>
> Ahoy sagt MQTT: connected
> Ich bekomme auch alles mit den gleichen Daten im mqtt-explorer
> angezeigt.
>
> Nur taucht es eben in HA nicht auf, bin auch mit jemanden durchgegangen
> der es gestern installiert hat und bei dem es läuft, bei ihm geht es,
> bei mir nicht.
>
> Ich bin auch auf ein Video gestoßen wo gesagt wurde man solle einen
> neuen benutzer anlegen "mqtt-user" auch mit dem geht es einfach nicht.
>
> Jemand eine Idee?

Also bei mir war das auch so. Alles versucht, aber kein mqtt 
Autodiscovery.
Auch mehrfach versucht. Es wollte einfach nicht klappen.
Im mqtt-explorer siehst du ja die Topics.

Habe die in der configuration.yaml dann händisch angelegt.

1

2

  - platform: mqtt

3

    state_topic: "solar/11617xxxxx/0/yieldtotal"

4

    name: "Gesamtproduktion HM-1500"

5

    device_class: energy

6

    unit_of_measurement: "KW/H"

7

    value_template: >

8

        {{value|round(2)}}

9

    state_class: total_increasing

10

    unique_id: "total_hm1500"

11

    last_reset_topic: "solar/11617xxxxx/0/yieldtotal"

12

    last_reset_value_template: "1970-01-01T00:00:00+00:00"

Hallo zusammen, ich kann unter Github-Action nur die Version 0.5.14 
finden. Gibt es für die 0.5.15 ein neues Versteck ;-) ?

OlaLu schrieb:
> Das Problem hatte ich auch, allerdings mit OpenDTU auf ESP32.
> Letztendlich habe ich irgendwo (in der Homeassistant-Dokumentation?)
> gefunden, dass folgende Einträge in die configuration.yaml geschrieben
> werden müssten:
> mqtt:
>   broker: http://<IP des Brokers>
>   discovery: true
>   discovery_prefix: solar

Dass war noch ein Fehler in der Default OpenDTU Konfiguration (Heute 
behoben). Du kannst das discovery_prefix in der configuration.yaml auch 
weglassen (default ist homeassistant) und unter Settings --> MQTT --> 
"Home Assistant MQTT Auto Discovery Parameters" --> "Prefix Topic" 
einfach "homeassistant/" eintragen.

Dirk Z. schrieb:
> Hallo zusammen, ich kann unter Github-Action nur die Version 0.5.14
> finden. Gibt es für die 0.5.15 ein neues Versteck ;-) ?
code ----releases

Moin,

ich nutze seit einer Woche einen ESP8266 mit einem HM-1500, funktioniert 
einwandfrei!
Das einizige was mir aufgefallen ist das die Uhrzeit sehr viel nachgeht.
Weiss jemannd wo die Zeit definiert bzw. wie die Zeit berechnet wird.
Ich denke die Synchronisierung mit dem NTP Server wird nur beim Start 
des ESP einmal ausgeführt!
AD

Hallo Andreas,

korrekt, die Zeit wird nur einmal beim Start geholt. Laut Stefan sollte 
die garnicht so stark davonlaufen.
Jetzt bin ich neugierig. Was hast du gemacht, dass dein ESP so lange 
läuft? Welcher Aufbau und welche Version? Mein ESP läuft maximal 8h, 
dadurch habe ich immer eine frische Zeit - ich hätte aber auch gerne 
eine Laufzeit > 1 Tag

Die neue Synchronisation der Zeit brauchen wir auf jeden Fall, man 
könnte einen Trigger einbauen, der alle 12h aktiv wird.

Lukas P. schrieb:
> Hallo Andreas,
>
> korrekt, die Zeit wird nur einmal beim Start geholt. Laut Stefan sollte
> die garnicht so stark davonlaufen.
> Jetzt bin ich neugierig. Was hast du gemacht, dass dein ESP so lange
> läuft? Welcher Aufbau und welche Version? Mein ESP läuft maximal 8h,
> dadurch habe ich immer eine frische Zeit - ich hätte aber auch gerne
> eine Laufzeit > 1 Tag
>
> Die neue Synchronisation der Zeit brauchen wir auf jeden Fall, man
> könnte einen Trigger einbauen, der alle 12h aktiv wird.

Moin,
ich habe mich evtl. etwas falsch ausgedrückt, das ganze Setup läuft seit 
einer Woche. Der ESP8266 bootet schonmal oder ich habe ihn gebootet.

Die Zeit läuft ca. 5min pro 3 STunden zu langsam!

Vier Tage Laufzeit habe ich schon dokumentiert - s. Screenshot.
Aufbau dazu: 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Unter dem nRF24L01+-Modul "versteckt" ist ein 3,3V-Spannungsregler für 
dieses Modul.

Die von Andreas beschriebenen Abweichungen bei der Zeit habe ich auch 
beobachtet. Sie sind wohl vom jeweiligen ESP8266-Baustein abhängig.

> Die Zeit läuft ca. 5min pro 3 STunden zu langsam!

Das kann ich nicht bestätigen. Meine Uptime ist jetzt 02:38 und die Zeit 
geht ca. 8s nach.

Lukas P. schrieb:
> Das kann ich nicht bestätigen. Meine Uptime ist jetzt 02:38 und die Zeit
> geht ca. 8s nach.

Ich denke das hängt von Modul ab! Ich arbeite vermutlich mit einem China 
Cone!?

Andreas S. schrieb:
> Reinhard schrieb:
>> Danke sehr. Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen
>> HM-1500? Der Wechselrichter sieht genau wie ein MI-1500 aus, gelabelt
>> ist er mit MSC Grid Tie Inverter 1500W.
>>
>> Ziyat T. (toe_c) oder Jörg R. (rejoe2), könnt ihr mir einen Link
>> schicken von einem kompletten Sketch, den ich testen kann?
>
> Hi,
> Es ist ein hm1500.
> Nutze einfach ein esp8266 board mit ahoy Firmware 0.5.15 und schreibe
> die Seriennummer immer als 1161xxxx

Hallo Andreas,

dein Tipp war goldrichtig. 1161xxxxxxxx eintragen statt 1062xxxxxxxx 
eintragen und der Wechselrichter funkt mit ahoy am ESP8266 brav. Ich 
habe D1/D2 für CE/IRQ genommen (da auf D3 oder D4 eine LED am ESP8266 
Modul ist). Vielleicht war dies der Grund, warum ich vorher keine 
Verbindung geschafft habe.

Jedenfalls, vielmals Danke nochmals!

Hallo, nachdem ich mich hier durchgewurschtelt habe, openDTU auf 
ESP32pico so läuft, stellt sich mir die Frage was hat das mit dem Git 
Hash auf sich ?
Weil bei mir steht da alles nullen, siehe Bild.
Und im 2.bild muß ich da die Daten von meinem Heimnetz eintragen. Ich 
bekomme keine Verbindung zum WR, achso ist ein HM-800.

Jetzt mal doof gefragt, was ist denn die IP des Brokers bei Home 
Assistant?

D

Sören S. schrieb:
> Jetzt mal doof gefragt, was ist denn die IP des Brokers bei Home
> Assistant?

Die IP von dem PC oder vom RPi wo drauf der HA läuft.

Hallo miteinander!
Alle Achtung für Euer ambitioniertes Projekt!
Bin seit >30a HW-Entwickler & weiß zu schätzen, was Ihr da leistet!
LGG

Jörg R. schrieb:
> mit der Version von Ziyat T. sollte es eventuell gehen, ich hoffe,
> Anfang Sept. auch eine etwas einfachere Variante für alle 10-er Nummern
> als Basis für das Weiter-Entwickeln in Richtung ahoy-Integration
> anbieten zu können.

Hi Jörg,
Welche Version genau meinst du?

Ich habe jetzt nochmal Ahoy 0.5.15 probiert, Seriennummer mal als 1041 
mal als 1141 eingegeben, es kommen aber keine Daten vom Inverter.

Wenn ich dir was helfen kann beim integrieren, testen oder so, lass es 
mich wissen.

Gruß
     Johannes.

...dann gehts erstmal auf der anderen Baustelle weiter: ESPHome mit 
Soyosource1000, Epever Laderegler und DALY BMS sprechen lassen.

Danke Jörg,

Ich hab das Repo von Ziyat gefunden: 
https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles
Mit dem code in der zip und nach umstellen auf MI600 und bekome ich 
jetzt tatsächlich Daten vom TSUN TSOL-M800 mit 1041er Seriennummer in 
der Konsole. Vielen Dank schonmal.

EDIT: nachdem ich NRofPV auf 1 gesetzt hab gehen jetzt auch Webserver 
und MQTT senden.

Denke ich werde das senden noch was anpassen, lieber einen JSON String 
statt vieler einzelner Werte, werde wohl das format von Tasmota 
übernehmen, das passt dann gut zum rest und geht direkt in die Influx.

Gruß
     Johannes

Also irgendwie bekomm ich das in Home Assistant nicht zum laufen.

Könnte mir jemand mal ne richtige Starthilfe geben?

Ausgangspunkt ist:

HASSIO: neueste Version
Ahoy: 0.5.15
MQTT: ist verbunden

HASSIO: unter Mosquitto broker bei "zuhören" werden mir alle Daten vom 
HM-600 Angezeigt.

Wie gehts für mich konkret weiter, ich wurstel da jetzt seit 3-4 Tagen 
abends herum und langsam nervt es nur noch.

jnz schrieb:
> Danke Johannes für den eindeutigen Beweis, das die 1041TSUN prinzipiell
> zur Kommunikation zu bewegen sind.

Wenn jemand mal testen will:
https://github.com/derFrickler/DTUsimMI1x00-Hoymiles

kompiliert und flasht mit platformio.
Es muss nur die secrets.h angepasst werden.
Und falls mqtt gewünscht noch die Adresse des brokers in der mqtt.h

Johannes schrieb:
> jnz schrieb:
>> Danke Johannes für den eindeutigen Beweis, das die 1041TSUN prinzipiell
>> zur Kommunikation zu bewegen sind.
>
> Wenn jemand mal testen will:
> https://github.com/derFrickler/DTUsimMI1x00-Hoymiles
>
> kompiliert und flasht mit platformio.
> Es muss nur die secrets.h angepasst werden.
> Und falls mqtt gewünscht noch die Adresse des brokers in der mqtt.h
Wow, das sieht cool aus, und dein C-Kenntnis-Level ist eindeutig besser 
wie meiner!

Zwischenzeitlich habe ich auch noch etwas am "Original" für die 
MI-Varianten rumgespielt. Die angehängte Version kann:
- Das Model bzw. auch die Anzahl der PV-Eingänge anhand der Seriennummer 
erkennen (der TSOL-800 müßte eigentlich 2 Eingänge haben, oder?).
- Die Analyse der "normalen" Messages erfolgt über eine einzige Routine
- Es wird nicht strikt abwechselnd angefragt, sondern immer der nächste 
noch fehlende Datenpunkt (auch bei dem 1500-er)
- Es wird TX- und RX-seitig "gehopt", wobei der RX-Channel immer 1/2 
Periode hinter TX herhinkt. Effektiv gesendet wird bei isTime2Send() 
dann immer erst, wenn der RX-Channel "optimal" für den WR ist; solange 
nicht klar ist, ob das der Fall ist, wird nach ein paar Fehlversuchen 
dann zum nächsten gewechselt.
Hatte eigentlich gehofft, dass es mit dieser Methodik dann easy wäre, 
die Status-Messages abzufangen - effektiv geklappt hat das aber leider 
nicht, ohne dass ich bisher draufgekommen wäre, an was es hängt. 
Andererseits "findet" der ESP nach dem Start recht schnell einen Kanal, 
auf dem der WR reagiert und bekommt dann "zumindest" die mAn. 
wichtigeren Leistungsdaten auch zeitnah zu jedem neuen "Zyklus" 
ermittelt.

@derFrickler: Die ersten beiden Punkte wären vermutlich recht einfach in 
deinen Code zu übernehmen. Ob es sinnvoll ist, das ganze irgendwie 
"zyklisch" anzulegen (nach x Sekunden wird alles wieder gelöscht und von 
vorne begonnen), müßte man ggf. diskutieren. Ich wollte (vor dem 
Hintergrund der bei den ersten Versuchen eher "löchrigen" empfangenen 
Daten) mit dieser Methode absichern, dass einerseits (ohne Limitierung) 
keine "Altdaten" ewig mitgeschleift werden, und andererseits 
optimalerweise der WR nicht "ständig" nach updates gefragt wird, ohne 
dass sich jemand für "Zwischenergebnisse" interessiert (anstehender 
MQTT-Versand oä.).

Jörg R. schrieb:
> Wow, das sieht cool aus, und dein C-Kenntnis-Level ist eindeutig besser
> wie meiner!

Och,m ich habe da auch nur rumgestümpert, mein C is auch nicht doll. 
wollte es nur sauber im git haben und eben mit platformio.

> Zwischenzeitlich habe ich auch noch etwas am "Original" für die
> MI-Varianten rumgespielt.

Sehr cool, schaue ich mir an, denke das ich meine paar Änderungen da 
auch einfach einbauen kann. Wenn du willst kannst du danach mal mein 
repository versuchen, ist mit platformio und VSCode doch deutlich 
komfortabler als mit Arduino IDE.

Das mit dem Fehlende anfragen ist prima, idealerweise hätte man so einen 
kompletten Datensatz und könnte den komplett als ein objekt per mqtt 
verschicken.

Die Limitierung habe ich beim TSUN noch garnicht getestet. meiner ist 
auch ein TSOL M800, DE auf 600W  limitiert. Wäre mal interessant ob man 
die 600W auch mit den max 800W möglichen überschreiben kann ;_)

Gruß
      Johannes

Johannes schrieb:

> Ich hab das Repo von Ziyat gefunden:
> https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles
> Mit dem code in der zip und nach umstellen auf MI600 und bekome ich
> jetzt tatsächlich Daten vom TSUN TSOL-M800 mit 1041er Seriennummer in
> der Konsole. Vielen Dank schonmal.

das ist erfreulich!
damit ist die funktionsfaehigkeit für den MI600 auch getestet. ich sehe 
auf dem bild, dass die status meldungen (3 = betrieb normal) auch durch 
kommen, super!

@Jörg R
warum die status meldungen bei dir nicht auf anhieb funktioniert hat??

ich habe bei einer neuen version (0.1.6) die PV checks mit einem timer 
versehen, nach dem ablauf wird die PV daten neue gesammelt. und es gibt 
div. andere  aenderungen, auch fixe limitierung.

bei mir geht es bei der definition v. NRofPV um die anzahl der 
tatsaechlich angeschlossenen PV's  und nicht um die anzahl der wr-ports, 
damit sammele ich  nur die angeschlossenen PV daten.

Hallo zusammen,

zwischenzeitlich habe ich auch gesehen, dass es ein update im Repo von 
Ziyat T. gab, und wohl aus diesem Grund der Code so aufgeräumt aussieht, 
sorry für das Mißverständnis.

Es wäre m.E. hilfreich, wenn wir dazu übergehen könnten, den Code nicht 
als Zip im repo zu verwalten, dann wird es transparenter, was wo (ggf. 
warum) geändert wurde.

Ziyat T. schrieb:
> @Jörg R
> warum die status meldungen bei dir nicht auf anhieb funktioniert hat??
Ich habe gestern dann noch eine firmware mit Hilfe von Johannes V0.1.5 
gebastelt, die seit heute morgen auf meinem Haupt-ESP werkelt. Die hat 
das Problem nicht, da kommen auch die 03-er-Messages durch.
Dieses Problem wird also durch meine Versuche verursacht, die Sende- und 
Empfangskanäle voneinander abhängig zu takten.

Insgesamt ist es in der V0.1.5 aber seltsam, dass die Zahl der "Treffer" 
(gesendete Anfragen mit zeithaher Antwort) zur Zahl der "Fehlschüsse" 
starkt über der Zeit variiert, auch was das Verhältnis der 03-er zu den 
PV-Daten bzw. 89- zu 91-Messages betrifft.

Festzuhalten bleibt aber, dass das gefühlt die beste Version ist, die 
ich bisher gesehen habe, auch was den MQTT-Teil betrifft.

Ad MQTT noch: die Daten kommen auch da eher ungleichmäßig, der JSON-Teil 
an sich gefällt mir auch sehr gut, über die Nomenklatur sollte man m.E. 
nochmal reden (auch was die Single-Topics angeht), wobei mich selbst das 
relativ wenig kratzt, ich benenne einfach in FHEM um...
Was aber bei Johannes Version noch nicht schön ist: da wird der 
json-Topic irgendwie anders ermittelt als der Rest, das wirkt wie ein 
Fremdkörper...

> ich habe bei einer neuen version (0.1.6) die PV checks mit einem timer
> versehen, nach dem ablauf wird die PV daten neue gesammelt. und es gibt
> div. andere  aenderungen, auch fixe limitierung.
Ich werde dann auf alle Fälle dann diese Fassung als weitere Basis 
nehmen, habe aber meinerseit ein paar kleinere Vorschläge, die es neuen 
Usern einfacher machen würden, das ganze auf ihre Bedürfnisse 
anzupassen. Wäre klasse, wenn wir da irgendwie einen Weg finden könnten, 
dass das geht, ohne dass jeder bei jeder Änderung irgendwo wieder erst 
mal ein diff drüberlaufen lassen müßte...

> bei mir geht es bei der definition v. NRofPV um die anzahl der
> tatsaechlich angeschlossenen PV's  und nicht um die anzahl der wr-ports,
> damit sammele ich  nur die angeschlossenen PV daten.
Ah, ja, da war noch was... Wie wäre es, den Teil in die userConfig zu 
übernehmen, aber optional zu machen? Also: wer es braucht, weil er 
künstlich limitieren will, kann das setzen, wer es nicht setzt, bekommt 
"ifdef" einen (korrekten) Automatismus?
Ziel sollte ja sein, dass man als "experienced user" alles mögliche 
einstellen kann, aber als "Gelegenheitscompiler" (bzw. mittelfristig 
ahoy-etc.-User) alles "mundgerecht" vorbereitet bekommt.

Ja, code direkt im GIT wäre klasse, dann kann man auch diffs machen und 
mergen.

Die Sache mit dem JSON mqtt war auch nur ein schneller Versuch es bei 
mir in die bestehende Infrastruktur mit Tasmota/Node-Red/Influx 
einzubinden, hab mich bei der Struktur und Nomenklatur am Tasmota 
orientiert - weil ich das gewohnt bin.

Ja, generell wäre es sinnvoll alle Settings wie Serial, Wifi, mqtt 
Server, Topic(s), WR Typ etc.. in einer Config zu haben. Hier hatte 
scheinbar auch schon jemand angefangen das umzusetzten:

https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles/blob/21bce89b41a921d3743ff0c941421eed46b917b5/NRF24_SendRcvMIesp/SettingsCheckThisFirstOutAndChangeName.h#L107

Mein Traum wäre ja das ganze integriert in Tasmota zu haben, aber das zu 
machen ist mir zu aufwendig.

Bin gespannt wie es weitergeht, auf jeden Fall schon mal vielen Dank, 
hab jetzt nach 2 Jahren Betrieb auch mal einzelne Daten was die beiden 
Panels wann bringen.

Wenn der Rest soweit steht kann ich gerne den MQTT Teil nochmal anpassen 
so das er besser integriert und configurierbar ist. Es scheint da auch 
noch ein problem zu geben das er keinen Reconnect zum broker macht wenn 
der mal weg war.

Johannes schrieb:
> Hier hatte
> scheinbar auch schon jemand angefangen das umzusetzten:
> 
https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles/blob/21bce89b41a921d3743ff0c941421eed46b917b5/NRF24_SendRcvMIesp/SettingsCheckThisFirstOutAndChangeName.h#L107

Na ja, "jemand" war meinereiner, über dasselbe Thema stolpere ich bei 
jeder Anpassung an mqtt.h - meine IP-Adressen sind einfach anders, und 
es ist ausgesprochen lästig, das jedesmal wieder "zurückdrehen" zu 
müssen...

> Wenn der Rest soweit steht kann ich gerne den MQTT Teil nochmal anpassen
> so das er besser integriert und configurierbar ist. Es scheint da auch
> noch ein problem zu geben das er keinen Reconnect zum broker macht wenn
> der mal weg war.
Die Benennungen im JSON finde ich eigentlich besser als die 
single-Varianten, und wenn sich da schon jemand anderes an anderer 
Stelle den Kopf zerbrochen hat, kann/darf das m.E. gerne so bleiben - 
ich kann für mich ja das so überleiten, dass die Benennung dem 
"klassischen" Muster entspricht, kein Problem, nur (einmaliger) Aufwand. 
(Bei mir geht es auch darum, das ggf. für andere FHEM-User 
vorzubereiten, damit die nicht ihrerseits irgendwelche historisch 
gewachsenen Datenstrukturen anpassen müssen).
Nur die Topic-Benennung ist da "schräg", und doppelt 
(single+JSON-verpackt) braucht man es eigentlich auch nicht. Aber das 
ist eher sowas wie der Feinschliff...

@Jörg R.
@Johannes (derfrickler)

die von mir verwendeten mqtt topics sind so entstanden, weil ich schon 
seit einem jahr meine DTU-Pro und DTSU666 mit pymodbus steuere und die 
daten auf nodered presentiere, darum musste ich die gleichen namen 
verwenden, so kann ich einfach umschalten.

>Ja, generell wäre es sinnvoll alle Settings wie Serial, Wifi, mqtt
>Server, Topic(s), WR Typ etc.. in einer Config zu haben.

klar und einverstanden, meiste sind jetzt 0.1.6 im settings.h, den rest 
werde ich auch zügeln.

> Es scheint da auch noch ein problem zu geben das er keinen Reconnect zum
> broker macht wenn der mal weg war.

das kann ich nicht bestaetigen

> Wie wäre es, den Teil in die userConfig zu übernehmen, aber optional zu >machen?
> Also: wer es braucht, weil er künstlich limitieren will, kann das >setzen, wer 
es nicht setzt, bekommt "ifdef" einen (korrekten)
> Automatismus?

im settings.h kann man definieren ob fix limitiert oder zeroexport oder 
gar nicht

>Es wäre m.E. hilfreich, wenn wir dazu übergehen könnten, den Code nicht
>als Zip im repo zu verwalten, dann wird es transparenter, was wo (ggf.
>warum) geändert wurde.

ich werde die V0.1.6 files einzeln uploaden

Ziyat T. schrieb:
> ich werde die V0.1.6 files einzeln uploaden
Thx, der erste Patch ist eingereicht (automatische Erkennung von Type 
und NRofPV (letzteres abschaltbar)).

Danke auch für's Zusammenführen der ganzen Einstellungen, das ist jetzt 
wirklich übersichtlich!

Funktioniert soweit ganz gut, an der "falschen" Empfangsstelle hatte ich 
allerdings erst gar keine Sts-Messages, und die Web-Seite kann man nicht 
aufrufen.

> die von mir verwendeten mqtt topics sind so entstanden, [...]
Volles Verständnis, (zumindest erst mal) die Kompabilität beizubehalten 
ist für mich völlig ok. Ändern können wir dann immer noch, wenn alles 
soweit steht, wobei ein optionaler tieferer sub-Topic als ergänzung 
schon hilfreich wäre, und darauf, dass Johannes wieder die JSON-Option 
einbaut, freue ich mich schon jetzt... grins

>> Es scheint da auch noch ein problem zu geben das er keinen Reconnect zum
>> broker macht wenn der mal weg war.
>
> das kann ich nicht bestaetigen
Ist vielleicht "Broker"-abhängig. hab's (mit FHEM-MQTT2_SERVER) noch 
nicht getestet, bei Gelegenheit versuche ich das mal (ggf. auch mit 
Mosquitto).

> im settings.h kann man definieren ob fix limitiert oder zeroexport oder
> gar nicht
Vermutlich irritiert mich das "one for all"-Konzept an dieser Stelle 
etwas. Für's Plausibilisieren fand ich es hilfreich, den Grid-Wert aus 
dem vorgeschalteten Aktor zu sehen. Vielleicht kann man das dahingehend 
umstellen, dass es einen getrennten MQTT-Topic für's Aktivieren gibt? 
Andererseits: für mich tut es die aktuelle Lösung auch, nachdem mir 
klarer ist, wie die Zusammenhänge sind.

THX jedenfalls für den klasse Support!

Jörg R. schrieb:
> Thx, der erste Patch ist eingereicht (automatische Erkennung von Type
> und NRofPV (letzteres abschaltbar)).

ich aendere noch weitere dinge, deine idee mit der "automatische 
erkennung" werde ich, etwas geandert, in die neue version übernehmen, 
danke!


> Funktioniert soweit ganz gut, an der "falschen" Empfangsstelle hatte ich
> allerdings erst gar keine Sts-Messages, und die Web-Seite kann man nicht
> aufrufen.

setupWebServer() war faelschlicherweise kommentiert und ausser betrieb 
;-)

> schon hilfreich wäre, und darauf, dass Johannes wieder die JSON-Option
> einbaut, freue ich mich schon jetzt... *grins*

diese JSON scheint ja unentbehrlich sein;-) ich überlege wie ich beide 
möglichkeiten über settings anbieten könnte

Ziyat T. schrieb:
> ich aendere noch weitere dinge,
Gerne! Ist ja nur ein (getesteter) Vorschlag.

Falls Du auch einen Vorschlag haben möchtest für die Logik "frage zuerst 
erst mal nach den Dingen, die noch nicht da sind": Einfach melden.

Dieses "ungeregelte Dauerfeuer" bei den Anfragen ist mir einfach 
suspekt, aber anscheinend ist das halt (zumindest mit Einschränkungen) 
wohl so erforderlich...?

Ansonsten enthält die neulich angehänge .ino auch noch einen 
"Einheitscode" für die Auswertung der Data-Messages (36-39 und 89/91; es 
wird einfach der hintere Bereich ausgelassen, wenn nicht MI1500). Ist 
vielleicht übersichtlicher, wenn man das irgendwann in eine "Klasse" 
umbauen will?
(dto, was Vorschlag angeht).

> setupWebServer() war faelschlicherweise kommentiert und ausser betrieb
> ;-)
lach, dann brauche ich nicht mehr suchen...
> diese JSON scheint ja unentbehrlich sein;-)
"unentbehrlich" ist vielleicht etwas dick aufgetragen, aber in FHEM ist 
die Verarbeitung von "Mehrfachinfos" schlicht effizienter, wenn alles 
auf einmal kommt statt tröpfchenweise, weil für jedes Tröpfchen jedesmal 
die komplette Eventverarbeitungsloop angestoßen wird (und wir hatten 
leider einige Fälle, in denen die aufgrund der konkreten Konfiguration 
der betreffenden User "etwas ineffizient" war, was dann in Summe zu 
(vermeidbaren) Problemen führt). Ein Teil der vermeidbaren "Zutaten" für 
derartige Probleme ist eben die "Umverpackung" in JSON, that's all, weil 
dann die Eventverarbeitung pro JSON durchgeführt wird - egal, ob da 1 
Datenpunkt drin ist oder 10.000e.

Ziyat T. schrieb:
> diese JSON scheint ja unentbehrlich sein;-) ich überlege wie ich beide
> möglichkeiten über settings anbieten könnte

Ich habs jetzt so gelöst:
https://github.com/derFrickler/DTUsimMI1x00-Hoymiles/blob/main/Settings.h#L70

https://github.com/derFrickler/DTUsimMI1x00-Hoymiles/blob/main/NRF24_DTUMIesp.ino#L1104

Senden der JSON Nachricht is in ne Funktion gepackt.

Beim Webserver wird nun auch noch die anzahl der Panels berücksichtigt:

https://github.com/derFrickler/DTUsimMI1x00-Hoymiles/commit/fd499d738297c8a7b75d5c210463781380abf16d#diff-c6315fa14b190df4199812d6dec67688aa0cc3c86f214fcf4e60cf8698359ac4

Hallo,

folgendes Problem sobald ich meinen D1 ESP8266 Mini (ahoy_v0.5.15)  mit 
dem nRF24L01+ PA+LNA verbinde bleibt alles aus. Erst wenn ich das 
nRF24L01+ entferne läuft der D1 ESP8266 Mini,so dass ich mich ins ESP 
AHOY WiFi-Netzwerk einloggen kann. Es scheint ein Problem mit dem Strom 
zu sein. Verbunden wurden die Module wie auf Github gezeigt.

Wäre Prima, wenn mir jemand ein paar Tipps geben könnte

Anbei mal ein Foto von meinem Setup:

Johannes schrieb:

> Senden der JSON Nachricht is in ne Funktion gepackt.
werde so übernehmen, auch die definition im settings.h

> Beim Webserver wird nun auch noch die anzahl der Panels berücksichtigt:
gute idee!

danke

Finde ich auch gut so!

Wenn ich noch Wünsche äußern darf:
- der subsribe-Topic sollte auch von der JSON-Variante abhängig sein 
(damit man wenigstens die "Adresse" im Topic drin hat)
- Falls jemand weiß, wie man einen funktionierenden "last will" bastelt, 
wäre das nochmal einen (ebenfalls von JSON/nicht-JSON abhängigen?) Topic 
wert...

- was ggf. noch fehlt (?), wäre die dynamische Ermittlung der 
Maximalleistung des WR (für MI600 eigentlich (?) 3*300W, Settings.h, 
zeroexport PVPOWER)

Ansonsten sind wir m.E. ziemlich nahe dran, dass wir "Teil 1" 
abgeschlossen haben (funktionsfähigen Code für einen "Standalone"-WR).

Für "Teil 2" (Integration in die Komplettfirmware) fehlt mir allerdings 
im Moment weiter der Durchblick, wie man das analog zu den HM-Modellen 
umsetzen könnte...

Andi schrieb:
> sobald ich meinen D1 ESP8266 Mini (ahoy_v0.5.15)  mit
> dem nRF24L01+ PA+LNA verbinde bleibt alles aus.

Ich schlage folgendes Vorgehen vor:
- Kontrollieren, ob es zwischen den + und - Pins (rot - schwarz) am 
nRF24L01 sichtbar eine direkte Lötverbindung gibt, ggf. vorsichtig 
nachlöten,
- nur + und - vom nRF24L01 am Wemos mini D1 anschließen: Bleibt dann der 
Wemos betriebsfähig?
- Falls nein: nRF24L01 wahrscheinlich "defekt".

Jörg R. schrieb:

> Wenn ich noch Wünsche äußern darf:
> - der subsribe-Topic sollte auch von der JSON-Variante abhängig sein
> (damit man wenigstens die "Adresse" im Topic drin hat)
> - Falls jemand weiß, wie man einen funktionierenden "last will" bastelt,
> wäre das nochmal einen (ebenfalls von JSON/nicht-JSON abhängigen?) Topic
> wert...
bisher hab ich keine erfahrung mit JSON, kann ev. Johannes (derfrickler) 
uns helfen

>
> - was ggf. noch fehlt (?), wäre die dynamische Ermittlung der
> Maximalleistung des WR (für MI600 eigentlich (?) 3*300W, Settings.h,
> zeroexport PVPOWER)
meinst du für MI600 2*300W, und bei MI300, 1*300?

Ziyat T. schrieb:
> Jörg R. schrieb:
>
>> Wenn ich noch Wünsche äußern darf:
>> - der subsribe-Topic sollte auch von der JSON-Variante abhängig sein
>> (damit man wenigstens die "Adresse" im Topic drin hat)
>> - Falls jemand weiß, wie man einen funktionierenden "last will" bastelt,
>> wäre das nochmal einen (ebenfalls von JSON/nicht-JSON abhängigen?) Topic
>> wert...
> bisher hab ich keine erfahrung mit JSON, kann ev. Johannes (derfrickler)
> uns helfen
In mqtt.h habe ich bzgl. des ersten Punkts mal Folgendes eingefügt, das 
scheint zu funktionieren:

1

#ifdef SENDJSON

2

String  GRID_PSTR                   = String(MQTTclientid)+"/ImpExpW";  //topic for reading the gridpower

3

const char *GRID_P                  = GRID_PSTR.c_str();

4

#else

5

static char GRID_P[]                = "ImpExpW";  //topic for reading the gridpower

6

#endif

last will hat nichts mit JSON zu tun, ist was MQTT-spezifisches: 
https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/ 
(ist wohl grade offline?) und 
http://www.steves-internet-guide.com/mqtt-last-will-example/

>> - was ggf. noch fehlt (?), wäre die dynamische Ermittlung der
>> Maximalleistung des WR (für MI600 eigentlich (?) 3*300W, Settings.h,
>> zeroexport PVPOWER)
> meinst du für MI600 2*300W, und bei MI300, 1*300?
Die Berechnung ist da und steht wohl auch an der richtigen Stelle, aber 
im Moment wird bei allen Modellen 350 verwendet.
Müßte mal ausprobieren, ob der MI600 auch 700W liefern würde? (Die Frage 
kam in ähnlicher Gestalt hier schon ein paar Mal, der WR müßte es 
abkönnen).
Weiß nicht, ob es von den Gen-2-Geräten auch 4*300W gibt (MI1200?)

Nachtrag:
Mit FHEM-MQTT2_SERVER ebenfalls wohl kein reconnect, und der Code von 
Johannes scheint auch an einer anderen Stelle etwas anders zu "ticken": 
Mit dem wird in FHEM ein Reading angezeigt, mit den "subscriptions" des 
ESP. Das fehlt (es funktioniert aber, der Server muss die also kennen).
Die Uhrzeit in der WEB-Abzeige war vorhin auch seltsam (2036), jetzt 
paßt es wieder? (habe zwischendurch nur die NRofPV in web....h 
eingetragen), die auch an einer 2. Stelle weiter unten auftaucht).

Generell neige ich weiter dazu, zwei subscribe-Topics zu nehmen, und die 
auf einen "set"-Teiltopic umzubiegen (für "grid" und "limit"). Vorschlag 
dazu kommt bei Gelegenheit.

Andi schrieb:
> Wäre Prima, wenn mir jemand ein paar Tipps geben könnte

Die PA+LNA-Variante zieht ziemlich viel Strom, ein (bei unshielded: 
besser 2) Kondensator ist (spätestens da) Pflicht!
Evtl. reicht auch der auf dem ESP verbaute Spannungswandler für 3.3V 
nicht aus.

meine Einstiegsprobleme waren:
- kompilieren des ESP Tools warf viele Fehler: meine Espressif Plattform 
für ESP8266 war viel zu alt, mit aktueller 4.x dann kein Problem
- die Verdrahtung auf dem Fritzing Bild passt nicht zur Defaultbelegung 
von CS,CE und IRQ. Kann im Setup im Webinterface angepasst werden
- ich hatte erst ein nRF Modul mit 10 pins und das falsch angeschlossen. 
Bei den 10 pin Modulen gibt es min. zwei Varianten. Sollte mittlerweile 
kein Problem bei neuen Komponenten sein, mein Waveshare Modul wird nicht 
mehr produziert und war aus einem älteren Set. Mit einem anderen Modul 
mit PA ging es dann, ich habe aber auch einen zusätzlichen Elko 
angelötet.
- In der Statistik wurden viele Fehler gezählt, es wurde versucht zwei 
nicht vorhandene WR abzufragen. Vor der Eingabe der WR Daten erstmal im 
Setup 'Erase Settings' auslösen, dann sind die Defaults ordentlich 
gesetzt.
- MQTT Server wurde nicht über Namen gefunden (liegt eher an meinem 
Netzwerk), mit IP Adresse ging es. Ich benutze ioBroker, da den 
mqtt-client Adpater installieren und alle Werte sind da.

Danke für das schöne Projekt, damit ist das Logging wirklich einfach.
Und die Hilfe im Discord Channel ist Top.

Jörg R. schrieb:
>> Jörg R. schrieb:
>>
> #ifdef SENDJSON
> String  GRID_PSTR                   = String(MQTTclientid)+"/ImpExpW";
> //topic for reading the gridpower
> const char *GRID_P                  = GRID_PSTR.c_str();
> #else
> static char GRID_P[]                = "ImpExpW";  //topic for reading
> the gridpower
> #endif

habe so übernommen, danke

> Die Berechnung ist da und steht wohl auch an der richtigen Stelle, aber
> im Moment wird bei allen Modellen 350 verwendet.
> Müßte mal ausprobieren, ob der MI600 auch 700W liefern würde? (Die Frage
> kam in ähnlicher Gestalt hier schon ein paar Mal, der WR müßte es
> abkönnen).
> Weiß nicht, ob es von den Gen-2-Geräten auch 4*300W gibt (MI1200?)

jetzt geht es sowohl, auch. wenn die PVportPOWER nicht angegeben wird, 
wird sie ermittelt

Danke für die Tipps ( Jörg & Günter). Hab alles mal nachgelötet. Es hat 
sich herausgestellt, dass GND - Pol nicht richtig angelötet war. jetzt 
geht alles. Eine Frage habe ich allerdings noch. Im Ahoi-SETUP stehen 
unter dem Reiter Inverter - 3 Einträge: Inverter 0 - Inverter 1 - 
Inverter 2. Unter Inverter 1 habe ich die SN meines Wechselrichters 
eingetragen. Im Menü Visualization werden mir allerdings auch die 
anderen beiden Inverter 0 & Inverter 2 als Leer angezeigt. Kann man die 
irgendwie entfernen ?

Schön, dass das jetzt geklappt hat, den/die Kondensatoren solltest du 
trotzdem sicherheitshalber noch einfügen.

Für den Rest kann ich wenig beitragen, da ahoy für die alten Modelle 
noch nicht läuft. Vielleicht reicht es, den WR als inverter 0 
einzutragen und die anderen leer zu lassen, sonst musst du ggf. die 
maximale Inverterzahl anpassen und selbst den Compiler anwerfen. Dann 
kannst du mit dem "großen" nRF evtl. auch gleich den PA-Level nach unten 
nehmen.

Erase Settings und dann nochmal neu eintragen.

Oha, perfekt. Jetzt wird alles richtig angezeigt. Wofür steht im SETUP 
Reiter der Eintrag: Radio (NRF24L01+) - Amplifier Power Level ? Was wäre 
da der optimale Eintrag für einen D1 ESP8266 Mini (ahoy_v0.5.15)  mit
dem nRF24L01+ PA+LNA ?

Ich habe es hier als Testaufbau und nur ca. 4 m Abstand, da reicht min. 
Ich würde es auch nur so stark einstellen wie nötig um die Daten zu 
empfangen. Wifi und ZigBee kloppen sich hier auch schon auf 2,4 GHz.

Ich habe heute einen TSUN TSOL-M800(DE) mit 11418 beginnender 
Seriennummer in Betrieb genommen. Die Kommunikation mit Ahoy 0.5.15 hat 
auf Anhieb funktioniert!

du brauchst einen Datensammler. Der Broker, z.B. mosquitto, verteilt nur 
die Daten. Beliebige Clients können dem Broker Daten liefern, andere 
Clients können anmelden diese Daten haben zu wollen. Lieferant hast du 
mit Ahoy, jetzt fehlt ein Rechner auf dem der MQTT Broker läuft, ein 
Stück SW das die Daten abonniert und in eine Datenbank schiebt, und dann 
eine GUI die aus der DB liest und darstellt.
Das macht SW wie ioBroker, FHEM, HomeAssistant lokal oder man könnte 
eine Cloud Lösung suchen.
Der Broker selber sammelt keine Daten, der verteilt nur 1:1 den Eingang 
(Publisher) and die Ausgänge (Subscriber).

Jens schrieb:
> Oder kann mir jemand die Stelle/Stellen im Postverlauf nennen, die
> wichtig sind.
>
>
> Gruß Jens

Hi,

1. Hardware:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/README.md#esp8266-wiring-example
2. Software:
https://github.com/grindylow/ahoy/releases --> dort das jeweils aktuelle 
zip und darin die *.bin Datei. Dann:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/README.md#flash-the-firmware-on-your-ahoy-dtu-hardware

Grüße

Hallo zusammen, mal eine "verrückte" Idee ... Wäre es irgendwie möglich 
die Signalqualität darzustellen ? Laienhaft ausgedrückt vielleicht über 
die Signallaufzeit ähnlich Ping ?

Dirk Z. schrieb:
> Wäre es irgendwie möglich
> die Signalqualität darzustellen ?

Dazu müsste der nRF Chip die Möglichkeit die RSSI auszulesen, hat er 
aber nicht, zumindest nicht dokumentiert.

Hat hier vielleicht jemand zufällig die 0.5.15 Version von Ahoy?
Die neu 0.5.16 war eine "Verschlimmbesserung" und die 0.5.15 gibt es 
nicht mehr zum download.

Also bei mir läuft die 5.16 auf 8266 und ESP32 stabil
anbei die 5.15

Danke dir.
Die Leistungslimitierung wird nicht mehr richtig angezeigt.

tatsächlich
betreibe ihn ohne Leistungslimitierung  deshalb nicht afgefallen

Rene M. schrieb:
> Danke dir.
> Die Leistungslimitierung wird nicht mehr richtig angezeigt.

Ja das stimmt. In der Weboberfläche passt das noch nicht. Vorher 0.5.15 
wurde einfach immer der Sollwert angezeigt egal ob der Umrichter das 
einstellte oder nicht. Jetzt ab 0.5.16 wird das Limit auf welches der WR 
regelt per Abfrage ermittelt und ausgegeben (also der Istwert):
a) auf der web Oberfläche (ja läuft im release 0.5.16 nicht, aber in der 
dev-Version, siehe github)
b) auf dem MQTT topic <DEINTOPIC>/ch0/PowerLimit
beides IMMER in %

Grüße

@Andreas
Ich limitiere mit absoluten Watt Angaben. Das funktioniert auch.
Nur bleibt im Webview die Limitierung auf 100% stehen, obwohl ich den 
1500er Wechselrichter auf 600W limitiere.
Hebe ich die Limitierung auf kommt irgendwann einmal später plötzlich im 
Webview 33%.
Es gibt ja jetzt auch ein File für den Esp32.
Wie sieht es da mit der Verkabelung aus? Gleich wie bei OpenDTU?

Hi Leute! Mega danke für eure ganze Arbeit, find ich richtig geil :)

Ne Möglichkeit oder die Idee den nrF Chip direkt auf dem WR mit anderer 
FW zu flashen gibt es nicht oder?

Bei mir läuft jetzt seit 36 Tagen OpenDtu ohne unterbrechung aus einem 
ESP32.

Leider lief die Ahoy immern nur max. 1 Tag bei mir.
Da ich mit den Daten der OpenDtu meinen Kühllüfter regele, möchte ich 
das ungern unterbrechen.

Geht es auch, das ich mit OpenDtu und AhoyDtu gleichzeitig auf den WR 
zugreifen kann oder beißt sich das dann ?

So könnte ich die neue Ahoy testen, ohne mein laufendes System zu 
unterbrechen.

Hallo,

was bedeuten eigentlich die Werte:
Pct
P_ACr

Hans W. schrieb:

> Geht es auch, das ich mit OpenDtu und AhoyDtu gleichzeitig auf den WR
> zugreifen kann oder beißt sich das dann ?


Nein die zwei stören sich dann.
Am Anfang klappte es bei mir mit ahoy auch nie.
Aber seit 0.5. irgendwas läuft das Teil auch einwandfrei.
Hatte am Anfang auch immer nur OpenDTU. Momentan nur ahoy.
Aber ich denke oder hoffe, dass auch OpenDTU bald mit der 
Leistungsbegrenzung klar kommt.
Zwei DTUs parallel stören sich aber, da hat man Ausfälle.

M. P. schrieb:
> Hallo,
>
> was bedeuten eigentlich die Werte:
> Pct
> P_ACr

Für Pct habe ich keine Erklärung und konnte auch nirgendwo nur einen 
Hinweis darauf finden. Irgendwas mit %, die angezeigten Werte ergeben 
für mich aber keinen wie immer gearteten Zusammenhang zu irgendwas.

Bezügl. P_ACr schien mir logisch Power-AC reactiv, also Scheinleistung, 
die bei diesen WR meist um die 0 herumkrebsen wird vermutlich. Dies 
konnte ich dann auch wo bestätigt finden.

Wenn also noch jemand die Güte besäße uns Pct einzudeutschen - danke!

Danke @ Grisu

Grisu schrieb:
> Wenn also noch jemand die Güte besäße uns Pct einzudeutschen - danke!

Ich hab folgendes gefunden:
Pct: actual AC Power factor in %

Quelle: 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md

Danke für die Aufklärung.
Das würde ja bedeuten Wirkleistung/Scheinleistung.
Ja, kommt sogar hin mit aktuell Pct 99,60% bei bei P_AC 272,70W und 
P_ACr 21,30VAr. Die Scheinleistung (Wurzel der Quadratsumme) errechnet 
sich dabei zu 273,53VA, somit 272,70/273,53=99,69%.

Danke auch für den Link, sowas hatte ich gesucht und nicht gefunden.

Das Limit (dunkelgrüne Zeile ganz oben) scheint auf "0 Watt" eingestellt 
zu sein. Bitte den Eintrag im Setup überprüfen.

Bei mir (HM-600) dauert es auch manchmal einige Minuten, bis der WR 
Strom produziert. Gut eine Minute wie im Bild ist eine kurze Zeitspanne.

Hallo,

ich wollte einfach mal ordentlich Danke sagen für das großartige "Ahoy" 
Projekt. Top! Funktioniert nun wunderbar nach anfänglichen 
Startschwierigkeiten mit nicht funktionierenden NRF24L01+.
So kann es aussehen, wenn man es per mqtt in den Home Assistant 
importiert hat.
Vielen Dank! koerly

misch schrieb:

> wollte die Version 05.15 flashen

Solltest vielleicht gleich die aktuelle 5.16 nehmen.

Hi zusammen,
auch von meiner Seite aus erst einmal vielen Dank für alles, was Ihr 
hier bisher auf die Beine gestellt habt. So ein geniales Projekt!
Ich habe OpenDTU jetzt seit einigen Tagen mit einem HM-400 ausfallfrei 
laufen. Das einzige was mich verwirrt ist der YieldDay-Wert. Der ist 
immer locker 0,4 bis 0,5 kWh unter dem Tageswert des Shelly 1PM, den ich 
noch zur Messung nutze. Gestern z.B. 1,71 kWh OpenDTU und 2,19 kWh 
Shelly.

Ich weiß, dass ein unkalibrierter Shelly 1PM nicht gerade präzise ist, 
aber SO unterschiedlich wundert mich dann doch. Oder funktioniert da was 
nicht richtig?

Hängen vielleicht noch andere Geräte an dem Kreis zw. Einspeispunkt und 
Shelly?
Wäre aber auch nur eine Erklärung, wenn die DTU mehr als der Shelly 
anzeigt.
Mein uralter EKM265 vom Conrad (>30 Jahre alt) liefert fast exakt die 
selben Werte wie die Messungen aus dem HM (<1,5% Differenz). Habe ihn 
dazu extra umgepolt, da er nur Verbrauch und keine Einspeisung messen 
kann.

PS: Finde es auch echt genial was hier geschaffen wurde, auch wenn ich 
Ahoy verwende, da die dazu nötigen Module grad greifbar waren.

Danke für die Einladung, bin "da".

Wäre schön, wenn Ziyat T. auch dazustoßen würde, weil ich mich bisher 
nicht damit beschäftigt habe, wo "im Untergrund" (also bei den h und 
cpp-files) eigentlich die Unterschiede zwischen HM und MI liegen.
Die Zusammensetzung der Messages selbst scheint ja bis auf die 
Status-Messages bis Mi-600/MI-800 mehr oder weniger identisch zu sein?
Und der Empfang (und/oder auch das Senden?) "muss" (ich halte das immer 
noch für eine komische Implementierung auf der Seite des Herstellers) 
wohl wirklich rollieren, damit man die Status-Messages auch bekommt.

Dass zwischenzeitlich Topics da sind für die diversen Bestandteile zum 
Produktionsdatum, habe ich dem "list" eines FHEM-Users entnommen und 
mich gefragt, ob das zeitlich zufällig war... Aber ist es sinnvoll, 
gleich 3 Topics für diese Infos zu belegen?

Und könnte man die HomeAssistant-autodiscovery per default bitte 
ausschalten? Jedem neuen FHEM-User zu erklären, dass er das gar nicht 
braucht und bitte ausschalten soll bzw. die Topics generell abschalten, 
ist nicht allzu erquicklich...

Das soll's von meiner Seite aber zu User-Fragen zu einer speziellen 
Automatisierungslösung gewesen sein, diese Dinge sind anderswo m.E. in 
der Tat besser aufgehoben.

Hallo zusammen,
wurde die HI version (habe selbst HI-600) jetzt schon testweise in das 
AHOI DTU eingebaut oder noch nicht?

David B. schrieb:
> Hallo zusammen,
> wurde die HI version (habe selbst HI-600) jetzt schon testweise in das
> AHOI DTU eingebaut oder noch nicht?
Die 2.Gen/Geräte sind noch nicht integriert, der "Startschuss" dürfte 
aber gefallen sein. Den aktuellen Stand kann man seit heute 
https://github.com/grindylow/ahoy/issues/258 verfolgen, und falls du 
selbst compilieren kannst (Arduino IDE reicht), kannst du das Repo von 
Ziyat T. (oder meinen fork) nehmen; da sind eigentlich nur kleine 
Anpassungen (in einer einzigen file) nötig (WR- und IP-Adressen etc.). 
(Ist dann aber nicht die Ahoy-firmware, sondern ein Klon von Hubi's 
Ausgangs-Code)

okay, das werde ich machen. melde mich mit resultaten.

Ist es normal, daß nach einem FW-Update (Ahoy 0.5.16 auf 0.5.17) die 
Pinout-Settings verloren gehen?
nRF24 war nicht mehr erreichbar (Fehlermeldung), dann in den Settings 
gesehen, daß alle 3 konfigurierbaren Pins D3 (GPIO0) eingetragen hatten.

Hi David,

ich hoffe, es ist ok für dich, wenn ich auf die pm hier offen antworte - 
das ist ein Entwicklungsthread, und es ist einfacher, wenn alle lesen 
können, ob bzw. welche Probleme dass es gibt.

Gut ist erst mal, dass das mit dem Flashen (Files aus meinem Repo, ich 
nehme an, aus dem Master-Tree) geklappt hat und du Nachrichten siehst 
bzw. zurückbekommst. Prinzipiell ist es so, dass der WR afaik nicht von 
sich aus sendet, sondern von der DTU aus "eingetacktet" und abgefragt 
wird, was vermutlich bedeutet, dass bei dir irgendwas auf der RF-Seite 
optimiert werden muss. Die Klassiker: Kondensator + "optimale" 
Sendeleistung. Letztere ist vermutlich auf "MIN" eingestellt, was für 
mich als Test-Ausgangsbasis gut war, weil ich einen eher "lauten" nRF 
verwende. Würde also in jedem Fall den/die Kondensator/en einsetzen, und 
dann ggf. die Stufen nacheinander durchtesten (man kann es am Terminal 
im laufenden Betrieb machen, nur eben nicht zurück auf MIN). "Zu laut" 
ist aber auch nichts!

Die jetzigen Fassungen (egal, ob von Ziyat T., oder die daraus 
abgeleiteten Klone von Johannes oder mir) sind die besten, die ich 
bisher gesehen habe, aber auch mit den Vorversionen hatte ich noch 
teilweise (auch im laufenden Betrieb) wechselhafte Ergebnisse mit Phasen 
relativ häufiger Rückmeldungen und solchen, in denen es nicht so optimal 
war.
Daher auch die (jetzt erst mal abgebrochenen und aktuell nicht 
implementierten) Versuche, irgendeine Logik zu finden, nach der Sende- 
und Empfangskanal in Abhängigkeit zueinander ermittelt werden können...

Ich will aber nicht ausschließen, dass ich bei den (wenigen) 
Modifikationen was kaputt gemacht habe, das den Empfang verschlechtert.

Rene M. schrieb:
> Wie sieht es da mit der Verkabelung aus? Gleich wie bei OpenDTU?

Ich habe meinen ESP wie folgt verkabelt und die Ahoy5.17 läuft darauf 
sehr stabil:

NRF24 / ESP32
CSN --- G23
CE ---- G2
MO ---- G13
SCK --- G18
IRQ --- G0
MI ---- G19

Jumper schrieb:
> Carsten B. schrieb:

> Ich habe bei mir
> NRF24 / ESP32 MINI
> CSN --- G5
> CE ---- G2
> MO ---- G23
> SCK --- G18
> IRQ --- G01
> MI ---- G19
> Jedoch erhalte ich bisher keine Antwort, daher bin ich hier noch am
> ausprobieren...

Ich hatte das aus meiner Belegung beim ESP8266 abgeleitet. Allerdings 
habe ich beim Aufschrieben gestern noch einen Fehler eingebaut  :-(, 
hier die Korrektur:

NRF24 / ESP32
CSN --- G15
CE ---- G2
MO ---- G23
SCK --- G18
IRQ --- G0
MI ---- G19

Sorry für die Verwirrung...

Jörg R. schrieb:
 Die Klassiker: Kondensator + "optimale"
> Sendeleistung. Letztere ist vermutlich auf "MIN" eingestellt, was für
> mich als Test-Ausgangsbasis gut war, weil ich einen eher "lauten" nRF
> verwende. Würde also in jedem Fall den/die Kondensator/en einsetzen, und
> dann ggf. die Stufen nacheinander durchtesten (man kann es am Terminal
> im laufenden Betrieb machen, nur eben nicht zurück auf MIN). "Zu laut"
> ist aber auch nichts!
>
> Die jetzigen Fassungen (egal, ob von Ziyat T., oder die daraus
> abgeleiteten Klone von Johannes oder mir) sind die besten, die ich
> bisher gesehen habe, aber auch mit den Vorversionen hatte ich noch
> teilweise (auch im laufenden Betrieb) wechselhafte Ergebnisse mit Phasen
> relativ häufiger Rückmeldungen und solchen, in denen es nicht so optimal
> war.
Hey Jörg,
ich habe den(die) Kondensatoren mal verbaut, aber bekomme noch immer 
keine validen Ergebnisse ausserhalb des Sniffers (sniffer output hab ich 
dir als PN geschickt)
Benutzt habe ich den Main von Dir, habe dort PA_LEVEL = RF24_PA_HIGH auf 
MIN gesetzt und die Schritte durch probiert, ohne nennenswerte 
Ergebnisse. Habe auch die Distanz auf 30cm zwischen WR und nRF modul 
reduziert.

Erinnert mich etwas an die Probleme, die ich in den ersten Versionen von 
Ziyat auch hatte. Könnte damit zusammenhängen, dass er keinen Grid-Wert 
per MQTT bekommt. Habe den Teil dann nicht mehr vertieft, sondern 
schlicht einen Wert an die richtige Stelle gepublisht (mit retain-flag).

Außerdem sehe ich grade, dass ich den "konsolidierten Code" mit den 
JSON-Vorschlägen von Johannes noch gar nicht im Repo habe, hole ich bei 
Gelegenheit nach.

Im Moment ist der Topic, auf den "irgendwas" gepublisht werden sollte 
(ich habe dazu sicherheitshalber den 10-fachen Wert genommen, den der 
vorgeschaltete Aktor liefert, letztlich ist es aber nicht wichtig, 
solange man ZEROEXP nicht aktiviert): "ImpExpW"

Und generell ist beim Funken "zu nah" auch nicht zu empfehlen. 2-3m 
dürfen es schon sein.

Carsten B. schrieb:
> Ich habe meinen ESP wie folgt verkabelt und die Ahoy5.17 läuft darauf
> sehr stabil:
>
> NRF24 / ESP32
> CSN --- G23
> CE ---- G2
> MO ---- G13
> SCK --- G18
> IRQ --- G0
> MI ---- G19


Danke. Mittlerweile wurde die Readme auf ahoy schon damit erweitert.

Hey Jörg,
Ich werde das mal probieren. Ich verstehe das dann richtig, wenn MQTT 
deaktiviert wurde, das Script nicht richtig läuft? Daher bin ich etwas 
über den Gritwert irritiert, welchen ich vom MQTT Server senden soll. 
Die Aussage verstehe ich nicht so recht, da MQTT Seitig (noch) keine 
Logik für das Senden von Werten existiert.
Hatte das mal aktiviert, aber als einziges item habe ich das ‚ImpExpW‘ 
im Root des MQTT bekommen.
Ansonsten wurde nichts weiter angelegt, auch nicht, wenn mal ein Wert 
vom WR Decodiert werden konnte.
Ich bin etwas verwirrt, ob das am Code oder an meinem Aufbau liegt.
Ich werde am Sonntag mal ein zweiten Aufbau als Sniffer machen, um zu 
sehen, ob mein DTUsim überhaupt was sendet.
David

Tut mir leid, ich habe es dann im Code auch nicht mehr weiter 
nachvollzogen, aber es war auch bei mir so, dass weder der Webserver 
erreichbar war, noch irgendein Wert gesendet wurde, solange es Probleme 
auf der MQTT-Seite gab.

Ob was gesendet/empfangen wurde, kann ich grade nicht sagen.

Welche Art Server hast du da? Mosquitto oder was anderes? Welche 
Automatisierung?

Im Prinzip müßte es reichen, per mosquitto_pub (z.B.) auf diesen einen 
Topic einen Wert zu senden. Bei mir macht das MQTT_GENERIC_BRIDGE (in 
FHEM/MQTT2_SERVER) und haut da jeweils den Messwert rein.

Hey Jörg,
ioBroker nutze ich.
Jetzt ruft erst mal das Mittelalter :-).
Ich teste Sonntag wieder. Dank Dir soweit und ein schönes Wochenende.

Hoylmoly DTU für MI 300/600/1500 / TSUN800

hallo
ich habe eine neue version V0.1.9 veröffentlicht zum testen:

https://github.com/Ziyatoe/DTUsimMI-Hoymiles


- der sketch/code wurde zum teil massiv umgebaut
- es laeuft recht stabil(bei mir mehrere tage) und die wr-daten werden 
viel schneller erfasst, zu mindestens bei mir;-)
- mehrere wr-commands implementiert
- siehe readme.md

@Jörg R. (rejoe2)
ich habe für diese version die dtu-pro und den mi1500 von morgens bis 
abends durchgesnifft.
ich muss dich enttaeuschen, auch wenn es für dich (auch für mich 
teilweise) schwer zu verstehen ist:
es gibt keine sichtbare zusammenhaenge zwischen Serienummern, timing, 
kanaele usw. DTU sendet zwischen CH1-99 fast auf alle kanaelen, 
statistisch bekommst du die meisten antworten auf: 3,23, 40, 61, 75.
für mich ist die weitere "forschung" nicht mehr nötig, zu mal die neue 
versio, bei der datenerfassung recht schnell ist

Günter H. schrieb:
> Das Limit (dunkelgrüne Zeile ganz oben) scheint auf "0 Watt" eingestellt

das ist sehr aufmwerksam! super!

Hallo zusammen,

vielen Dank für das tolle Projekt.
Der Aufbau und Inbetriebnahme hat problemlos funktioniert.
Mein ESP8266 läuft jetzt seit mehreren Tagen problemlos.
Leider scheitere ich beim beim Aufruf des  "Active Power Limit via REST 
API".
Was ist am folgenden Aufruf verkehrt ?

curl -d '{"inverter":0, "tx_request":81, "cmd":11, "payload":10, 
"payload2":1} ' -H "Content-Type: application/json" -X POST 
http://192.168.1.93/api/

Vielleicht kann mir jemand beim Aufruf helfen.
Danke

Grüße Draszen

Ziyat T. schrieb:
> Hoylmoly DTU für MI 300/600/1500 / TSUN800
>
> hallo
> ich habe eine neue version V0.1.9 veröffentlicht zum testen:
>
> https://github.com/Ziyatoe/DTUsimMI-Hoymiles
Der Umbau sieht sehr gut aus (!), auch bei mir kommen die Daten sehr 
schnell (die Messdose zeigt noch gar nichts an....! Aber der MI-600 
sendet schon länger fleißig Daten (<5W zwar, aber er produziert).
Auch nach reboots (bisher aber nur 3x, und alle ohne großes zeitliches 
"Funkloch") sind die Daten schnell da (bereits bei der 2. Aktualisierung 
der Webseite).

Welchen Einfluss da speziell das als wichtig gekennzeichnete "wait(10);" 
hat, wäre ggf. auch für die HM-Fraktion interessant.

Auf die Schnelle keine Probleme auf der MQTT-JSON-Seite.

Kleinigkeiten:
- Die Webseite zeigt wohl Winterzeit an, und die "is day"-Info dürfte 
nachts auch falsch sein; ob die "year 2036"-Anzeige weg ist, kann ich 
ggf. morgen sagen
- Die Debug-Ausgaben an der Konsole für RX/TX enthalten teils komische 
Zeichen, die das etwas schwerer lesbar machen als bisher.

Das Dauerfeuer gefällt mir zwar immer noch nicht, und wie die TX-Kanäle 
gewechselt werden, sah' auf die Schnelle auch seltsam aus, wo/wann die 
3-er Statusinfo herkam, war an der Konsole nicht zu sehen.

**Vielen lieben Dank an dich für die Mühe auf alle Fälle!**

Vielleicht allgemein interessant: Dafür kurze Zeit stand auf einem der 
Kanäle eine "2" - das scheint sowas zu bedeuten wie: "fange gleich an zu 
produzieren"?

Jörg R. schrieb:
> Ziyat T. schrieb:
>> Hoylmoly DTU für MI 300/600/1500 / TSUN800
>>
>> hallo
>> ich habe eine neue version V0.1.9 veröffentlicht zum testen:
>>
>> https://github.com/Ziyatoe/DTUsimMI-Hoymiles
> Der Umbau sieht sehr gut aus (!), auch bei mir kommen die Daten sehr
> - Die Webseite zeigt wohl Winterzeit an, und die "is day"-Info dürfte
> nachts auch falsch sein; ob die "year 2036"-Anzeige weg ist, kann ich
> ggf. morgen sagen

die 2036 hab auch schon gesehen, konnte nicht mehr reproduzieren, da 
laeuft mit NTP etwas schief

> - Die Debug-Ausgaben an der Konsole für RX/TX enthalten teils komische
> Zeichen, die das etwas schwerer lesbar machen als bisher.
>
> Das Dauerfeuer gefällt mir zwar immer noch nicht, und wie die TX-Kanäle
> gewechselt werden, sah' auf die Schnelle auch seltsam aus, wo/wann die
> 3-er Statusinfo herkam, war an der Konsole nicht zu sehen.
wie gesagt, die DTU macht genau so mit dem dauerfeuer, nach meiner 
meinung gibts keine zusammenhaenge zwischen rx/tx, wenn man schaut wie 
viele verschiedene wr/cmd's/frame's die haben, ist es fast nicht 
möglich..

> **Vielen lieben Dank an dich für die Mühe auf alle Fälle!**
gerne! ich aendere die v0.1.9 immer wieder, einfach mal checken, das 
ziel ist eine 0.2 zu machen.

> Vielleicht allgemein interessant: Dafür kurze Zeit stand auf einem der
> Kanäle eine "2" - das scheint sowas zu bedeuten wie: "fange gleich an zu
> produzieren"?

die 2 hab ich auch schon gesehen, kann aber nicht ganz zu ordnen, bisher 
bin ich mit diesen sicher:
PORT_STATUS =
["no data?",
"?",
"?gesehen",
"Normal", (3)
"?",
"PV not connected", (5)
"?gesehen",
"?",
"Reduced"] (8)

Jörg R. schrieb:
> Kleinigkeiten:
> - Die Webseite zeigt wohl Winterzeit an, und die "is day"-Info dürfte
> nachts auch falsch sein; ob die "year 2036"-Anzeige weg ist, kann ich
> ggf. morgen sagen

ja genau, offset ist bei mir NULL, kannst du für dich anpassen
zeile 1195,363 >> is_Day = isDayTime(0);
ich werde den offset ins settings.h nehmen

edit:
>- Die Debug-Ausgaben an der Konsole für RX/TX enthalten teils komische
> Zeichen, die das etwas schwerer lesbar machen als bisher.

kann nicht bestaetigen, hier auf ubuntu22.04/minicom

sorry, es ist so:
PORT_STATUS =
["no data?",
"?",
"?gesehen",
"Normal", (3)
"?",
"MPPT port not connected", (5)
"?gesehen",
"?",
"Reduced"] (8)

wer zu wissen möchte,
reaktionszeit eines MI1550 auf cmd=0x51 (0x5A5A, limit)  etwa 20sek