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

[sorbit (Gast)]

Hallo,

diese Wechselrichter verfügen über einen RF 2,4 GhZ Nordic.
Hat jemand eine Idee wie dieses Protokoll aufgebaut ist?
Hat jemand das schon einmal "angezapft" um ein eigenes Monitoring ohne 
deren Cloudzwang zu realsieren?

Es gibt offensichtlich einen "Adapter", der das "2,4 GhZ Signal umsetzt 
und dann via WLAN an deren Cloudsysteme versendet.

Google, Hersteller, etc. schweigen sich leider aus.

Danke für sachdienliche Hinweise

[EAF (Gast)]

sorbit schrieb:
> Hat jemand eine Idee wie dieses Protokoll aufgebaut ist?

Könnte auf der Basis von ShockBurst™ sein.
Eine Beschreibung findest du z.B. im NRF24L01+ Datenblatt

[PhilippK_59 (Gast)]

Wenn die sich das einfach gemacht haben ist das ein properietäres Uart 
Signal.

[Christian Strickmann (Gast)]

Häng mich mal ran .... interessiert mich auch

[Sorbit (Gast)]

Scheint leider niemand zu wissen…
Schade, die WR sind eigentlich sehr verbreitet.
Das Ding sendet ungenutzt dauernd wertvolle Daten in den Äther..

[Martin M. (mcmaier)]

Bekomme demnächst auch den HM-600, von daher interessiere ich mich auch 
für das Thema.
Zumal das Originalzubehör ziemlich teuer und hässlich ist...

[Sorbit (Gast)]

Martin M. schrieb:
> Bekomme demnächst auch den HM-600, von daher interessiere ich mich
> auch
> für das Thema.
> Zumal das Originalzubehör ziemlich teuer und hässlich ist...

Die schweigen sich da so ziemlich aus.
Auf jeden Fall Cloudzwang mit Kosten und dieser wohl nicht verfügbare, 
teure wlan Stick

[Paul (Gast)]

Den Stick gibt es, aber sauteuer.
https://www.ebay.de/itm/164230252118

[sorbit (Gast)]

https://youtu.be/uA2eMhF7RCY

[Eule (Gast)]

Ist da inzwischen jemand weitergekommen?
Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm 
ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo 
von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID 
habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine 
ID länger ist werden ignoriert.

Erstes Problem: Das LC12S lässt sich nicht konfigurieren - zumindest 
spuckt dies die serielle Konsole aus.
Beschaltet ist das LC12S so:
VCC - 3V3
GND - GND
CS - GND
SET - IO4
Rx - IO16
Tx - IO 17
--> D.h. wenn, dann läuft es mit irgendwelchen Defaultwerten

In der Konsole bekomme ich folgenden Nonsense bei aktuell schwankend 
20-40W AC über Steckdose gemessen (klar, der WR ist ein anderer und hat 
ja bspw. 2 Strings usw...)

14:19:13.023 -> Received Inverter Status
14:19:13.023 -> Device: 7201xxxx
14:19:13.023 -> Status: 0
14:19:13.023 -> DC_Voltage: 46.00V
14:19:13.023 -> DC_Current: 629.00A
14:19:13.023 -> DC_Power: 28934.00W
14:19:13.023 -> AC_Voltage: 0.00V
14:19:13.023 -> AC_Current: 0.00A
14:19:13.023 -> AC_Power: 0.00W
14:19:13.023 -> Power gen total: 0.00
14:19:13.023 -> Temperature: 0

Sieht sich jemand in der Lage das Programm anzupassen?
Hier ein Ausschnitt, welche Bytes überhaupt ausgewertet und wie sie 
verrechnet werden. Ich wüsste jtzt nicht welche Bytes wie rum zu shiften 
und verrechnen sind...

void NETSGPClient::fillInverterStatusFromBuffer(const uint8_t* buffer, InverterStatus& status)
{
    status.deviceID = buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF);
    //status.deviceID = buffer[5] << 32 | buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF);
    const uint32_t tempTotal = buffer[10] << 24 | buffer[11] << 16 | buffer[12] << 8 | (buffer[13] & 0xFF);
    status.totalGeneratedPower = *((float*)&tempTotal);

    // CRC = buffer[14]
    status.dcVoltage = (buffer[15] << 8 | buffer[16]) / 100;

    status.dcCurrent = (buffer[17] << 8 | buffer[18]) / 100;
    status.dcPower = status.dcVoltage * status.dcCurrent;

    status.acVoltage = (buffer[19] << 8 | buffer[20]) / 100;
    status.acCurrent = (buffer[21] << 8 | buffer[22]) / 100;
    status.acPower = status.acVoltage * status.acCurrent;

    status.state = buffer[25]; // not fully reversed
    status.temperature = buffer[26]; // not fully reversed   
}

[[e-mail] (Gast)]

Ich würde mal "bluetooth-clients" in der Umgebung suchen. Vielleicht hat 
man Glück. ;-)

Was steht auf den Nordic-Chip?

[[e-mail] (Gast)]

Es wird ein LC12S laut yt-Video verwendet.

https://www.ebay.de/itm/272662983218

[Chris A. (cherio7)]

Eule schrieb:

> Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm
> ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo
> von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID
> habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine
> ID länger ist werden ignoriert.

Hi Eule,

ich habe das gleiche bei meinem HM-1200 versucht.
Allerdings bekomme ich einfach keine Antwort nach: "Sending request now"

wie hast du denn die InverterID im code eingegeben ?
einfach die komplette Seriennummer vom WR (12 stellen) wie hier ?

constexpr const uint64_t inverterID = 0x11617052xxxx ;

[Hubi (Gast)]

Hallo Eule
habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles 
HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, 
aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe 
ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann 
verworfen.
Also, ich schau's mir mal an.
Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und 
im Klartext als auch als Hex-Dump hättest.
Hast du am Original-Code was geändert, oder so wie in Github zu finden?

[Eule (Gast)]

>
> Hi Eule,
>
> ich habe das gleiche bei meinem HM-1200 versucht.
> Allerdings bekomme ich einfach keine Antwort nach: "Sending request now"
>
> wie hast du denn die InverterID im code eingegeben ?
> einfach die komplette Seriennummer vom WR (12 stellen) wie hier ?
>
> constexpr const uint64_t inverterID = 0x11617052xxxx ;


Hallo Chris,

ja genau. Geht aber genauso gut oder schlecht, wie wenn ich die ersten 4 
Stellen einfach weglasse und nur die letzten 8 verwende.
Es scheint, dass sich irgendwas verändert, wenn ich das Modul in der 
Hand habe. Auf dem Tisch liegtnd bekomme ich meist auch keine Antwort, 
halte ich es in der Hand oder an den Kabeln tut sich meist etwas. 
Entweder diene ich als Antenne oder ich habe einen Wackler, den ich 
trotz mehrmaligem Auftrennen und Neuverbinden nicht wegbekomme.

Bin einfach zu lange raus aus dem C++, mich verwirrt die Polldemo. :(

Gruß Eule

[Eule (Gast)]

Hubi schrieb:
> Hallo Eule
> habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles
> HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee,
> aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe
> ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann
> verworfen.
> Also, ich schau's mir mal an.
> Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und
> im Klartext als auch als Hex-Dump hättest.
> Hast du am Original-Code was geändert, oder so wie in Github zu finden?

Hallo Hubi,
ich habe mir so ein LC12S Modul besorgt und an die 2. UART eines Lolin 
Boards gehängt. Die Polldemo habe ich lediglich um meine Inverter ID 
angepasst.
Ansonsten habe ich inzwischen auch an zig Stellen im Code rumgedoktert - 
aber ich bin was das angeht mittlerweile einfach ein richtiger Anfänger.

Mal alles was der WR ausgibt mitschneiden war auch meine Idee, bekomme 
ich aber auf die Schnelle nicht hin. Ich frage mich eh, wie der Aaron 
das "entschlüsselt" hat. Wenn die Werte halbwegs mit irgendwas 
zusammenpassen, kann man es sich ja noch zusammenreimen. Aber das passt 
bei mi gar nicht. Auch frage ich mich, woher kennt er den "command" mit 
0xc0, 0xc1 usw.? Woher kennt er das Magic Byte? Ist das alles beim HM 
gleich oder anders?

Gruß Eule

[Hubi (Gast)]

Hi Eule
hier auf die Schnelle der Code zur Ausgabe des Dumps:
void printBuffer (char * richtung) {    // rein oder raus, send oder rcv
  int i;
  uint8_t ch;
  Serial.println(richtung);
  // drucke zuerst als Zeichen
  for (int i = 0; i < sizeof(mBuffer); i++) {
    ch = mBuffer[i];
    if (ch >= 32 && ch < 127) Serial.print(ch); else Serial.print ('.');
  }
  Serial.println();
  // jetzt das ganze in Hex
  for (i = 0; i < sizeof(mBuffer); i++) {
    ch = mBuffer[i];
    if (ch < 10) Serial.print('0');
    Serial.print (ch, HEX);
  }
  Serial.println();
}

[Hubi (Gast)]

Moin
es wäre auch von Vorteil, wenn man nach dem sendCommand in der Methode 
getStatus den Buffer mBuffer wieder komplett löschen würde, etwa durch
memset (mBuffer, 0, sizeof(mBuffer))
Da ab der Stelle 6 im mBuffer die DeviceId gefüllt wird (beim Senden) 
und dort nach Empfang des Status auch wieder steht, könnte man durch das 
vorherige Löschen ersehen, ob der Sender, also der WR, die DeviceId 
eingetragen hat.
Dann wüßte man wenigstens, dass der WR richtig antwortet.

[Eule (Gast)]

Kleines Update:
Rx und Tx gehören anders herum, als im Code-Kommentar.
D.h. alles was ich ab und zu "gelesen" habe, waren Geister.

Nach dem Drehen von Rx/Tx erste Erkenntnis: die beiden Tx haben sich 
nicht weh getan, denn nun wird zumindest mal die Konfiguration des LC12S 
geschluckt! :)
Aber vom Wechselrichter höre ich mit den gegeben Einstellungen für 
Channel und Network ID nichts.
Ich bin dann auf dieses tolle Repository gestoßen: 
https://github.com/Yogui79/IntexPureSpa
Da gibt's unter Tools was zum Suchen des Channels und der Network ID. 
Der klappert einfach einen nach dem anderen durch. Dauert halt... bisher 
noch kein Treffer beim Channel.
Naja vielleicht hat der Hoymiles ja doch garkein LC12S verbaut...? Mal 
abwarten.
Gruß Eule

[Eule (Gast)]

OK, mal wieder was gelernt... Aber ans Ziel kam ich damit nicht.
Die Kanalsuche schlägt nicht an.
Also nochmal nach dem DTU gesucht und siehe da, ein Bild mit der 
aufgedruckten FCC ID gefunden. Die dokumentieren ja üblicherweise ihre 
Tests.
Aha! https://fcc.report/FCC-ID/2ARNB-DTUW100
Wie man bei den internal photos sieht - kein LC12S verbaut. Sieht nach 
Eigenentwicklung - oder zumindest -layout aus.
Wieso nicht noch weiter bei der FCC nach Hoymiles suchen? Achja, da 
gibt's ja auch ein RF Modul namens HM2401 einzeln - zum Verbau im WR 
vermutlich: https://fccid.io/2ARNB-HM2401
Auch hier gibt's nette Bilder. Das schaut tatsächlich nach was anderem 
aus, als das LC12S 
(https://fccid.io/2ARNB-HM2401/Internal-Photos/Internal-Photos-4572280)
Aha! Ein NRF 24LE1E!
Ich muss mal in den Keller, glaube sowas habe ich auch noch wo 
rumfliegen.

Gruß Eule

[Herbert K. (avr-herbi)]

TOP Informationen EULE !  Grossartig !

[Martin (Gast)]

Usr-c210 ist ein uart total WiFi modul von pusr

[hubi (Gast)]

Tach
in der Zwischenzeit habe ich einen RF24-Scanner in meinem Gartenhaus 
laufen lassen. Scanner sind bei diversen RF24 Libs als Beispiel dabei. 
Es wird nach Carriern auf den Kanälen gesucht. Mein bisheriges Resultat:
- auf den Kanälen 1-14 ist recht viel los, sind ja auch die vom WLan
- auf Kanal 64, der bei dem Polldemo benutzt wird, war rein garnichts 
los
- meiste Aktivität war auf Kanal 16 bei 2 Mbps
Mein nächster Ansatz, falls sonst keine neueren Erkenntnisse, wird sein, 
auf dem Kanal mal etwas zu senden, evtl sowas wie die Statusabfrage, und 
die Antwort abzuwarten.
Übrigens: im Arduino-Repository gibt es die Lib nrf-hal, die stammt aus 
dem Hause Nordic und könnte die schon erwähnte proprietäre Lib für die 
Hoymiles sein.

[Carsten B. (carstenb)]

Moin zusammen,

kann ich hier mitmischen? Ich habe grade meine "Versuchsanlage" mit 
einem HM-600 in Betrieb genommen. Auf Grund dieses Beitrags habe ich 
jetzt ein NRF24-Mudul und einen Arduino zusammengesteckt und einen 
Scanner am laufen. Leider noch ohne Erfolg.

Welche Scansoftware habt ihr eingesetzt und wie groß ist der Abstand HM 
und NRF-Modul (bei mir etwa 10m)? Wahrscheinlich ist es sinnvoll, den 
Empfänger mal direkt neben den HM zu setzen, oder? Kann ich erst machen, 
wenn es wieder hell ist. Finkt der HM überhaupt, wenn die Panels keine 
Spannung liefern?

Viele Grüße

Carsten

[Carsten B. (carstenb)]

Hallo,

ich hatte gesehen, dass in den FCC-Dokumenten, die weiter oben verlinkt 
sind, ein user manual enthalten ist. Dort ist angegeben:

Channel List
2403, 2423, 2440, 2461, 2475MHz

Vielleicht hilf das, die Suche einzugrenzen?

[Einhart P. (einhart)]

Carsten B. schrieb:
> einen
> Scanner am laufen. Leider noch ohne Erfolg.

Hast du denn das Hoymiles Kommunikationsmodul (DTU-W100 ) laufen? 
Vielleicht antwortet der Wechselrichter nur auf Anfragen von diesem 
Gerät.

[Carsten B. (carstenb)]

Hallo,

DTU habe ich keine, war mir zu teuer und ich hätte es gern "cloudfree".

Den Fehler beim Scanner habe ich gefunden, ich hatte noch zwei Pins 
vertauscht läuft jetzt.

Noch kann ich aber keinen Kanal dem HM zuordnen.

[hubi (Gast)]

Hallo
meine Versuche mit dem Scanner hatte bisher keinen Erfolg. Oben gab es 
die Nachfrage welche Scanner eingesetzt wurden, ich nutzte die von den 
Libs rf24 und nrf_hal. Soviel ich weiß haben die nrf24l01 nur bis zu 126 
Kanäle.
Der Abstand zum HM-600 war nur knapp 2 m, und durch die Holzdecke + 
Schindeln.
Bin jetzt leider am Ende meines Lateins, wenn noch jmd eine Idee hat 
mache ich gerne weiter.

[[e-mail] (Gast)]

Modul überprüfen.
https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285

Direkt an TxD (oder auch RxD, das ist Definitionssache) des Moduls 
lauschen, ob Daten kommen.

Und ganz böse: Sein eigenes Adapter-Modul einbauen. ;-)

[Heinz R. (heijz)]

ich bin auch interessiert - aber leider momentan viel zu wenig Zeit

Aber schaut Euch doch das mal an:

https://github.com/Koenkk/zigbee2mqtt/issues/4221

Hoymiles kommt aus dem gleichen Haus wie APSystems - denke das Protokoll 
ist sehr ähnlich

Dort sind ein paar sehr fixe Jungs unterwegs die gerne behilflich sind

[roman1528 (Gast)]

Hallo zusammen, ich hänge mich hier mal rein, weil ich auch Cloud-Free 
den "MI" auslesen will. In meinem Fall 2 HM-600.

Hoymiles kommuniziert über "Nordic proprietary"... siehe Anhang

Nordic proprietary != Zigbee

anderes Adress-/CRC-Protokol... mehr hab ich leider noch nicht erfahren 
können... versuche auch schon mit 'nem NRF24l01 irgendwas zu 
empfangen... fürchte aber, dass der Inverter wie beim NETSGPClient 
getriggert werden muss... also aktiv Daten geholt werden.
Ansonten werden laut FCC-Test nur Kanal 13, 40 und 76 getestet 
("Fundamental frequency")

Grüße^^

[roman1528 (Gast)]

ich korrigiere...

Kanal 3, 40 und 75

[Einhart P. (einhart)]

Das Gerät wird nicht ständig Senden. Wenn dann nur Keep Alive Packets 
mit größeren Abständen. Es könnte sogar sein, dass der Empfänger auch 
nicht ununterbrochen aktiv ist und zum Einschalten der Träger erst ein 
paar Sekunden anstehen muss. Die Hoymiles sind mit < 50mW Verbrauch bei 
Dunkelheit angegeben. Für permanentes Wlan reicht das nicht.

Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die 
Kommunikation mitschneiden.

[31 (Gast)]

Einhart P. schrieb:
> Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die
> Kommunikation mitschneiden.

Ich bin am überlegen, ob ich mir DTU-Wlite bestelle, gibt es momentan 
für 79€. Ist immer noch viel Geld...und beschränkt auf 4 Module...

Bisher hat keiner der Beteiligten hier eine DTU?

Mein Testaufbau mit den NRF24 und dem Arduino funktioniert, zwischen 
meinen beiden NRF-Modulen kann ich erfolgreich Daten austauschen. So 
bald das Wetter es zulässt, packe ich einen Empfänger neben den 
Hoymiles.

[Carsten B. (carstenb)]

Sorry, sehe grade. dass ich als Gast geschrieben habe. Ich wars...

[hubi (Gast)]

Tja, vllt findet sich ja einer mit DTU, der hier mitmachen will, wäre 
super.
Meine Tests von heute morgen brachten folgende Resultate:
- es scheint kein alive-Paket zu geben, das von den Hoymiles verschickt 
wird
- Test auf Carrier-Signal auf den Kanälen, 13, 40 und 75 , dass nur auf 
Kanal 40 ein Carrier-Signal gefunden wurde, innerhalb einer Minute 
mehrere hundert.Auf den beiden anderen Kanälen war ab und zu ein 
Carrier, kann auch Rauschen sein.
Ich denke, ohne dass man da die Kommunikation mitschneidet wird es sehr 
aufwendig. Ich versuch mal, ähnlich wie bei dem o.g. Projekt mit 
APsystems zu pollen.

[martin (Gast)]

Hallo zusammen,
mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite 
bestellt, sowie einen HackRF SDR zur Protokoll-Analyse.

Mein Ziel ist, die Kommunikation mitzuschneiden und die Daten mit einem 
nRF24 und ESP ins Heimnetz zu bringen. Die Info über die verwendeten 
Kanäle ist schon mal nützlich zur Eingrenzung der Suche.
Ich melde mich, wenn dann mal alles da ist und ich Messungen machen 
konnte.

[Einhart P. (einhart)]

Klasse! Ich bin auf Ergebnisse gespannt.

[Chris K. (kathe)]

Nordic Docu gibt es hier:
https://infocenter.nordicsemi.com/index.jsp

[hubi (Gast)]

Toll dass es hier weitergeht.
Meine Tests haben zu keinem Ergebnis geführt. Das große Problem dabei 
ist, dass zuviele Parameter zueinander passen müssen, nämlich Kanal, 
(5-byte) Adressen der NRFs, Protokoll (Shockburst oder enhanced SB), 
Aufbau Datenpaket, "Magic" Byte, Füllbytes, CRC etc.
Wenn meine Programmierkenntnisse gebraucht werden, gerne.

[martin (Gast)]

martin schrieb:
> Hallo zusammen,
> mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite
> bestellt, sowie einen HackRF SDR zur Protokoll-Analyse.

Hallo zusammen.
Die Teile sind da und ich habe bereits erste Versuche durchgeführt, 
wovon ich euch einen Zwischenstand mitteilen möchte.

Zum Funkprotokoll:
Die Kanäle 3,23,40,75 scheinen zu passen, hier sieht man im Spektrum die 
Datenpakete, die per NRF gesendet werden. Die DTU scheint auch 
regelmäßig alle Kanäle zu bedienen - ob der Inverter immer auf dem 
selben Antwortet oder ob die Pakete redundant sind kann ich noch nicht 
sagen.

Im Zeitverlauf kann man die Datenpakete auch schön sehen, allerdings bin 
ich mir nicht sicher ob der Universal Radio Hacker sie richtig 
dekodieren kann - mir fehlt der Vergleich, welche Daten es denn sein 
sollen.

Dann hab ich mir die DTU mal genauer angeschaut. Alles in allem keine 
Raketentechnik.
-Ein GD32F303 (Gigadevice, ein STM-Klon) mit SPI Flash 25Q128 .
-Ein ESP8266 für die WLAN Kommunikation
-Ein NRF24LE1E mit 2401C (RF Front End)

Nachdem ich die beschriftete SPI-Schnittstelle gesehen habe, dachte ich 
"Da kann ich ja direkt die NRF-Kommunikation abfangen und mit den 
Funkpaketen vergleichen" - war aber leider nix, die Schnittstelle wird 
nicht benutzt. Ich muss jetzt also herausfinden, wo der NRF mit dem 
anderen uC kommuniziert. Ich vermute mal, dass irgendwo noch eine UART 
lauert.

Den "USB"-Anschluss werde ich mir auch noch genauer ansehen, der scheint 
nämlich der Beschriftung nach ebenfalls eine UART zu sein. Mal schauen, 
was die ausgibt. Gibt also noch bisschen was zu tun...

Soweit für heute, ich melde mich, wenn ich mehr herausgefunden habe.
Schönen Sonntag euch allen.

[Carsten B. (carstenb)]

Hallo Martin,

sehr cool. Ich bin leider wehen ständigem Streß auf der Arbeit und 
Mistwetter nicht weiter gekommen. Ich wollte eines meiner NRF24-Module 
dicht an den Hoymiles auf dem Dach positionieren.

Mal sehen, grad kommt die Sonne raus ...

Carsten

[Super (Gast)]

Super Martin,

wenn etwas brauchbares herauskommt, beteilige ich mich an den Aufwand 
gern mit einer Spende!

Danke an ALLE

[Fritzdect (Gast)]

Ich hab hier ein Projekt gefunden:
https://github.com/Eule01x/NETSGPClient-for-Hoymiles

[Fritzdect (Gast)]

Fritzdect schrieb:
> Ich hab hier ein Projekt gefunden:
> https://github.com/Eule01x/NETSGPClient-for-Hoymiles

Sorry, ist oben bereits erwähnt

[Fritzdect (Gast)]

Ich hab den HM-600 erst bekommen. Sobald er in Betrieb ist, werde ich 
das Example hier mal auf einem Nordic Board testen. Mal sehen ob dieses 
Protokoll verwendet wurde:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fesb_users_guide.html&cp=5_0_0_5_2

[Hubi (Gast)]

Ich steige mal wieder mit ein.
Folgende Überlegung: wenn dieses Teil über USB eine 
Programmierschnittstelle hat, könnte man doch die Firmware mittels 
esptool auslesen. Und es gibt einige Reverse engeneering tools (wie zB 
Ghidra) , mit denen man wieder C-code generieren kann. Vllt lässt sich 
darüber etwas über die benötigten Infos wie Kanal, Adressen etc 
rausfinden.

[martin (Gast)]

Hallo zusammen,
ein kleines bisschen bin ich auch weiter gekommen mit meinem Reverse 
Engineering der DTU.

Zuerst musste ich aber lernen, dass das erste Funksignal im meinem 
oberen Beitrag k*cke aussieht. War nicht richtig abgetastet. Hier ein 
Bild wie es aussehen muss. Das kann man dann auch schön demodulieren, um 
daraus die Bitfolge auslesen zu können. Damit muss ich allerdings noch 
ein bisschen hin und her experimentieren, weil ich nicht genau weiß wie 
viele Bits der NRF tatsächlich sendet.

Deshalb habe ich mir gleichzeitig die Platine noch ein bisschen näher 
angeschaut. Die im Bild markierten Testpunkte sind Rx/Tx einer seriellen 
Schnittstelle zwischen dem NRF und dem GigaDevice, welche ich mir dann 
mit dem Logic angeschaut habe - die Baudrate ist übrigens 125.000 
Baud/sec.
Dadurch erhoffe ich mir Rückschlüsse, ob das Funksignal auch richtig 
demoduliert wurde - ich habe jedenfalls schon übereinstimmende Sequenzen 
gefunden. Aber für belastbare Daten und eine saubere Analyse brauche ich 
mehr Zeit...

Wenn ich dann mal weiß, wie viele Byte der NRF sendet werden und was die 
Adressen sind, versuche ich einen eigenen NRF mithorchen zu lassen.

Schönen Rest-Sonntag noch.
Gruß, Martin

[Einhart P. (einhart)]

Danke Martin,
mit dem Ansatz hast du eine gute Grundlage geschaffen.

[Hubi (Gast)]

Hallo Martin
hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von 
Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die 
Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, 
und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte.

[martin (Gast)]

Hubi schrieb:
> Hallo Martin
> hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von
> Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die
> Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen,
> und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte.

Hallo Hubi,
ja, das Enhanced Shockburst hab ich mir angeschaut - dürfte passen.
Ich habe hier mehrere Re-Transmits eines Pakets untereinandergelegt, die 
sich (halbwegs) sauber demodulieren ließen (bisschen Jitter ist in den 
einzelnen Bitfolgen).
Es tauchen vertraute Zahlenfolgen darin auf, nämlich jeweils die letzten 
8 Ziffern (=Hex) der Seriennummern von Inverter und DTU. Siehe Beispiel 
- möchte meine Seriennummern nicht preisgeben ;-)

Die eigentliche RF-Payload ist 27 Byte. Das passt auch zu dem, was der 
NRF seriell an den Controller schickt - das sind 29 Byte, wobei das 
erste und letzte Byte immer gleich sind (0x7E..0x7F). Ich vermute mal, 
die werden als Start- und Endmarker benutzt oder als Commands für den 
uC.

Die Datenrate müsste 250 kbps sein, das habe ich mal mit einem eigenen 
NRF und einem Sendetest quergeprüft.

Ich konnte bisher noch nicht herausfinden, welche CRC verwendet wird und 
ob die Payload selbst auch nochmal mit einer CRC versehen ist.
Als nächstes will ich deshalb untersuchen, welche Daten in der Payload 
versteckt sind. Da müssten sich ja theoretisch die Leistungs- und 
Stromwerte finden lassen, die die App anzeigt. Das wird aber nochmal ein 
größerer Brocken Arbeit...

Vielleicht gelingt mit diesen Informationen ja dem ein oder anderen auch 
schon eine Kommunikation?

[Super (Gast)]

Ich lobe mal einen Preis von 50€ aus für einen funktionierenden Clone.

Das Biest auf meinem Dach soll mir sagen was los ist;-)

[Wolfgang (Gast)]

Hubi schrieb:
> Dein Abtast sieht danach aus, denn da findet man die
> Startsequenz 0x55.

Ein 0x55 sagt über das Protokoll eher wenig aus. Das ist eine 
Standardsequenz, die eigentliche jede Funkübertragung benötigt, damit 
sich der Empfänger einpegeln kann.

[Fritzdect (Gast)]

Hallo Martin,

hast du in der Spec vom Nordic den Abschnitt von der CRC gesehen:

CRC (Cyclic Redundancy Check)
The CRC is the error detection mechanism in the packet. It may either be 
1 or 2 bytes and is calculated over the address, Packet Control Field 
and Payload.
The polynomial for 1 byte CRC is X8 + X2 + X + 1. Initial value 0xFF.
The polynomial for 2 byte CRC is X16+ X12 + X5 + 1. Initial value 
0xFFFF. No packet is accepted by Enhanced ShockBurstTM if the CRC fails.

Das könnte helfen, die verwendete crc herauszufinden

https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf

[martin (Gast)]

Hallo zusammen,
hier mal wieder ein Update zur Protokoll-Analyse.

Ich habe nun etwas mehr Durchblick bei der Kommunikation erreicht. Also 
es ist definitiv das Enhanced Shockburst Protokoll. Das direkt per 
RadioHacker zu analysieren ist schwierig, da es nicht immer exakt 
demoduliert wird - hinzu kommen die 9 Bit Status-"Byte", die die 
erkannte Bitfolge um 1 verschieben ggü. der eigentlichen Payload. 
Ziemlich unschön. Aber wenn man damit die Randbedingungen geklärt hat, 
gibt es eine bessere Methode: Sniffen mit dem nrf24sniffer von yveaux.

Er hat ein kleines Arduino-Programm für einen Nano mit nrf24, sowie ein 
Windows-Tool, das mit Wireshark gekoppelt wird - Anleitung auf seiner 
Homepage, siehe GitHub-Link.

https://github.com/Yveaux/NRF24_Sniffer

Dazu muss man noch folgende Startparameter wissen:
-Die Empfängeradresse des Inverters entspricht den letzten 8 Stellen der 
Seriennummer, aber umgedreht (Little Endian) - 00 anhängen nicht 
vergessen, da die gesamte Adresse des NRF 5 Byte lang ist.
-Die Datenrate ist 250 kbps, max. Payload 32.

Man kann das Tool dann hiermit starten (siehe Screenshot) und bekommt 
die Datenpakete in Wireshark serviert. Der oben bereits beschriebene 
Protokoll-Aufbau (innerhalb der Payload) scheint zu passen, eine CRC 
konnte ich darin nicht ausfindig machen - die des NRF wird mit diesem 
Tool automatisch geprüft.

So konnte ich das was die DTU sendet direkt auf dem Rechner empfangen.
Im nächsten Schritt hänge ich einen 2. NRF mit der Adresse der DTU dran, 
um das was der Inverter zurück schickt abzufangen. Und dann geht es 
darum, den Inhalt zu identifizieren - einen offensichtlichen 
Zusammenhang zu den physikalischen Größen habe ich leider noch nicht 
entdeckt. Scheint aber eine Menge Overhead drin zu sein...

[Hubi (Gast)]

Hallo Martin
ich verfolge sehr intensiv deine "Forschung". Bin gerade dabei, das 
ganze mit einem Aruino pro mini und eine nrf24 nachzubauen, aber es 
kommt keine Kommunikation zustande, WR antwortet nicht.
Vllt könntest du mir folgendes kommentieren:
(nur zur Info: ich benutze Lib RadioHead, die macht von Hause aus schon 
das enhanced SB)
1) wenn mein WR die Ser.Nr. 112233445566 (dezimal), so nehme ich letzte 
8 Stellen, also 33445566, daraus in Hex 0x01FE56BE und setzte damit im 
nRF die Adresse mit dem byte-Array {BE,56,FE,01,00}, oder muss das 0x00 
vorne hin?
2) in der payload setzte ich nach der 0x15 wiederum die Adresse des WR 
(BE,56,FE,01) und danach den Rest wie in deinem Bild vom WireShark (72 
81 88 ...).

Aber es passiert nichts, keine Antwort vom WR.
Eine Idee? Wenn nicht wartete ich weitere Ergebnisse ab.

[Hubi (Gast)]

mein Punkt 2 ist falsch: ich schreibe die Adresse des WR natürlich in 
umgekehrter Reihenfolge, also (01,FE,56,BE)

[martin (Gast)]

Hallo Hubi,

nein, die Adresse des WR nicht in Hex umwandeln sondern direkt (die ist 
quasi schon Hex). Also aus deiner SN wird Ox66554433 als erste 4 Byte 
der Adresse für den NRF im Inverter. Plus vermutlich 01 als 5. Byte.

Dann die Ox15 als (irgendein) Kommando. Der WR antwortet an dieser 
Stelle mit 0x95.

Danach die Empfangsadresse nochmal richtig rum innerhalb der Payload, 
sowie die Sendeadresse. Die 72818832 ist die Seriennr. meiner DTU, da 
kannst du also theoretisch irgendwas nehmen, was du deinem NRF als 
"DTU"-Adresse gibst.

Die 0x80 OB nach den Adressen scheint auch immer da zu sein. Ich weiß 
noch nicht, wofür das steht. Genauso wenig wie ich bisher über die 
restlichen 16 Byte weiß...

[Hubi (Gast)]

Martin, Danke für die ausführliche Erklärung.
Aber auch damit habe ich bisher keinen Erfolg, leider. Da muss noch 
irgendwas anderes nicht stimmen, payload dynamisch oder fix, auto ack, 
???

[martin (Gast)]

Hallo Hubi,
ich vermute Mal, dass die "DTU" zuerst eine Initialisierung schicken 
muss. Habe aber keine Ahnung wie die aussehen muss.
Dieses Wochenende komme ich auch nicht mehr dazu weiterzumachen, bin 
unterwegs...
Melde mich, wenn ich mehr weiß.

[Martin G. (petersilie)]

      WLAN                       Nordic
                                 2.4 GHz
      \|/                         \|/
       |                           |
   +-------+      (A)(?)    +-----------+
   | ESP32 | <------------> | NRF24LE1E |
   +-------+                +-----------+
       ^                          ^
       |                          |
       |       +----------+       |
       +-----> | GD32F303 | <-----+
         (B)   +----------+   (C)
              
     ABBILDUNG 1: Systemübersicht "DTU"

Hallo zusammen,

ich stelle mir gerade die Frage, welche Wechselrichter ich mir für mein 
geplantes "Balkonkraftwerk" zulegen soll. Auch für mich wäre eine 
direkte Kommunikation zum Wechselrichter (ohne Hersteller-"Cloud"-Zwang) 
sehr attraktiv.

Die Ermittlungen von @martin sind sehr interessant.

Da ich auch beruflich mit ähnlich aufgebauten Systemen zu tun habe, 
wollte ich mal darstellen, welche Möglichkeiten ich kenne, solch ein 
System aufzubauen.

Vielleicht hilft das ja, mit der Analyse weiterzukommen.

Also: Das "DTU" scheint nach @martins Analyse aus folgenden drei 
Hauptkomponenten zu bestehen (siehe Abbildung 1):

 - ESP-12F: Das ist ein komplettes "System on Module" mit ESP8266
   Mikrocontroller und integriertem WLAN. Theoretisch könnte die
   gesammte "Intelligenz" darauf programmiert sein.

 - NRF24LE1E: Das ist auch ein komplettes "System on Chip":
   (https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [1]).
   Es besteht aus einem direkt an einen allgemeinen Mikrocontroller
   gekoppelten RF-Frontend.
   Wenn wir auf der Schnittstelle zwischen Controller und RF-Frontend
   lauschen könnten, hätten wir gewonnen. Aber das wird nix, denn die
   ist "im Chip".

 - GD32F303: Der dritte Controller im System. Allein die Tatsache, dass
   dieser überhaupt vorhanden ist, deutet IMHO darauf hin, dass die
   "Hauptintelligenz" des "DTU" hierauf implementiert ist. Denn
   technisch hätten die anderen beiden Subsysteme beide genug
   Rechenpower/Speicher/etc, um ohne weitere Hilfe die Aufgabe des
   "DTU" zu erledigen.

Belauschen können wir die Kommunikation zwischen den Chips, also die 
Wege (A), (B) und (C). (A) gibt es vermutlich nicht, wenn der GD32F303 
die zentrale Steuerung macht - dann muss WLAN und Nordic nie miteinander 
reden.

Die Kommunikation (B) zum WLAN ist im ersten Schritt vermutlich eher 
uninteressant.

Bleibt also die Verbindung (C) zwischen GD32F303 und NRF24LE1E.

Hier können wir nun "Glück" oder "Pech" haben, oder irgendetwas 
dazwischen:

"Glück"-Szenario: Auf dem Mikrocontroller des NRF24LE1E läuft nur eine 
ganz einfache Software, die eingehende Bytes/Pakete 1:1 an das 
eingebaute RF-Frontend durchreicht.

"Pech"-Szenario: Auf dem Mikrocontroller des NRF24LE1E ist eine Software 
implementiert, die "Kommandos" vom GD32F303 empfängt, und diese dann 
selbst in passende RF-Pakete übersetzt. Und eventuell auch mit einem 
fest im Controller hinterlegten Schlüssel verschlüsselt (die eingebaute 
Verschlüsselungs-Hardware ist ein Grund, warum man solch ein System so 
entwerfen würde).

Im "Glück"-Szenario hätten wir so gut wie gewonnen. Wir könnten quasi 
die RF-Kommunkation mitlesen, und sie somit auch mit einem eigenen 
NRF24LE1E nachbauen. Ganz unwahrscheinlich ist das nicht, denn dieses 
Szenario ist natürlich (von Herstellerseite) einfacher zu 
implementieren, als auch noch für den NRF24LE1 "kompliziertere" Software 
zu schreiben. Und mir scheint, es steht zumindest nirgendwo in der 
Werbung, dass die Wechselrichter "verschlüsselt" kommunizieren.

Meine Frage an @martin wäre also: Kannst Du die Verbindung (C) irgendwo 
entdecken und darauf mithören? Am wahrscheinlichsten sind das einfach 
eine RX und eine TX Leitung zwischen den beiden Chips (UART). Der 
Mikrocontroller hat laut Datenblatt ([1], s.o.) genau eine serielle 
Schnittstelle, bei dem verbauten 32-pin-Gehäuse sollten die hier sein:

 - P0.4 (Pin  7): RXD
 - P0.3 (Pin 10): TXD

Auf Deinen Fotos passt das auch insofern, als diese Pins jeweils in ein 
Via gehen. Da könntest Du mal versuchen, die Leiterbahnen zu verfolgen. 
Oder direkt da mit einem Tastkopf abgreifen. An einem Oszi sollte sich 
da schnell ein Signal zeigen und die Datenrate lässt sich dann 
rausmessen.

(Die GND, CVV, ROG, SCK, SI, SO, SCN, RST Kontakte sind vermutlich "nur" 
die Programmierschnittstelle für den NRF24LE1 und werden im Betrieb 
keine Daten übertragen.)

Jetzt bin ich mal gespannt, ob Ihr mit meiner Analyse übereinstimmt, und 
natürlich, ob @martin auf den Pins sinnvolle Signale mitlesen kann!

Viele Grüße

-- Petersilie
(sorry, Vorname ist auch "Martin" - davon haben wir schon mehrere in 
diesem Thread...)

[martin (Gast)]

Hallo Martin/Petersilie ;-)

ja, die beiden Testpunkte gehen an die Rx/Tx Pins des NRF24LE1E.
Ich habe auch schon die Kommunikation zwischen NRF24LE1E und GD32F303 
mit dem Logic Analyzer mitgeschnitten. Es sieht tatsächlich so aus, als 
würde der NRF nur "stupide" als Transceiver benutzt.

Ich vermute, wie du oben beschrieben hast, dass die Logik im Gigadevice 
sitzt und der ESP ebenfalls nur als Gateway zur Cloud dient. Die DTU 
stellt übrigens auch permanent ein WLAN zum direkten Zugriff bereit per 
App (das ist eher unschön, wenn man das Ding dauerhaft im Einsatz hat).

Die bisherige Untersuchung zeigt, dass die Pakete "on air" 1:1 den 
seriellen Datenpaketen entsprechen. Jetzt geht es also darum, aus den 
seriellen Daten schlau zu werden. Ein paar Randbedingungen konnte ich 
schon klären, z.B. kommt immer die Seriennummer des Inverters bzw. der 
DTU im Paket vor (Absender und Empfänger-Adresse).

Leider habe ich im Moment wenig Zeit, weiter an dem Protokoll zu 
forschen.
Ich versuche euch demnächst mal eine Excel-Tabelle mit den 
aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit 
den Daten bereits was anfangen. (Einschalten der DTU, Verbindung zum 
Inverter, Regelmäßige Abfrage).

[Martin G. (petersilie)]

martin schrieb:
> Ich versuche euch demnächst mal eine Excel-Tabelle mit den
> aufeinanderfolgenden Paketen bereitzustellen,

Das wäre spitze. Einfach mitschneiden. Muss nicht aufwendig aufbereitet 
sein. Eventuell kannst Du auch einfach ein Terminalprogram (HTerm o.ä.) 
aufzeichnen lassen. Was auch super funktioniert sind diese Saleae 
Logik-Analyser, falls Du zufällig so einen hast. Wäre doch gelacht, wenn 
wir bei diesen Erkenntnissen und der Vorarbeit dem Protokoll nicht 
vollends auf die Schliche kommen würden!

[Hubi (Gast)]

Bin auch dabei, wenn genügend Daten über die Kommunikation da sind, an 
einem Klon mit zu programmieren. Man müßte halt vom 1. Anschalten der 
DTU, über Registrierung des WR bis hin zur dauernden Übertragung der 
Daten von WR zu DTU mal alles aufgezeichnet haben. Verschlüsselt ist da 
wohl nichts, sonst könnte man die Seriennrn nicht rauslesen. Bin schon 
ganz gespannt auf die Daten!

[Martin G. (petersilie)]

Hab mir die Bedienungsanleitungen für die DTUs mal durchgelesen. Sieht 
mir so aus, als müsse es eventuell gar keine "Verbindungsaufnahme" o.ä. 
geben.
Der DTU sagt man einfach, welche Seriennummern die Wechselrichter haben, 
und die DTU fragt dann regelmäßig alle eingetragenen Wechselrichter ab.
Insofern also "einfach" mal die RX und TX Bytes für einige Zeit 
mitschneiden (ein ganzer Tag wäre ultimativ), dann sehen wir hoffentlich 
irgendwelche Muster in der Payload, über die wir dann auf den Inhalt 
schließen können.

[Martin K. (Gast)]

Super Projekt das ihr da Versucht umzusetzen.

Ich habe seit ein paar Tagen einen HM700 und eine DTU WLite. Ich habe 
allerdings sogar das Probelm das die DTU bei mir gar nicht richtig 
hochfährt und ich nur ein WLAN das AiThinker heisst angezeigt bekomme.

Fahre ich ein paar Kilometer weit weg, fährt der Stick hoch und zeigt 
mir das DTU WLAN an. Habt ihr dazu eine Idee? Eine Alternative zu dem 
Stick wäre mir auch am liebsten! Die Cloud braucht ja keiner ;)


LG
Martin

[Hubi (Gast)]

Überlagerung der Wifi-Kanäle?

[Martin K. (Gast)]

Hab ich mir am Anfang auch gedacht, nur sind fast keine anderen WLAN 
Signale in der nähe. Hab dann auch schon mein eignes Mesh Wlan 
abgedreht, bringt keine Besserung. Auch in der restlichen Ortschaft 
funktioniert es nicht. Nur beim Bahnhof... sehr strange das ganze...

Aber egal, ich beobachte eure Vortschritte weiter, der Stick geht aber 
auf jeden Fall wieder zurück.

LG
Martin

[Marcel (Gast)]

Hallo,

ich würde sehr gerne helfen, da ich auch einen HM-400 habe und dessen 
Daten auslesen möchte. Ich hab den Thread hier schon verfolgt, aber 
bisher noch keinen Code gesehen. Wie schafft Ihr es, dass der 
Wechselrichter antwortet? Ich würde sehr gerne helfen und die Antworten 
des Wechselrichters auswerten / analysieren. Derzeit bekomme ich aber 
noch nicht mal eine Antwort.

#include <Arduino.h>
#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

/**
 * CSN 5
 * CE 4
 * MOSI 23
 * SCK 18
 * IRQ
 * MISO 19
 * 
 * FCC URL: https://fcc.report/FCC-ID/2ARNB-DTUW100
 * Allowed Frequency: 2403, 2423, 2440, 2461 or 2475MHz
 *           Channel:  1     1      8     10     13
 * Tested Channels: 1, 3, 6, 9, 11 (FCC)
 */

// ---- Radio Setup ----
RF24 radio(4, 5); // CE, CSN

// serial no hoymiles: 112234567890

const uint64_t deviceID[1] = { 0x0987654301 };


// ---- Program Values ----
const int unitNumber = 0;         // Sets the pair out of the 6 programmed channels

int dataSend = 0;
int dataReceive = 0;

int channels[5] = {3, 23, 40, 61, 75};

//============  Send/Recieve Function  ============
void rxtx() {

    for( int i = 0; i < sizeof(channels)/sizeof(channels[0]); i++ ) {
        int iChannel = channels[i];

        Serial.print("rxtx Start");
        Serial.print(" ");
        Serial.println(iChannel);

        uint8_t deadPool = 0x15;
        uint8_t frankCastle = 0;
        int iTx = 0;
        int iRx = 0;

        radio.setChannel(iChannel);

        radio.printPrettyDetails();

        //Begin Transmission and send for 10ms
        for (int iTx=0; iTx <= 10; iTx++){
            radio.stopListening();
            radio.write(&deadPool, 1);
            delay(1);
        }

        //Begin Receive and listen for 10ms
        for (int iRx=0; iRx <= 10; iRx++){
            radio.startListening();
            radio.read(&frankCastle, 1);
            delay(100);
        }
        dataSend = deadPool;
        dataReceive = frankCastle;
        Serial.println("RxTx Cycle Finished");
        Serial.println(dataSend);
        Serial.println(dataReceive);
        Serial.println("");
    }
}


void setup() {
  // ---- Activate Radio ----
    Serial.begin(115200);

  radio.begin();
  radio.openWritingPipe(deviceID[unitNumber]);
  radio.openReadingPipe(unitNumber, deviceID[unitNumber]);
  radio.setPALevel(RF24_PA_MIN);
  radio.setPayloadSize(1);        // Sets payload to 1 byte
  radio.setDataRate(RF24_250KBPS);
  radio.setAutoAck(unitNumber, false);

//   radio.printDetails();
}

void loop() {
    // Serial.println("Loop Start");
    rxtx();
    // Serial.println("Loop End");

    delay(1000);

}

Vielen Dank
Marcel

[martin (Gast)]

martin schrieb:
> Ich versuche euch demnächst mal eine Excel-Tabelle mit den
> aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit
> den Daten bereits was anfangen.

Hallo zusammen,
im Anhang findet ihr eine Excel-Tabelle mit Daten die ich vor kurzem 
aufgezeichnet hatte. Es handelt sich dabei um die INTERNE Kommunikation 
in der DTU zwischen dem GD32 und dem NRF - die ersten 15 Sekunden nach 
Einschalten.
Diese Daten entsprechen nach meinem Kenntnisstand fast 1:1 der 
Funkkommunikation mit dem Inverter (siehe Tab 3 in der Excel).

Einiges, was ich identifizieren konnte, habe ich bereits markiert - 
vielleicht könnt ihr weitere Teile entschlüsseln. Leider ist es nicht 
ganz so offensichtlich, wo sich die Daten zu Strom, Spannung und 
Leistung wiederfinden lassen.

Aber vielleicht könnt ihr mit diesen Infos ja bereits einen NRF mit 
eurem Inverter kommunizieren lassen. Ich vermute, dass die Kommunikation 
von der DTU initiiert werden muss, da man dort die Seriennr. des 
Inverters einträgt. Der antwortet dann nur, wenn er seine Nummer "hört" 
(ab dem 2. großen Kommunikationsblock im Tab 2).

[Carsten B. (carstenb)]

Hallo Martin,

vielleicht eine blöde Frage, aber hast du mal mit einem Hexeditor auf 
die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Die 
Aufbereitung in Excel ist Klasse für die Doku, aber für das Handling der 
Daten finde ich es eher unpraktisch. Vielleicht kannst du auch noch die 
Rohdaten als Binärfiles zur Verfügung stellen?

Da ich mittelfristig eh einen zweiten HM brauche, habe ich gestern einen 
bestellt. Dann kann ich den "unter den Schreibtisch" legen und komme 
vielleicht auch weiter. Vom Dach empfange ich keine Daten, bzw. kann sie 
in all den "Stördaten" nicht identifizieren. Ich würde es dann mal mit 
HM und dem NRF24 in einer "Blechkiste" zur Abschirmung versuchen. Sendet 
der HM eigentlich auch Daten, wenn die Panels nichts liefern?

VG

Carsten

[martin (Gast)]

Carsten B. schrieb:
> hast du mal mit einem Hexeditor auf
> die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster?

Hallo Carsten,
habe deinen Vorschlag mal mit den vorhandenen Daten umgesetzt, siehe 
Binary anbei. Mit HxD war auch kein Muster direkt erkennbar, neben dem 
von mir bereits markierten Aufbau der Datenpakete. Wegen der verschieden 
Länge der Pakete habe ich diese jeweils mit 00 aufgefüllt - so sieht es 
wenigstens angenehmer aus ;-)

[martin (Gast)]

Marcel schrieb:
> Wie schafft Ihr es, dass der
> Wechselrichter antwortet?

Hallo Marcel,
mit einem eigenen NRF hat es bisher noch keiner hier geschafft.
Ich hatte mir die DTU ("Data Transfer Unit"?) vom Hersteller gekauft, um 
damit das Protokoll abzufangen und analysieren zu können. Darin werkelt 
ebenfalls ein NRF auf den ich mich in meinen bisherigen Texten bezogen 
habe.

[Pascal A. (pasarn)]

Hi,

ich bin auch am Überlegen mir eine PV zu kaufen. Die meinsten Angebote 
sind mit dem HM Wechselrichtern. Für die Integration in meine 
Hauselektronik will ich aber keine Cloud. Daher kommt mir der Bertrag 
sehr gelegen. Mal sehen, wo ich helfen kann.

Ich hab mir mal die Binärdaten angesehen und noch Werten gesucht, welche 
normalerweise stabil sind. (Netzfrequenz und Netzspannung)

Wenn mich nicht alles teucht, könnten es die Bytes (Big-Endian) im 
Screenshot sein.

Gruß
Pascal
PS: Hier gibt es noch die Modbus Register der DTU Pro. Vielleicht läst 
sich daraus etwas ableiten.
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

[Pascal A. (pasarn)]

Hi,

hab noch was rausgefunden:

Das letzte Byte vor dem EOF (0x7F) ist ein CRC8 mit poly=1 init=0 xor=0

Hoffe, dass konnte weiterhelfen.

Gruß
Pascal

[Pascal A. (pasarn)]

Noch mehr Bytes.

[martin (Gast)]

Hallo Pascal,

sehr gut, das sind schon mal hilfreiche Infos - das erste Byte nach den 
Seriennummern scheint zu kennzeichnen, welche Werte folgen.
Bei den von dir vermuteten Netz-Ausgangsdaten (scheint zu passen) war es 
jeweils die ID 0x02 an Byte[10].

[Pascal A. (pasarn)]

Hi Martin,
mit der 0x02 passt nicht immer. In deiner Excel Datei Spalte AW ist eine 
Antwort, wo es nicht passt.

[martin (Gast)]

Hallo Pascal,

stimmt. Auf den ersten Blick würde ich vermuten, dass es an der Abfrage 
durch die DTU liegt.
Die 0x80 an Byte[10] heißt wohl lesen - danach folgt i.d.R. die 0x0B für 
Ist-Werte. In dem von dir genannten Fall (Spalte AW) ist es aber die 
0x11.
Es dürften also irgendwelche anderen Werte folgen.

[Pascal A. (pasarn)]

Hi Martin,

hast du noch mehr Daten zu deinem Wechselrichter?
Vielleicht sind es Daten zu Einstellungen, Firmware, ...

[martin (Gast)]

Pascal A. schrieb:
> hast du noch mehr Daten zu deinem Wechselrichter?
> Vielleicht sind es Daten zu Einstellungen, Firmware, ...

Hallo Pascal,
morgen kann ich dir mehr sagen - heute komme ich nicht dazu, weil mein 
Wechselrichter leider noch nicht fest installiert ist. Ich würde ihn ja 
gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn 
dadurch abschieße...

[Einhart P. (einhart)]

martin schrieb:
> Ich würde ihn ja
> gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn
> dadurch abschieße...

Spannung im zulässigen Bereich und passende Strombegrenzung - dann kann 
nichts passieren. Am besten die Spannung niedrig halten damit der MPPT 
noch nicht arbeitet. Dann kannst du wunderbar verschiedene nahezu 
konstante Bedingungen schaffen und die zugehörigen Daten untersuchen.

[Frank H. (fh_)]

Hallo,
ich bin auch interessiert, da eine Anschaffung geplant ist.
Ich habe mir die Daten auch mal angeschaut.
Der 'PackageCounter' und die drei davorliegenden Bytes sind die Uhrzeit
in BigEndian time_t 32-bit => 13.02.2022 13:16:04.

Sieht man in der Oberfläche die Today Production / Total Production in 
Wh?
Laut Modbus Beschreibung sollten dies 2 bzw 4byte sein.

Interessant sind die beiden vorletzten Bytes vor dem 0x7F;
ggf auch eine Art zusätzliche Prüfsumme? Das Byte direkt vor dem 7F ist 
ja eine CRC8.
Hilfreich wäre m.E. auch mal eine andere Seriennummer zusätzlich zu 
probieren um zu sehen was sich bei der Anfrage hier ändert.

VG
Frank

[Martin G. (petersilie)]

Super!

Ich habe mal versucht, die bisherigen Erkenntnisse in der angehängten 
Textdatei zusammenzufassen. Vielleicht gewährt das ja noch neue 
Einblicke. Gerne erweitern!

[Hubi (Gast)]

Das 1. Init (mit den 8 Nullen) scheint mir eine Broadcast zu sein, aber 
über welche Adresse wird das verschickt?
In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn 
Adresse WR ist ja noch nicht bekannt, aber der sch... WR antwortet 
einfach nicht.

[Thomas B. (tbnobody)]

Hubi schrieb:
> In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn
> Adresse WR ist ja noch nicht bekannt

So wie ich das Verstanden habe  gibt man die Seriennummer(n) der WR in 
der DTU (oder in der Cloud) ein bevor eine Kommunikation möglich ist. 
Dadurch wäre die Adresse des WR schon bekannt.

Aber andererseits antwortet der WR mit der Adresse der DTU. Die ja nicht 
bekannt wäre wenn die nicht im ersten Frame enthalten wäre.

Könntest du ggf. dein Testprogramm sharen? Habe hier einen HM-1500 sowie 
NRF24 Module. (nur aktuell noch keine Zeit gehabt einen Testaufbau zu 
machen bzw. Abends ist der WR meist schon aus)

[Hubi (Gast)]

Anbei mein Testprogramm. Wer will kann es gerne weiterbenutzen und 
anpassen. Vllt hat ja jmd mehr Erfolg als ich.

[Thomas B. (tbnobody)]

Danke für den Sourcecode!

Ich mag mich täuschen, aber sollte das hier:

void tele7 () {
//=============
  memset (data, 0, 32);
  data[0] = 0x07;
  data[10] = 0x07;
  datalen = 11;  
}

nicht eher so aussehen:

void tele7 ()
{
    memset(data, 0, 32);
    data[0] = 0x7e;
    data[1] = 0x07;
    data[11] = 0x07;
    data[12] = 0x7f;
    datalen = 13;
}

Nachdem im Excel vorher die komplette Payload dargestellt ist müsste 
doch das 0x7e und 0x7f mit dazu oder verstehe ich was falsch?

[Hubi (Gast)]

Hallo Thomas
so wie ich die Excel-Tabelle verstanden habe ist das ein Mitschnitt 
innerhalb der DTU, also zwischen der "CPU" und dem NRF. Und diese 
Kommunikation startet mit 7E und endet mit 7F. Aber Martin kann das 
bestimmt klären.

[Martin G. (petersilie)]

Wir müssen unterscheiden zwischen

(a) den Nachrichten zwischen dem GD32F303 und dem NRF24LE1E [1], und
(b) den Nachrichten, die der µC im NRF24LE1E an den darin eingebauten 
"nRF24L01+"-kompatiblen Transceiver sendet.

Martins Radio-Mitschnitt hat bewiesen, dass der "nRF24L01+"-Teil nach 
dem Nordic "enhanced Shockburst" Protokoll funkt.

Dieses beinhaltet insbesondere immer eine Zieladresse. Siehe [1], 
Kapitel 3.4.3:
- Preamble 1 byte
- Address 3-5 byte
- Packet Control Field 9 bit
- Payload 0-32 byte
- CRC 1-2 byte

Für Shockburst gibt es leider keinen einfachen (d.h. 
NRF24LE1E-basierten) "Sniffer", um alle Nachrichten mitzulesen. Daher 
das weiter oben erwähnte Projekt in [2].

Unser Ziel ist ja wohl, mit einem einfachen "nRF24L01+" direkt mit 
einem/mehreren Wechselrichtern zu sprechen.

Dazu müssen wir zu jeder der von Martin zwischen GD32F303 und NRF23LE1E 
mitgeschnittenen Nachrichten auch wissen, wie diese Nachricht 
schließlich (als "enhanced Shockburst"-Nachricht) versendet wird.

Glücklicherweise scheint es sich herauszukristallisieren, dass die 
beiden sich sehr ähnlich sind.

Alternativ könnte man eventuell an diese Pakete "direkt" drankommen, 
wenn man im Wechselrichter mitliest - was ist denn dort verbaut? Auch 
ein NRF24LE1E, oder eventuell ein "nRF24L01+" Transceiver?

Ich könnte mir auch gut vorstellen, dass gewisse Nachrichten übernaupt 
nicht an den Transceiver (und somit in den Äther) gehen, so zum Beispiel 
die "Init" Nachricht. Vielleicht ist das lediglich eine Nachricht an den 
NRF24LE1E à la "mach' Dich bereit" oder so?

-- petersilie


[1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
[2] https://github.com/Yveaux/NRF24_Sniffer

[Martin G. (petersilie)]

Übersicht erweitert:
Nachrichten "02 28 23" und "82 00 03" ergänzt. Sauberer ausgerichtet. 
Python Beispiel für CRC.

[Thomas B. (tbnobody)]

petersilie,

du hast recht. Ich hatte verdrängt das auf den NRF24 selbst auch noch 
Logik vorhanden sein kann.
Ich würde jetzt mal unterstellen, dass der WR immer auf seine 
Seriennummer (= Adresse) lauscht und der DTU ebenfalls auf seiner 
Seriennummer.

In Init 1 (siehe deine Text File) würde die DTU zwar an die Adresse des 
WR ein Paket senden aber der WR würde nicht wissen an welche Adresse er 
antworten soll. Dies ginge erst ab Init 2 weil dort die DTU seine eigene 
Adresse an den WR schickt.

Bei der Durchsicht des Datenblattes [1] ist mir noch etwas im Kapitel 
3.4.3.3 aufgefallen. Dort wird u.a. das No Acknowledgment flag 
beschrieben.
Im Post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" wird 
beschrieben das das PCF 0D8 (== b011011000) ist. Was ja bedeutet das 
NO_ACK 0 ist.
"Setting the flag high, tells the receiver that the packet is not to be 
auto acknowledged."

Es ist low, also muss AutoAck true sein. Das wäre zumindest etwas was 
mir im Code von Hubi aufgefallen ist.
Ebenso wird im oben genannten Post beschrieben das Channel 3 verwendet 
wird.

radio.setAutoAck(true);
radio.setChannel(3);

[1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf

[Martin G. (petersilie)]

Ich hab mir jetzt mal solche NRF24-Platinchen geordert. Wir kennen die 
verwendeten Adressen. Somit können wir doch einen NRF24 auf die gleiche 
Adresse konfigurieren wie den Wechselrichter. Dann sollte der doch genau 
die Pakete von der DTU empfangen, oder was meint ihr?

Damit hätten wir dann einen 1:1 Mitschnitt der tatsächlichen Pakete in 
die Richtung DTU --> WR.

Später drehen wir das Spiel um, und konfigurieren den NRF24 auf die 
Adresse des DTU. Und hören wiederum zu.

Eventuell macht das "auto-ACK" Probleme - das man eventuell 
empfängerseitig nicht abschalten kann. Aber vielleicht reicht es, den 
"Zuhörer" schön weit weg zu platzieren, damit das ACK vom echten 
Empfänger gewinnt.

Leider habe ich (noch) keinen WR/DTU. Lieferprobleme überall. Wenn das 
mit den NRF24 klappt, könnte ich eventuell einen vorkonfigurierten Raspi 
zur Verfügung stellen, den dann ein stolzer Besitzer einer DTU (Martin?) 
mal lauschen lassen könnte...

Hubi hat ja wohl auch nur einen WR, aber keine DTU. Da ist nach den 
bisherigen Erkenntnissen mit Zuhören allein wohl leider nichts zu holen, 
da der WR ohne passende Frage auch nie antwortet.

[martin (Gast)]

Hallo zusammen,
gestern hatte ich versucht, den Wechselrichter mit einem Netzteil zu 
speisen - leider hat mir der MPP-Regler dazwischengefunkt und es hat 
sich kein stabiler Arbeitspunkt eingestellt. Ich glaube, es wird doch 
endlich mal Zeit für ein ordentliches Labornetzteil...

Freut mich, dass hier so viele helfen, das Protokoll zu knacken. Aber 
ich glaube, es herrscht hier noch ein bisschen Unklarheit über die von 
mir bereitgestellten Daten.

Deshalb nochmal ein Schema zur Klarstellung. Die obige Excel/Binärdaten 
zeigen die serielle Kommunikation innerhalb der DTU! Der NRF24LE1E 
ändert diese Pakete nochmal ab, bevor er sie an den Inverter 
rausschickt, inklusive Neuberechnung der CRC8.
Die Initialisierungssequenz dürfte also nur dazu da sein, den NRF24LE1E 
mit den benötigten Adressen zu versorgen. Die erste Kommunikation "on 
air" beginnt dann erst nach den 3 Init-Sequenzen - das wäre der 
Ansatzpunkt, den jeder mit einem Inverter und ein paar NRF24 Modulen mal 
in Angriff nehmen könnte:

-Enhanced Shockburst (ist voreingestellt)
-CRC 2 Byte
-250 kbit
-Kanal 3, 23, 40, 61 oder 75
-Paketlänge 27 Byte
-Empfänger-Adresse: Letzte 8 Stellen Inverter Seriennr. BCD in "Little 
Endian"

Und wenn dann das im Bild dargestellte Datenpaket gesendet wird, müsste 
euer Inverter theoretisch antworten.

[Hubi (Gast)]

Macht er aber nicht!
Ich habe folgendes
15 72 60 79 52 72 81 88 32 80 B 0 62 9 4 9B 0 0 0 0 0 0 0 0 2 29 31
an addrWR[5] = {0x52, 0x79, 0x60, 0x72, 0x01} gesendet, aber das 
Drecksding muckst sich nicht.
Meine Seriennummer WR ist xxxx72607952.
Die 31 ist die CRC8 der vorangehenden Bytes.
Das sollte doch alles passen!?

[martin (Gast)]

Hallo Hubi,

ja, die Sequenz sieht m.M.n. richtig aus. Hast du es mal auf den anderen 
Kanälen probiert?
Ist das in deinem Beispielcode enthalten? Dann könnte ich es mal bei mir 
probieren.

Oder es könnte doch noch weitere Inbetriebnahmeschritte geben. 
Vielleicht wird die DTU-Adresse bei der Einrichtung per S-Miles App im 
Inverter gespeichert?
Dazu müsste ich das ganze Setup nochmal neu machen, während ich die 
Pakete mitschneide.

[Hubi (Gast)]

Habe alle Kanäle ausprobiert, aber nix. Vllt ist auch die Entfernung zum 
WR zu groß. Sende hier vom Wohnzimmer durch Glastür in Richtung 
Gartenhaus mit dem WR aufm Dach.
Im Anhang nochmals das Testprogramm.
Als RF24 Lib benutze ich die von TMRh20
und die CRC-Lib findet man hier https://github.com/RobTillaart/CRC (bin 
zu blöd um Link einzufügen)

[Arnaldo G. (arnaldo_g)]

Hello all,

First of all, I don´t speak german, so I am following this thread using 
google translator, it´s not a problem for me. I have a DTU-W100 and five 
MI-1500 microinverters.

I have flashed a Logitech Unifying Dongle with the firmware from this 
repo
https://github.com/BastilleResearch/nrf-research-firmware

I left it running on channels 1,3,6,9,11,23,40,61 and 75 for all night, 
I don´t know if logged packages came from PV system. The dongle is a bit 
far from the MI and DTU, but today morning I put it about 2-3 meters 
from two MI-1500 and now I waiting for new data, but the code use DWELL 
for channel scanning, so probaly I am losting some packages.

If anyone need a specific channel scanner or sniffer or any other test, 
I can help in my spare time.

I hope this project will go forward!

[Martin G. (petersilie)]

Hi Arnaldo,

Welcome to the party!

Thanks for offering to help out with scanning/sniffing, and thanks for 
providing some results already!

Looking at the received packets, it seems to me that these are unlikely 
to be coming from your MI-1500s for the following reason:

I think we have already established that the devices (DTU/MIs) use the 
last 8 decimal digits of their respective serial numbers converted to 
BCD code as their "Shockburst" address. This implies that the address 
will never contain any of the hex digits A...F.

From your list, this only leaves a handful (if your hand happens to be 
six-fingered, that is) of packets, but these don't look familiar:

[2022-03-10 19:17:25.477]  11  21  55:15:57:55:BD  9A:AA:A8:2A:AA:AA:AA:AA:A2:97:AA:6A:AB:A9:AE:EA:AE:DA:79:2B:AA
[2022-03-11 04:14:56.172]   3   4  22:34:55:93:10  4C:01:2E:77
[2022-03-11 05:46:00.747]   6   0  24:01:05:45:0B
[2022-03-11 06:17:57.783]  75   1  14:01:51:14:25  25
[2022-03-11 07:00:49.999]  75   0  03:24:85:46:EA
[2022-03-11 07:06:58.018]   3  18  23:85:84:40:1F  23:5D:89:FA:D8:D5:B5:54:FA:FA:BA:A7:AC:90:C5:55:A8:C7

However, knowing the address that the inverters use means that we should 
be able to "sniff" specifically for packets to/from those addresses.

I am not familiar with the "nrf-research-firmware" tools, but it appears 
to me that you might be able to use the "nrf24-sniffer.py" tool to 
specifically follow packets sent to/from a particular address.

If your DTU serial number is, say, xxxx12345678, then this address 
should be 0x78,0x56,0x34,0x12 (possibly followed by 0x01 - not sure 
about that).

But first, let's see what today's data contains!

Very excited about this project gaining more participants.

-- petersilie

[Marcel (Gast)]

Hello Arnaldo,

thanks for the dump. I can see that your dump was mainly during the 
night. If i’m correct, the Hoymiles is not active in the night because 
the required start voltage is not generated by the solar panels. It 
would be beneficial if you try to “sniff” during a more or less sunny 
day. Even the last 5 byte pairs of your devices and DTU could be helpful 
for analyzing the dump.

Thanks a lot
Marcel

[Martin G. (petersilie)]

@hubi,@tbnobody

Zumindest was den Kommentar in Zeile 35 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") 
angeht ("// !!!! muss false sein sonst klappt senden nicht") kann ich 
Euch glaube ich beruhigen. Das Senden geht nicht schief, wenn Auto-ACK 
aktiviert wird. Vielmehr gibt die write()-Funktion zurück, ob ein ACK 
empfangen wurde (true), oder eben nicht (false), siehe [1].

Somit geht zwar das Senden nicht schief (das Senden gelingt wohl laut 
Spezifikation "immer"), aber der WR antwortet nicht (mit einem ACK).

[1] 
https://nrf24.github.io/RF24/classRF24.html#a4cd4c198a47704db20b6b5cf0731cd58

[Martin G. (petersilie)]

Marcel schrieb:
> I can see that your dump was mainly during the night.

Excellent point!

[Martin G. (petersilie)]

@martin

Bist Du sicher, dass die Pakete 5-Byte-Adressen verwenden, und nicht 
etwa nur vier?

Mir fiel nämlich auf, dass "Shockburst" das Einstellen der Adresslänge 
(zwischen 3 und 5 Bytes) zulässt. Die RF24-Lib hat dazu die Funktion 
setAddressWidth() ([1]).

Es scheinen ja nur die letzten 8 Dezimalziffern der Seriennummer in die 
(ersten vier Bytes der) Adresse umgesetzt zu werden. Bisher haben die 
Versuche oben dann als fünftes Byte ein "0x01" genommen, aber wo kommt 
das her? Hast Du das so auf dem Funk gesehen, oder ist das geraten?

[1] 
https://nrf24.github.io/RF24/classRF24.html#ad5aea7f9a3bd9c7d357fb296ce751f21)

[Hubi (Gast)]

Hallo Petersilie
habe mir den Source-Code angesehen und bin zu gleicher Erkenntnis 
gekommen. Mich hat halt nur gestört, dass das Senden immer das Ergebnis 
false lieferte. Aber was ist nun besser fürs testen, mit AutoACK=TRUE 
und Ergebnis=false oder doch besser Ack abschalten? Frage weil du halt 
geschrieben hast dass wohl AutoAck eingeschaltet ist laut deiner 
Mitschnitte (im PCF)? Bist du da sicher?

[Martin G. (petersilie)]

Was "besser" ist, ist eine gute Frage.

Tatsache ist, es ist sehr unwahrscheinlich, dass der WR antworten wird, 
wenn er nicht einmal ein ACK sendet. Insofern würde ich sagen, es ist 
"besser", mit eingeschaltetem AutoACK zu arbeiten.

Die Mitschnitte sind von einem anderen Martin - insofern muss ich die 
Frage weitergeben, ob das ACK-Bit in der beobachteten Kommunikation 
wirklich gesetzt ist, oder nicht...

-- petersilie

[Arnaldo G. (arnaldo_g)]

I attached the log from today, I think tomorrow I will listen just on 
channel 1, or if someonte have another idea please tell me.

@parsley
it´s my first time using the nrf-research-firmware tools, so I am trying 
to do something that can help, I need to identify a address and after it 
sniff just this address with nr24-sniffer.py.
To add a MI in hoymiles plataform you need to use the serial number of 
the MI so, I think, it is used to reach the device using the serial 
number.

@Marcel
yes, the dump was done in the night, because I flashed the dongle after 
the work and leave it running to try to catch something...  today I got 
a few packages, I really don´t know if it´s working as expected, but the 
main reason, I think, is because the DWELL for each frequency, tomorrow 
I will leave it on channel 1 and after I post the result here again....

last 5 bytes of the serial DTU and the nearests MI1500
DTU: 35453
MI1500: 36590
MI1500: 14456

[Martin G. (petersilie)]

@arnaldo_g
Your nrf-research sniffing efforts are much appreciated. This certainly 
has the potential to be very helpful indeed.

Unfortunately, there might yet be some obstacles to overcome:

I noticed that the "nrf24-scanner.py" uses "promiscuous mode" (which by 
itself seems to be a major hack, see posts above). This should not 
necessarily be a problem, since we think we know the addresses of the 
devices involved, and can therefore listen for packets specifically 
addressed to these.

But to make matters worse, it seems to me that the on-air bitrate is 
hardcoded to 2 MBit/s 
(https://github.com/BastilleResearch/nrf-research-firmware/blob/02b84d1c4e59c0fb98263c83b2e7c7f9863a3b93/src/radio.c#L41).

The Hoymiles inverters communicate at 250 kbit/s, so until you can 
switch the sniffer to that lower bitrate, you won't be seeing any 
meaningful data.

[Thomas B. (tbnobody)]

@martin, hattest du auch schon den traffic zwischen WR und DTU "in the
 air" mitgeschnitten? Ich frage mich nur, ob da das 5. byte auch immer 
0x01 ist wie bei der Kommunikation zwischen DTU und WR. Nicht das hier 
noch ein Problem liegt

[Martin G. (petersilie)]

@arnaldo_g
Another quick note regarding addresses. You helpfully list the serial 
numbers of your devices:
> last 5 bytes of the serial DTU and the nearests MI1500
> DTU: 35453
> MI1500: 36590
> MI1500: 14456

However, you will need the last 8 (not 5) digits to determine the 
address:

> DTU: 35453     --> Address will be 0x53,0x54,0x?5,0x?? (,0x01)
> MI1500: 36590  --> Address will be 0x90,0x65,0x?3,0x?? (,0x01)
> MI1500: 14456  --> Address will be 0x56,0x44,0x?1,0x?? (,0x01)

[Arnaldo G. (arnaldo_g)]

Hi!

@petersilie, you are right the datarate is wrong!

Thanks for the support, I recompiled the firmware for 250K and flashed 
the dongle again, and now I am seeing some packets with the serial 
numbers of MI, see the attached file, now I think we can go forward, I 
know the data is update at Hoymiles every 15 minutes the last number in 
address is always xx:xx:xx:xx:01. The dongle with this results is far 
from the MI, I will take it close again. If anyone have a idea to what 
channel/address to scan I can provide it.

[Martin G. (petersilie)]

Brilliant!!!

These all appear to be messages from your DTU (serial number 
...70:53:54:53) to various inverters.

They're all 11 Bytes long, and we're not seeing any replies.

Maybe some sort of "ping"?

Are your inverters running?

Not sure why we think that the DTU only communicates on the given 
channels (1 3 6 9 11 23 40 61 75).

My guess is that maybe the channels are selected based on serial number. 
Or maybe they are switched dynamically somehow...

Maybe you could try monitoring "all" available channels? Not sure how 
well that will work though - since at any given moment in time you will 
likely be looking at the "wrong" channel!

[Thomas B. (tbnobody)]

@petersilie @arnaldo_g,

if all the messages are from the DTU towards the inverter we have a new 
message id.

In this document: 
https://www.mikrocontroller.net/attachment/549922/hoymiles-datenformat-r2.txt

and also in martins excel the MID 0x83 was only shown as a response form 
the inverter towards the DTU. But now we see 0x83 also from the DTU 
towards the inverter. 0x82 seems to be completly new

[Arnaldo G. (arnaldo_g)]

My inverters are running, attached a new log from a closest place with 
more log.

This is the DTU: [2022-03-12 09:17:15.329]  40   0  90:65:23:74:01

I am running a scanner on all channels, but it´s seens losting a lot of 
package, I will leave it running for some hours and post here after!

[Marcel (Gast)]

Thanks Arnaldo,

just to clarify. In an older post you wrote, that your serial number of 
your DTU ends with 35453 ?

> DTU: 35453
> MI1500: 36590
> MI1500: 14456

But in your last post, you wrote "90:65:23:74:01". For me there are no 
similarities. Would you be so kind and give us the last 8 digits of the 
serial number from your DTU and your Hoymiles please ?

Thanks a lot for your work

Marcel

[Arnaldo G. (arnaldo_g)]

Marcel,

Sorry I made a mistake, is not that line, see below, you can see it in 
last log nrf24_4.txt file, the serial is 70535453.
[2022-03-12 09:16:58.926]  23   0  53:54:53:70:01

this is another MI.
[2022-03-12 09:17:15.329]  40   0  90:65:23:74:01

[Thomas B. (tbnobody)]

I just wrote a small parser to analyze the data from @arnaldo_g.
It's maybe easier to find some logic in the channel selection.

Unfortunatly it seems that all messages from the inverters to the DTU 
are empty.

[Marcel (Gast)]

Correct, the reason for this result is that arnaldo is using the 
scanner. This one only shows the connections between the devices. Based 
on the code it analyses only the first bytes of the protocol.

Arnaldo (@arnaldo_g) can you use the ./nrf24-sniffer.py. I'm not quite 
sure about the params.

Maybe

./nrf24-sniffer.py -a 90:65:23:74:01

or

./nrf24-sniffer.py -a 53:54:53:70:01

I think this should result in a more detailed output.

Marcel

[Arnaldo G. (arnaldo_g)]

Yes, sure I will run!

Attached is a scanner in all channells with a DWELL of 10s.

[Arnaldo G. (arnaldo_g)]

Hi all!

seens the firmware for the dongle have some hardcoded parameters, I 
leaved it running for about a hour and nothing was catch by sniffer, 
after I analysed the code and change another point to 250K, maybe it 
need some ajusts to sniff the packages.

I also changed (in radio.c / line 388) to RATE_250K recompile and 
reflashed the device, but running "./nrf24-sniffer.py -a 36:49:51:70:01" 
nothing is recorded...

    // 2Mbps data rate, enable RX, 16-bit CRC
    configure_phy(EN_CRC | CRC0 | PRIM_RX | PWR_UP, RATE_2M, 0);

If anyone is familiar with the radio and it´s parameters can look the 
code, maybe can help more!

If someone have a idea please let me know to try again....

[Martin G. (petersilie)]

Grasping at straws here, but you could try reversing the order of the 
bytes to the -a parameter:

./nrf24-sniffer.py -a 01:70:51:49:36

(The source code reverses them before passing them on to the underlying 
layer "enter_sniffer_mode()", but it appears to do no such thing when 
printing the results coming from there.)

[Martin G. (petersilie)]

Aktualisierte Nachrichtenliste

[Arnaldo G. (arnaldo_g)]

Martin G. schrieb:
> Grasping at straws here, but you could try reversing the order of the
> bytes to the -a parameter:
>
>

./nrf24-sniffer.py -a 01:70:51:49:36

>
> (The source code reverses them before passing them on to the underlying
> layer "enter_sniffer_mode()", but it appears to do no such thing when
> printing the results coming from there.)

Martin, about a hour running and nothing was logged.....

root@retropie:/home/pi/nrf-research-firmware/tools# date
Sat 12 Mar 17:09:04 -03 2022
root@retropie:/home/pi/nrf-research-firmware/tools# ./nrf24-sniffer.py 
-a 01:70:51:49:36

[Hubi (Gast)]

Hallo
um sichern zu sein, dass meine Pseudo-DTU (Arduino ProMini + nRF24L01) 
funzt, habe ich mir ein Testprogramm geschrieben, das den WR simuliert. 
FDaten kommen an, ich setzte das Bit 8 und sende an die "DTU" zurück. 
Und die kriegt das auch, zwar nicht bei jedem Senden, aber wenigstens 
kommt was an. Und ich bin sicher, dass meine Hardware funktioniert.
Aber weiterhin kommt von richtigen WR aufm Gartenhaus nix. Ich vermute 
entweder eine spezielle Einstellung der RF24-Parameter oder eine 
spezielle Sequenz von Telegrammen von DTU->WR.
Meine RF24-Parameter sind:
Kanal 3
Speed 250000 kbps
payload=27
autoAck=true
adressbreite=5
Sollte doch passen, oder?

[Herbert K. (avr-herbi)]

Hallo, eine Frage an diejenigen, bei denen es scheinbar schon ein 
bischen klappt mit dem Senden / Empfangen:
Welches nrF24 Modul nutzt Ihr ?  Es gibt ja verschiedene ?  Ich wollte 
mir eines bestellen.
Danke.
Einen schönen Sonntag wünsche ich Dir / Euch.

[Hubi (Gast)]

Meins sieht aus wie ali-001

[Thomas B. (tbnobody)]

ich habe hier ein ali-005

@Hubi: das mit der Kanalauswahl ist sehr seltsam. Weil bzgl. der Dumps 
von @arnaldo_g scheinen ja alle möglichen Kanäle involviert zu sein. 
Wann welcher ausgewählt wird ist mir noch nicht klar.

[Frank H. (fh_)]

Hallo,
Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen 
der Beiträge durch den Kopf ging:

nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are 
used.
In nrf24_4.txt we have a lot of packages with the address of the DTU and 
zero payload. Could this be ACK packages from the DTU to the WR?
When the WR answers, could it be, that it uses the address of the DTU?
However we see only data from the DTU. Maybe the usb sniffer has a 
'weak' antenna.
@arnaldo_g
Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, 
75,  83 but put the sniffer as near as possible (minimum wall in 
between) to one of the MIs?

@hoymiles-datenformat-r3.txt
Regarding the first xlsx from martin I think []=Spekulation:
0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)]
0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01
0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02]

VG
Frank

[Arnaldo G. (arnaldo_g)]

Frank H. schrieb:
> Hallo,
> Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen
> der Beiträge durch den Kopf ging:
>
> nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are
> used.
> In nrf24_4.txt we have a lot of packages with the address of the DTU and
> zero payload. Could this be ACK packages from the DTU to the WR?
> When the WR answers, could it be, that it uses the address of the DTU?
> However we see only data from the DTU. Maybe the usb sniffer has a
> 'weak' antenna.
> @arnaldo_g
> Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61,
> 75,  83 but put the sniffer as near as possible (minimum wall in
> between) to one of the MIs?
>
> @hoymiles-datenformat-r3.txt
> Regarding the first xlsx from martin I think []=Spekulation:
> 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)]
> 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01
> 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02]
>
> VG
> Frank

Hi Frank, I tried the sniffer in the same place but I can´t get 
anything, I think the code for the sniffer have something different... 
The distance for the DTU is about 3 meters and for 1 MI is about 1 
meter, for another MI 1,5meters and the others is about 4-5 meters.... 
the wall is just a thin wooden about 4-5mm.....

Yes the antenna of the sniffer is tiny, it´s a logitech unify dongle, 
but for 250k and the frequency it´s should work nice... When using the 
dongle with the logitech keyboard I can go far and it´s still 
working....

Also I have tried some changes on scripts and code of the 
nrf-research-firmware but no luck, I think the sniffer is not working, 
maybe because the CRC, payload or another radio configuration....

[Arnaldo G. (arnaldo_g)]

Hi! More one log, I think it will not help anything, but just to see the 
difference, I changed the script parameters and run it, then  I runned 
the original code.....

[Martin G. (petersilie)]

I agree with arnaldo_g, fh_, etc. There might well be some setting that 
we're missing - therefore we're not seeing the packets we expect to see.

CRC and Baud Rate settings seem fine to me.

Not sure what to do about the different channels. Until we figure out 
how the devices "hop" between channels, we will miss packets. But we 
should be able to see at least some. It would be interesting to see if 
the inverters always stay on the same channel, or if they switch 
channels...

"martin (Gast)" seems to have the most insight into how the RF side of 
things work. Maybe he has some more ideas?

Also, maybe the Logitech dongle isn't quite the same as an "NRF24L01+", 
and the nrf-research-firmware definitely has some quirks.

I bought some NRF24L01+ modules and will try to interface them to a 
RaspberryPi. This might give better results.

@arnaldo_g - do you have any NRF24L01+ modules that you could try 
instead of the Logitech dongle?

[Arnaldo G. (arnaldo_g)]

Hi Martin,

I have a Nrf24l01 module that I buyed, and put on my drawer to wait the 
results, when I found this forum.... :)

After that I found the nrf-research-firmware, and I found a Logitech 
dongle that can run it... And started with some test and put the results 
here...

This Logitech dongle model C-U0007 seens to have a NRF24L01+ IC, but I 
don´t have much time to code a new firmware and try....

[Martin G. (petersilie)]

Another thought: Could we try to "ping" the known addresses, cycling 
through "all" channels? I believe the NRF24s should answer to a "ping" 
(empty payload) all by themselves.

I should be able to try this with my NRF24s in a couple of days' time.

[martin (Gast)]

Hi Guys,
sorry for my late reply - I have a roof reconstruction going on at home, 
so little time for playing with my inverter and no panels installed at 
the moment ;-)

As I mentioned in my post 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" I got good results 
with the NRF sniffer from yveaux. Since you have dedicated addresses and 
CRC checked packages, you can filter out a lot of garbage. Downside is, 
that you can only sniff one side of the communication (per computer - so 
I have to setup a second one to sniff both sides).
As you can see in the wireshark screenshot, the packets are 
acknowledged. So ACK is on.

@Arnaldo: I would limit sniffing to the channels 3/23/40/61/75 since 
these are approved in the FCC report and I have verified them with a 
spectrum analysis.
see:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

My guess(!) about the channels is, that the information is redundant. 
That would mean, the DTU hops to every channel and transmits the same 
information - to have a chance of getting data even in wifi contaminated 
areas. So for the beginning, it should be sufficient to focus on one 
channel.
A first glance at the RF data on channel 23 instead of 3 seems to 
support my guess.

[martin (Gast)]

Hi everyone,

I started another quick test without the inverter (DTU trying to 
connect), to compare the serial data on the DTU with the RF packets 
sniffed with Wireshark.

An important part in the request by the DTU seems to be coded in the 
last 2 Bytes before the CRC8. They alter with the time stamp, but I have 
no idea what they encode. Maybe some flags?

[Lars B. (docbmuc)]

Hi,

I also join the party as I'll receive soon a HM-600 inverter. I don't 
favour cloud services and try to keep my data in-house.

Concerning the last two bytes before the CRC:
Is that lower nibble of the first byte always "B"?

To me it seems unlikely to put changing flags in an initial connect 
request which contains the same data besides the changing time stamp.

IMHO it could be

1. some kind of pseudo random number (drawn from an internal µC counter) 
and used as a packet number. In this case the answer of the inverter 
should include somewhere the same number.

or

2. some kind of authentication, e.g. a ciphered time value using a 
shared secret between the DTU and the inverter.

just an idea... ;-)

[Martin G. (petersilie)]

or

3. Yet another CRC/"checksum"? (It changes whenever the content 
changes.) In that case: how is it calculated? Since it doesn't change 
when the source address gets swapped out by the µC, if it is some kind 
of checksum, it is likely only influenced by the bytes following the 
address information.


Have we ever seen a reply from the inverter in response to a 0x80 
message? That might give us some more clues.

[Martin G. (petersilie)]

Success! Thanks, @docbmuc and @martin (Gast)!

I cycled through some predefined CRC functions. Turns out our mystery 
bytes are the same type of CRC as used by the "Modbus" protocol, see 
picture. Works for all the examples in "martin" (Gast)'s 
SerialData_RFSniff.xlsx, and for the one I originally documented in 
hoymiles-datenformat-r3.txt.

New revision of said document attached.

[Heinz R. (heijz)]

Hallo Martin,

das heisst Du hast es jetzt geknackt? :-)

Bin gespannt, hier wartet auch nich ein HM-1200
DTu werde ich mir keine kaufen - eher kommt der ganze Hoymiles-Schrott 
weg...

[Thomas B. (tbnobody)]

Amazing!

Based on @petersilie info I adjusted the test program. I cannot test it 
at the moment (lack of sun) but the crc calculation should work as 
expected.

Maybe it helps someone. (used libraries are also documented in the 
platformio.ini file)

I tested the source with an ESP32

[Thomas B. (tbnobody)]

@petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um 
einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter 
oben [1]. Dort ist ein ESP-12F abgebildet.

[1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Hubi (Gast)]

Hallo Thomas
das setzen des CRC16-Polynom in Zeile 66 kann  aber nicht ganz stimmen, 
das sind mehr als 16 bit. Und wenn ich nur 0x8005 und bei online-CRC16M 
Rechnern eingebe kriege ich nicht das gewünschte Ergebnis. Vllt bin ich 
auch etwas irritiert.
Ich bin ganz g... auf deine Klarstellung und dann werde ich morgen 
wieder meinen ProMini bruzzeln bis er durchbrennt oder endlich eine 
Antwort kommt.

[Matthias B. (matthias882)]

Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut 
Spitze wie sich das hier entwickelt. Auf meinem Vordach sonnt sich ein 
HM-600 und wartet darauf seine Daten preiszugeben. Ein NRF24-Modul ist 
im Zulauf, also bin ich hier auch bald bereit zum Mitspielen 😉

Mit freundlichen Grüßen
Matthias

[Thomas B. (tbnobody)]

Hallo Hubi,

jetzt hast du mich etwas blank erwischt :)

Also in Python klappt es so:

import crcmod
f = crcmod.mkCrcFun(0x18005, initCrc=0xFFFF, xorOut=0x0000)
payload = bytes((0x0B,0x00,0x62,0x09,0x04,0x94,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00))
print(hex(f(payload)))

Das Ergebnis ist wie erwartet: 0x229
(Wichtig ist hier, dass die kompletten 14 byte angegeben werden)

Und auch hier wenn man es im Online Calculator eingibt erscheint das 
korrekte Ergebnis: 
https://crccalc.com/?crc=0B00620904940000000000000000&method=CRC-16/MODBUS&datatype=hex&outtype=0

Die 0x18005 habe ich aus der Doku von crcmod: 
http://crcmod.sourceforge.net/crcmod.predefined.html

[Hubi (Gast)]

Sorry Thomas, mit 0x8005 passt es doch

[martin (Gast)]

Hallo Martin,

perfekt - damit wissen wir jetzt das komplette Anfrage-Paket.
Ich habe auch nochmal ein paar Datenpakete überprüft, es passt auch für 
das  Paket ausgehend von der DTU mit 0x11 anstatt 0x0B im ersten Byte 
(nach den Adressen). In den Antworten vom WR habe ich die Modbus-CRC 
bisher aber nicht entdecken können.

Für diejenigen, die ihre CRC-Berechnungsfunktion oder weitere Pakete 
prüfen wollen, siehe Einstellungen für HxD im Screenshot.

Thomas B. schrieb:
> Maybe it helps someone. (used libraries are also documented in the
> platformio.ini file)
> I tested the source with an ESP32

@Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom 
Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 
eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. 
War gestern Abend aber auch nicht sicher, ob die Speisung mit Netzteil 
funktioniert hat - zumindest hatte der WR mal grün geblinkt...

Matthias B. schrieb:
> Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut
> Spitze wie sich das hier entwickelt.

@Matthias, ja ich bin auch begeistert, wie das hier Fahrt aufgenommen 
hat ;-)

[Hubi (Gast)]

Habe mit meinem Testprogramm (mit CRC16) bisher auch keinen Erfolg, es 
kommt einfach keine Antwort.
Ich vermute, da fehlt die richtige Initialsequenz.
Ein Mitschnitt der Kommunikation vom Einschalten der DTU an wäre 
bestimmt sehr hilfreich.

[Marcel (Gast)]

Ich habe mir jetzt auch mal diese Logitech Dongles von Arnold geholt. 
Ich bin mir irgendwie nicht sicher, was die NRF library raus sendet. Ich 
hab das Gefühl, die fügt noch was hinzu. Ich teste dann mal mit meinem 
ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die 
einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht 
vorstellen, das es eine genaue Schrittfolge geben soll.

Marcel

[Martin G. (petersilie)]

Thomas B. schrieb:
> @petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um
> einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter
> oben [1]. Dort ist ein ESP-12F abgebildet.
>
> [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Du hast natürlich Recht, danke. Ich werde das anpassen.

[Martin G. (petersilie)]

Marcel schrieb:
> [...]
> Ich teste dann mal mit meinem
> ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die
> einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht
> vorstellen, das es eine genaue Schrittfolge geben soll.

Dass es eine genau einzuhaltende Reihenfolge geben soll, scheint mir 
auch unwahrscheinlich. Ich denke aber, der WR wird (für längere 
Zeit/nur) auf einem der verfügbaren Kanäle zuhören. Und vielleicht nur 
jede Stunde oder so den Kanal wechseln, wenn er in der Zeit nichts 
sinnvolles empfangen hat.

Die DTU, bzw. unsere Version davon, muss also zuerst mal auf allen 
Kanälen ein "PING" schicken, um zu sehen, ob der WR vielleicht zufällig 
gerade auf diesem Kanal zuhört. Erst dann sind weitere Anfragen 
überhaupt sinnvoll. Die DTU scheint das nach den Logs hier im Thread ja 
auch so in der Art zu machen.

Ich meine, im Datenblatt zum NRF24 gelesen zu haben, dass ein 
"0-Payload"-Paket wie ein "PING" funktioniert, d.h. die Gegenstelle wird 
brav mit "ACK" antworten. Vielleicht könnten wir als ersten Schritt 
probieren, solch einen "PING" auf die jeweils bekannte(n) 
Seriennummer(n) auf allen Kanälen zu programmieren?

Danach stellt sich die Frage, welche Anfrage wir dann schicken sollten. 
Die mit der Uhrzeit ist eventuell nicht die hilfreichste - welche 
Antwort erwarten wir denn darauf?

Wie wäre es mit der "Nachricht 0x81: DTU an WR: "Anfrage DC-Daten""? Da 
würde ich dann die DC-Daten als Antwort erwarten.

[Martin G. (petersilie)]

r5

[Thomas B. (tbnobody)]

Einfach anfangen klingt sinnvoll :)

Ich habe auch gesehen es gibt einen Dynamic Payload Length Modus. Im 
Excel von martin haben wir ja verschieden lange Pakete.

Das Payload control field in [1] war 0x0d8 = 11011000
Laut Kapitel 7.3.3.1 in [2] ist wird die Payload Length (6 bit lang, 
siehe Kapitel 7.3.3) nur verwendet wenn die Dynamic Payload Length 
function aktiv ist.

Vielleicht ist das auch noch ein Punkt der zum Erfolg fehlt...

Hätte an meinem Code das hier geändert:

    //radio.setPayloadSize(27);
    radio.enableDynamicPayloads();

[1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[2] 
https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf

[Herbert K. (avr-herbi)]

Hallo,
was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 
Frequenzen abgeklappert werden.
"Channel List 2403, 2423, 2440, 2461, 2475MHz"
Nur einen Channel zu testen bringt doch nix bzw. wäre Zufall, das der WR 
genau da horcht.
Ich kenne mich mit "C" leider nicht so aus. Ich vermisse da jedenfalls 
eine Schleife die alle 5 Frequenzen abcheckt.
@Petersilie: Vielleicht mal die Frequenzen in r6 mit aufnehmen :-)
Viele Grüße an Alle, die hier mitarbeiten.

[Thomas B. (tbnobody)]

Herbert K. schrieb:
> was ich bisher in dem einen Sourcecode vermisse ist, das alle 5
> Frequenzen abgeklappert werden.

Siehe Anhang... hatte das bei mir schonmal implementiert aber aktuell 
hats keine Sonne :-(

[Hubi (Gast)]

Nur zur Info:
bei irgendwelchen neuen Erkenntnissen über die Kommunikation klappere 
ich mit meinem Testprogramm alle bekannten Kanäle ab. Bin mal gespannt 
wie oft ich noch bruzzeln kann, bis der uC die Krätsche macht.

[Marcel (Gast)]

Hallo,

Marcel schrieb:
> int channels[5] = {3, 23, 40, 61, 75};
> 35

mit diesen Kanälen hatte ich damals immer getestet und habe diese dann 
irgendwann mal auf

int channels[9] = {1, 3, 6, 9, 11, 23, 40, 61, 75};

angepasst. Alle Informationen, die hier im Forum herausgefunden wurden, 
habe ich in meinem Script angepasst und immer auf diesen Kanälen 
getestet.

Leider bisher noch kein Erfolg in Form von einem ACK oder sogar 
Statistiken vom WR.

Marcel

[Thomas B. (tbnobody)]

Marcel schrieb:
> Alle Informationen, die hier im Forum herausgefunden wurden,
> habe ich in meinem Script angepasst und immer auf diesen Kanälen
> getestet.

Hast du die dynamicPayload auch schon getestet oder erst alle Dinge die 
vor heute Abend hier standen? Ich halte das aktuell für 
vielversprechend.

[Hubi (Gast)]

Bin zwar nicht angesprochen, aber DynamicPayload und Payload 27 (siehe 
Erkenntnisse irgendwo oben) probiere ich ständig abwechsenld aus.

[Thomas B. (tbnobody)]

@martin (Gast),

hattest du schonmal versucht mit einem NRF24 den WR zu pollen? Falls die 
DTU im initialen Setup $Dinge im WR einstellt damit dieser antwortet, 
müsste das ja bei dir passiert sein und er sollte dann auch einem 
"eigenen" NRF24 antworten?

[martin (Gast)]

martin schrieb:
> @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom
> Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11
> eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg.

Hallo Thomas. Ja, ich hatte es getestet - leider ohne Erfolg. Ich 
arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und 
NRF24 - sobald es etwas neues gibt, melde ich mich.

[martin (Gast)]

martin schrieb:
> Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und
> NRF24

Also meine bisherigen Versuche mit eurer als auch eigener Software sind 
fehlgeschlagen - obwohl 2 NRFs miteinander Pingpong spielen (Funkmodul 
tut also). Aber was ich sagen kann, der Inverter lässt sich mit einem 
24V Netzteil (nominal 2,5 A/60W) speisen und funktioniert dann auch. Das 
ermöglicht mir zumindest auch mal Abends zu testen.

Pascal A. schrieb:
> hast du noch mehr Daten zu deinem Wechselrichter?
> Vielleicht sind es Daten zu Einstellungen, Firmware, ..

@Pascal, hier noch die Daten, die ich dir schuldig geblieben bin -> 
Siehe Screenshot.

[golf (Gast)]

kann es vielleicht sein, daß die eigenen NRF24L01 1 Mbps statt 256kbps 
nutzen. Meiner jedenfalls will trotz Programmierung nach den 
SDR-Aufnahmen keine 256kB senden. Liegt aber evtl auch an mir ?

[Herbert K. (avr-herbi)]

NRF24L01 = 1 MHz u 2 MHz
NRF24L01+ = 256 K u. 1 u 2 MHz
(ohne Gewähr)

[golf (Gast)]

Herbert K. schrieb:
> NRF24L01 = 1 MHz u 2 MHz
> NRF24L01+ = 256 K u. 1 u 2 MHz

daran liegts dann bei mir bzw. meinen Modulen. Ich werd mir 24LE01 
bestellen, wie sie verwendet werden.

[Lukas M. (miltechniks)]

Mit Interesse lese ich hier schon seit ein paar Tagen mit. Mein WR (ein 
HM600) kommt hoffentlich im April, die nrf24 Module sind schon da.

Laut Datenblättern sieht es tatsächlich so aus, dass der nrf24L01+ die 
250kbit/s kann:
https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf#page24

Der nrf24L01 (ohne +) kann nur bis 1Mbit/s runter:
https://www.mouser.com/datasheet/2/297/nRF24L01_Product_Specification_v2_0-9199.pdf

Ich bin gespannt, wie es weiter geht und hoffe dass ich demnächst auch 
ordentlich mitmischen und programmieren kann sobald der WR da ist

[Marcel (Gast)]

Hallo,


ich habe mir mal zwei NRFs aufgebaut und der eine sendet die Daten so, 
wie der WR sie eigentlich empfangen soll und wie es hier im Forum 
gepostet wurde.

Den zweiten NRF habe ich mit einer Scanner logig beschrieben 
(https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183). 
Dieser Scanner findet auch ein paar valide Nachrichten in meinem Umfeld 
- aber leider nicht die, die ich mit dem anderen NRF sende.

Dazu habe ich im Scanner mal nur den channel = 3 (und im while loop das 
channel++ auskommentiert) eingestellt und der 2. NRF sendet auch aller 
140ms auf diesem Kanal.

Sind wir denn sicher, das die CRC Berechnung korrekt ist (ich bin leider 
kein Experte in Bit Operatoren und Bit Verschiebung).

Zeile, die prüft ob die CRC die empfangen wurde auch einer Berechnung 
stand hält befindet sich hier: 
https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183

Marcel

[Daniel E. (Gast)]

Ein anderer Ansatz: man könnte versuchen, die Firmware aus dem nRF24LE1 
auszulesen. Die SPI-Schnittstelle dafür ist auf der DTU-Platine 
beschriftet. Sollte das Flash nicht lesegeschützt sein, könnte man sich 
die Initialisierung/Kommunikation mit dem RF-Kram via Disassembler 
ansehen.

Zum Auslesen gibt es verschiedene Möglichkeiten:

FTDI FT232R:
https://github.com/jdelfes/nrf24le1_flasher

nrf24le1_flasher --read-flash readout.bin

RaspberryPi:
https://github.com/derekstavis/nrf24le1-libbcm2835

nrf24le1 show
nrf24le1 read firmware readout.bin

Arduino:
https://github.com/DeanCording/nRF24LE1_Programmer/blob/master/Read_Mainpage/Read_Mainpage.ino

[Martin G. (petersilie)]

Mein Wechselrichter ist angekommen!

Leider bisher ohne DTU ("Lieferschwierigkeiten" - große Hoffnungen habe 
ich nicht).

Mein Testsetup besteht aus 2 RaspberryPis mit jeweils einem NRF24L01+ 
Modul.

Auf einem Pi läuft der "pretender", der sich wie ein WR verhalten soll.

Auf dem anderen Pi läuft der "discoverer", der nacheinander eine 
Testnachricht an alle einprogrammierten Seriennummern auf allen Kanälen 
sendet, und jeweils anzeigt, falls er ein ACK zurückbekommt.

Der "discoverer" findet auch brav den "pretender", auch wenn ich diesen 
zwischendurch auf einen anderen Kanal wechsle.

ABER mein Wechselrichter antwortet nicht.

Das führt mich zu folgender Schlussfolgerung:

Der Auto-ACK-Modus ist Wechselrichter-seitig vermutlich doch nicht 
aktiv.

Hat jemand auf der Funkschnittstelle schon mal wirkliche ACK Pakete 
gesehen? Das "nACK" Bit im "PCF" sagt ja nur, ob der RF-Transceiver das 
Paket bestätigen soll, sofern Auto-Ack eingeschaltet ist. Wenn das 
nicht der Fall ist, wird er auch keine Bestätigung senden, egal welchen 
Zustand das nACK Bit hat.

Ich habe mal ein Github-Repo für die Hoymiles-Kommunikation angefangen. 
Vielleicht können wir das gemeinsam erweitern?

Mein Quellcode liegt hier: https://github.com/grindylow/ahoy


Ein zielführender nächster Schritt wäre, zu versuchen, einen 'pretender' 
als weiteren Wechselrichter an eine DTU anzulernen.

Dann sollten wir sehen, welche Pakete die DTU an die entsprechende 
Seriennummer schickt, und können von dort Stück für Stück die weitere 
Kommunikation beobachten. Hat jemand die Möglichkeit, das 
auszuprobieren?

[Martin G. (petersilie)]

@arnaldo_g, do you think you might be able to program your receiver to 
respond to the same address as one of your inverters? That way it should 
receive the queries from the DTU directly, without us having to guess 
what the sniffer tool may or may not be doing to the received packets.

Also, at night, the inverters will stop replying, but traffic to the 
'pretend' receiver should continue.

[martin (Gast)]

Hallo zusammen,

ich habe hier nochmal ein paar Captures zusammengestellt, vielleicht 
hilft es dem Projekt ja weiter, wenn da noch jemand anderes draufschaut.

Es sind .sal (Saleae Logic) Captures der seriellen Schnittstelle in der 
DTU.
Und .pcapng (Wireshark captures) mit dem yveaux NRF24 sniffer, jeweils 
auf den bekannten Adressen. Interessanterweise antwortete der Inverter 
nur auf einem Kanal von den 3 betrachteten.
Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung 
stellen, diese können im Universal Radio Hacker geöffnet werden. Sind 
aber mehrere Hundert MB groß, deshalb nur auf Anfrage.

Ich vermute, dass die DTU alle Kanäle durchtestet und wenn der Inverter 
antwortet, diesen Kanal dann weiterhin verwendet. Kann das aber im 
Moment leider nicht verifizieren, da der Java Spectrum Analyzer seit dem 
Firmwareupdate des HackRF nicht mehr tut...

Schönen Sonntag noch.

[emhopa (Gast)]

Hallo in die Runde,

ich möchte eure interessante „Forschung“ nicht stören, habe aber 
vielleicht einen hilfreichen Hinweis:
Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese 
zuallererst bei der Basis registrieren musste, bevor eine Kommunikation 
möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn 
man eine andere DTU verwenden wollte, musste man den WR zuerst 
de-registrieren und dann neu registrieren. Die Registrierung erfolgte 
mit der Master-ID, der Seriennummer der DTU.

Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ 
erfolgen.

[B. G. (golf2010)]

martin schrieb:
> Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung
> stellen, diese können im Universal Radio Hacker geöffnet werden. Sind
> aber mehrere Hundert MB groß, deshalb nur auf Anfrage.

Hallo Martin,
solche RF-Aufnahmen, z.b. als IQ-File, wären sicher am besten. Da würden 
ganz kurze Ausschnitte davon mit den Sendungen ja voll ausreichen. Die 
könnte man dann selbst demodulieren, falls nötig.

Als Anhang eine demodulierte Sendung von meinen Versuchen. Ich hab da 
momentan kein 16-bit CRC dran. Ist dieser immer vorhanden beim Senden ?

( da die demodulierte Sendung nicht mittig liegt, hab ich eine relativ 
große Frequenzabweichung. Da muß ich den Quarz am NRF noch besser 
abgleichen)

Gruß
golf

[Oliver F. (of22)]

Hallo zusammen.

Ich habe auch zwei Hoymiles Modulwechselrichter und eine DTU Lite.
Ich habe mir nun, inspiriert durch die bisherigen Inhalte, zwei 
NRF24L01+ Module besorgt und diese mit einem Arduino nano gekoppelt. Ein 
Modul bekommt als Adresse die Adresse der DTU, das andere die Adresse 
eines der Wechselrichter. Damit schneide ich den Datenverkehr zwischen 
DTU und Wechselrichter mit. Ich nutze dazu den yveaux NRF24 sniffer in 
abgewandelter Form. Zunächst ist dabei nur ein Daten Durcheinander 
herausgekommen.

Wenn man allerdings den gelesenen Nutzdaten Stream jeweils um ein Bit 
nach links verschiebt, sieht das Ganze ein wenig besser aus.

Meine DTU hat die Adresse 0x50908172.
Die Wechselrichter haben diese Adressen: WR1 0x19461073. WR2 0x39441073.

Am Beispiel eines empfangenen Rohdatenstreams wird aus:

01-6C-4A-B9-88-23-0C-B9-88-23-0C-80-80-00-80-AC-00-AE-02-55-00-AB-00-AA-82-46-00-00-5A-17

Beim Schieben des ganzen Streams um ein Bit nach links diese Bytefolge:

02-D8-95-*73-10-46-19-73-10-46-19*-01-00-01-01-58-01-5C-04-AA-01-56-01-55-04-8C-00-00-B4-2E

Ab Byte 3 wird darin zweimal hintereinander die Adresse eines der 
Wechselrichter gesendet. Allerdings wird die Wertigkeit gedreht, aus 
0x19461073 wird 73-10-46-19.

Wende ich dies auf die empfangenen Streams an und formatiere es ein 
wenig, so tauchen an den Stellen im Stream nur die bekannten Bytefolgen 
der Adressen auf, allerdings in umgekehrter Reihenfolge. Siehe Anhang.

Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen 
Seriennummern bestätigen?

[Martin G. (petersilie)]

Super! Tolle Mitschnitte und Erkenntnisse!

Das mit dem Verschieben um 1 Bit macht Sinn, da das "Enhanced 
Shockburst"-Protokoll seinen Vorgänger, das "Shockburst"-Protokoll, um 
ein 9-bit "Packet Control Field" erweitert. Alles nach diesem "PCF" 
erscheint dann um ein Bit verschoben.

So wie ich das verstehe, arbeitet der "Sniffer" im "normalen" Shockburst 
Modus, wo man dem Chip wohl beibringen kann, auch Pakete durchzuleiten, 
die nicht CRC-geprüft sind. Eventuell gehen allerdings dafür die letzten 
Bytes verloren, das würde erklären, wenn Dir am Ende die 
protokoll-eigene CRC fehlt. Shockburst ist wohl auf 30 Bytes beschränkt, 
und da gehen die 5 Adressbytes noch weg, also können 27 Byte lange 
Nachrichten inkl. CRC evtl. nicht mehr ganz gelesen werden. Das ist aber 
kein Problem, denn wenn wir so weit sind, können wir die Nachrichten ja 
auch im echten "Enhanced Shockburst" Modus mitlesen.

Zu Deiner Nachricht: Das passt super. Mit den verschobenen Bits ergibt 
sich nämlich direkt die Nachricht [0x01: WR an DTU: "Aktuelle DC 
Daten"], siehe hoymiles-datenformat-r5.txt.

02-D8-95-*73-10-46-19-73-10-46-19*- [01-00-01-] 
        01-58- 01-5C- 04-AA- 
        01-56- 01-55- 04-8C-    00-00-   B4-  2E xx

Dein WR Seriennummer xxxx73104619 sieht
 * Auf Kanal 1: 34.4 V; 3.48 A; 119.4 W
 * Auf Kanal 2: 34.2 V; 3.41 A; 116.4 W

Die Bedeutung der anfänglichen [01-00-01] kennen wir noch nicht genau. 
Die erste 01 ist vermutlich ein Befehlscode.

[martin (Gast)]

Oliver F. schrieb:
> Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen
> Seriennummern bestätigen?

Hallo Oliver,
ja, das sieht vertraut aus. Ich erkenne darin die bereits analysierte 
Paketstruktur wieder.
Man sieht die Anfrage von der DTU mit der Kennung 0x15, danach das 
übliche 0x80 0x0B, die Unix-Zeit 0x62...

Die Antwort vom Inverter beginnt mit 0x95 und enthält die Daten wie 
Martin G. oben schon aufgeschlüsselt hat.

Was mir hier und auch in meinen Daten aufgefallen ist: In den 
Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer 
mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun 
haben, der für die Antwort verwendet werden soll?

Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden, 
wenn die DTU nach dem Inverter "sucht". Demnächst werde ich noch 
aufzeichnen was passiert, wenn der Inverter dann antwortet.

Anbei noch wie von golf angemerkt eine kurze Sequenz auf Kanal 40 als IQ 
File zur Analyse mit dem Radio Hacker.

[B. G. (golf2010)]

vielen Dank Martin für deine Aufnahmen.
Es reicht eigentlich eine Realwandlung des IQ-Files, um die Bits 
abzulesen. Auch der Momentanfrequenzverlauf ist sehr sauber.

[martin (Gast)]

B. G. schrieb:
> Auch der Momentanfrequenzverlauf ist sehr sauber.

Hallo golf,
mit welchem Programm hast du die Auswertung auf dem zweiten Bild 
gemacht?
Die Bits sieht man hier viel deutlicher, als bei der Auswertung mit dem 
Universal Radio Hacker (URH).

Durch die Verschiebung der Daten um 1 Bit wegen des 9-Bit Packet Control 
Fields ist auch die Hex-Ausgabe im URH nicht wirklich hilfreich.
Ich hatte mir deshalb mit folgendem Excel-Template beholfen - ist 
natürlich Quick & Dirty, da die Bits nicht immer 100% passen, aber mir 
hat es definitv weitergeholfen, den Signalaufbau besser zu verstehen.

[B. G. (golf2010)]

martin schrieb:
> mit welchem Programm hast du die Auswertung auf dem zweiten Bild
> gemacht?

Hallo Martin,
das ist alles von mir mal in Delphi selbst geschrieben im Programm für 
meinen
Eigenbau-SDR. Ich hab auch einen Modulator gebaut, damit hab ich deine 
Aufnahme einfach wieder mit dem SDR empfangen können.
Leider bringen Dir die Programme nichts ohne die Hardware dazu.
Ich hab die Aufnahme erst auf 16 bit gebracht und als Wave gespeichert, 
da mein SDR nur 16 bits verarbeitet.

Das Programm für die Complex to Realwandlung könnte ich evtl versuchen 
anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise 
demodulieren.

[Thomas B. (tbnobody)]

emhopa schrieb:
> Hallo in die Runde,
>
> ich möchte eure interessante „Forschung“ nicht stören, habe aber
> vielleicht einen hilfreichen Hinweis:
> Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese
> zuallererst bei der Basis registrieren musste, bevor eine Kommunikation
> möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn
> man eine andere DTU verwenden wollte, musste man den WR zuerst
> de-registrieren und dann neu registrieren. Die Registrierung erfolgte
> mit der Master-ID, der Seriennummer der DTU.
>
> Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“
> erfolgen.

So etwas dachte ich Anfangs auch. Ich mag mich täuschen, aber es sollte 
doch zumindest bei @martin (Gast) funktionieren, da bei ihm ja die 
Seriennummer der DTU schon im WR registriert sein müsste.

[Der Kommissar (Gast)]

Liest sich wie ein Krimi.
Ich drücke Euch die Daumen.
Tolle Teamarbeit.

[Mag C. (magcode)]

Finde ich auch! Ich drücke die Daumen.
Mein DTU-loser Hoy HM-400 würde sich sehr gerne mit einem billigen 
Nachbau einlassen!

[B. G. (golf2010)]

B. G. schrieb:
> Das Programm für die Complex to Realwandlung könnte ich evtl versuchen
> anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise
> demodulieren.

Ich hab mal eine 1.Version meines Complex2Real Wandlers mit opt. 
Demodulation versucht, die auch die HackRF Files bearbeiten kann 
(.complex16s). Ich selbst habe keinen HackRF, nur meine Eigenbauten.

Leider machen die aktuellen Delphi-Compiler auch aus einem kleinen 
Programm gleich Megabytes.

Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten 
Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von 
martin.

Die Ausgabe des Programms ist immer ein Wavefile.

[martin (Gast)]

B. G. schrieb:
> Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten
> Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von
> martin.

Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit 
deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner 
Analyse-Excel.

[B. G. (golf2010)]

gut daß es soweit funktioniert.

bei den bei mir vorliegenden Hf-Aufnahmen sind nur Blöcke vom Inverter. 
sendet der DTU denn auf einer anderen Frequenz ?
gibts HF-Aufnahmen oder demodulierte Sendungen vom NRF24 des DTU, die 
wären interessant ?

[martin (Gast)]

Hallo golf,

anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. 
Die zugehörigen seriellen Pakete und Wireshark Captures hatte ich 
bereits oben angehängt jeweils unter "Session 1".

Wer wann auf welcher Frequenz sendet scheint momentan noch eines der 
größten Rätsel zu sein. Bei meinem Test am Sonntag spielte sich das 
meiste offenbar auf Kanal 40 ab.

emhopa schrieb:
> Wenn
> man eine andere DTU verwenden wollte, musste man den WR zuerst
> de-registrieren und dann neu registrieren. Die Registrierung erfolgte
> mit der Master-ID, der Seriennummer der DTU.

Ja, das kann schon sein - aber bei mir sind die beiden Teilnehmer 
bereits registriert. Also sollte doch theoretisch irgendwas durchkommen?

[Thomas B. (tbnobody)]

martin schrieb:
> B. G. schrieb:
>> Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten
>> Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von
>> martin.
>
> Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit
> deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner
> Analyse-Excel.

Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen 
Auswertungen war das doch immer 0x01?

[martin (Gast)]

Thomas B. schrieb:
> Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen
> Auswertungen war das doch immer 0x01?

Hallo Thomas,
ja ist mir auch aufgefallen. Ebenso bei Olivers Daten:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

In den Wireshark Captures allerdings nicht, da ist Addr[0] = 0x01.

[B. G. (golf2010)]

martin schrieb:
> anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren.

was mir aufgefallen ist. Da ist im Frequenzbereich noch ein 2 Inverter 
aktiv. Wenn ich die Samplerate mit 20 Mhz richtig interpretiert habe, 
dann sendet der 3 Mhz tiefer. Jpg ist Teil der auf Real gewandelten 
Aufnahme.

sowas wie Start, $32,88,81,72,01, 011011000, 
$95,72,22,02,00,72,22,02,00,
 $01,00,01,00,E4,01,64,03,2D,00,02,00,02,00,00,00,00,3A,33,41..
wenn ich mich nicht verschaut hab.

Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich 
darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ?

[martin (Gast)]

B. G. schrieb:
> Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich
> darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ?

Also die Pakete werden tatsächlich ein paar mal im Block so gesendet. 
Das ist vermutlich das automatische Retry, die Pause zwischen den 
Paketen beträgt ca. 1 ms.

3 MHz tiefer wäre dann Kanal 20? Ist das tatsächlich ein Signal oder 
kann das ein Fehler von meiner SDR-Messung sein?
Das wäre natürlich ein wichtiger Hinweis, wenn der Inverter gar nicht 
auf den gleichen Kanälen antwortet wie die DTU...

[B. G. (golf2010)]

martin schrieb:
> kann das ein Fehler von meiner SDR-Messung sein?

da der 2. NRF-Sender gleichzeitig (etwas verzögerter Start) mit auf der 
Aufnahme ist muß das so stimmen, auch die Frequenzen. Vorausgesetzt daß 
meine Annahme der Samplerate mit 20 Mhz stimmt.

(gewandelte Realfiles haben bei meinem Programm dann immer doppelte 
Samplerate, da aus dem IQ-Stereo File ein Monofile wird).

Aber ich hab das wohl falsch beschrieben. Es dürfte wohl so sein, daß 
auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz 
tiefer (2420 Mhz) der Inverter antwortet.

Das Verhalten läßt sich bestimmt mit neuen Aufnahmen prüfen. Ob die 
Abweichnung der beiden Sendefrequenzen immer gleich bleibt, muß man 
sehen.

(Ich weiss allerdings nicht, ob der HackRF irgendwas gemischt hat in 
diesen Bereich, da ich den nicht kenne, glaub das aber eher nicht).

[Daniel E. (Gast)]

B. G. schrieb:
> Es dürfte wohl so sein, daß
> auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz
> tiefer (2420 Mhz) der Inverter antwortet.

Im Universal Radio Hacker (UHR) sieht es für mich so aus, als ob auf der 
Spektrummitte zwei Sender unterwegs wären. Einer mit stärkerem Signal 
(DTU, weil näher am HackRF?) und ein schwächerer (Inverter?).

[B. G. (golf2010)]

Hallo Daniel,
das stimmt schon. Ich weiss halt nur nicht, ob das alles 
Aufnahmeschnipsel sind von mehreren Aufnahmen oder ob das alles am Stück 
auf der 2423 Mhz so statt gefunden hat.
Das sind ja immmer nur kleine Teilstücke.
Das kann nur Martin beantworten.
Da wäre evtl so ein Bild eines Sonogramms einer Aufnahme aussgefähiger 
ohne ausgeschnittene Stellen.

[B. G. (golf2010)]

Da wäre z.b. ein Sonagrammbild des ganzen Ablaufs ( der Aufnahme ) evtl 
aussagefähiger ohne die Aussetzer.

Oder nimmt der HackRF squelchgesteuert auf oder sowas ?
Ich lass bei mir immer die Aufnahmen durchlaufen (geht theoretisch bis 
die platte voll ist) ohne Sampleverluste. Hab hier nur keine 
DTU-Signale.


Nachtrag: doppelt gesendet, das ist was schief gelaufen bei mir

[Martin G. (petersilie)]

@martin (Gast) - könntest Du vielleicht die großen Originalcaptures bei 
einem Filesharing-Dienst hochladen?
Wetransfer kann zum Beispiel kostenlos bis 2 GB. 
https://filetransfer.io/ wohl bis zu 6 GB.

[martin (Gast)]

Hallo Martin, golf und Daniel,

leider war mein Studienschwerpunkt Automatisierungstechnik, deshalb bin 
ich bei den HF-Themen nicht ganz so fit - was heißt Squelch? ;-)

Anbei die 3 Mitschnitte bei 3, 23 und 40 MHz als komplette Files 
(zeitgleich aufgenommen wie die Logic und Wireshark Captures).
https://filetransfer.io/data-package/1Z2bKt05#link

Samplerate und Bandbreite je 20M (samples/s bzw. Hz).
In der RF-Aufnahme ist viel Mist dazwischen, weil Inverter und DTU ja 
offensichtlich immer zwischen den Kanälen hin und her wechseln und halt 
unvermeidlich WLAN oder sonst was in der Gegend rumfunkt.

Kann das "Doppelbild" daher kommen, dass ich gleichzeitig zwei 
Arduino/NRF24 Sniffer mitlaufen habe lassen? Theoretisch müssten diese 
doch rein passiv zuhören, oder?

[martin (Gast)]

Hier zum besseren Verständnis noch ein Bild, wie bzw. was ich gemessen 
hatte mit allen Teilnehmern.

3 Versuche auf den jeweiligen Frequenzen (2403, 2423 und 2440 MHz).

[B. G. (golf2010)]

hallo martin,
squelchgesteuerte Aufnahmen nehmen nur auf, wenn ein bestimmter 
Empfangspegel überschritten wird.
Aber bei dem HackRF kann das Verhalten auch durch die 8-bit bedingt 
sein, das sind jedenfalls für mich teils recht ungewöhliche Aufnahmen. 
Es gibt NRFs mit teils sehr unterschiedlichen Pegeln, dann bricht die 
Aufnahme teils abrupt ab. Das sind Aussetzer, weil der PC mit der 
Datenrate überfordert ist. Die 40 MB/sec sind halt ziemlich das Maximum 
für USB2, was geht.
Evtl zur Sicherheit mal bei weiteren Aufnahmne die Sniffer-NRFs aus 
lassen.
Bei kurzer Durchsicht gab es mehrere Stellen mit verschiedenen 
Frequenzlagen.
bei der 2403 wurde teilweise fast auf der gleichen Frequenz gesendet. 
Dann sieht man scheinbar mehr als 2 Umtastfrequenzen.
Siehe Bilder

bei dem HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG sind wohl auch 2 NRFs 
fast auf der gleichen Frequenz. Scheinbar auch mehr als 2 
Umtastfrequenzen. Muß näher untersucht werden

[B. G. (golf2010)]

die unterchiedlichen Pegel der einzelnen NRFs verwundern etwas.

[Daniel E. (Gast)]

Beim Überfliegen der Aufnahmen mit "inspectrum" (zum Öffnen: 
*.complex16s in *.cs8 umbenennen) ist mir angehängter Abschnitt 
aufgefallen. Zwei verschiedene Sender? Ein Paket mit Länge 27 und 
cmd=0x95 (-> Inverterdaten) und das andere ein 0-Byte-Paket - ist das 
ein ACK? Vielleicht vom Sniffer-NRF?

[B. G. (golf2010)]

Ich meine auch, daß da diese Sniffer vielleicht mitmischen.
Anbei eine grobe Darstellung der Blöcke auf den Frequenzen mit diversen 
Pegeln. Ob die Blöcke von DTU/INV oder teilweise von den Sniffern sind ?
Bei den beschriebenen Blöcken mit mehr als 2 Frequenzen scheint der 
Sender irgendwie instabil, sieht eher nicht nach 2 NRFs aus.

Vielleicht sollten wir auf eine neue Aufnahme warten ohne die 
Sniffer-NRFs.

[Herbert K. (avr-herbi)]

Hallo,
leider habe ich keine DTU um mitzumischen.
Warum versteift Ihr Euch so auf den HF Teil ?
Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation 
zwischen dem GD... und dem nRF ? Einen Logic Analyzer da dran, der 
gleich die Kommunikation dort decodiert ?
Mann müsste vielleicht mal alles in den Werkszustand versetzen.
Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA 
loslaufen lassen.
Wer weiss, ob die ganzen Register vom nRF überhaupt schon zu dem passen, 
was hier durch obige Programme und LIBs gemacht wird ?  Vielleicht ist 
es nur 1 Bit in irgendeinem Register, was noch nicht passt ?
Ist nur so eine Überlegung von mir. Ich will niemanden einen Vorwurf 
machen (falls sich jemand auf den Schlips getreten fühlt) !
! ! !  Danke an alle, die schon eine DTU haben und Ihr Bestes geben ! ! 
!
Foto ist von (C)Martin. Nur die Aufmerksamkeit.

[Daniel E. (Gast)]

Herbert K. schrieb:
> Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation
> zwischen dem GD... und dem nRF ?

Das wird schon so gemacht, siehe weiter oben. Aber der verwendete NRF 
ist nicht nur ein Transmitter, sondern auch ein Mikrocontroller. Die 
Kommunikation zwischen GD und NRF lässt deswegen nicht direkt auf das 
HF-Geschehen schließen.

Was aber noch nicht versucht wurde: versuchen, ob der Flash vom NRF 
auslesbar ist. Siehe meinen Vorschlag:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[B. G. (golf2010)]

Herbert K. schrieb:
> Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA
> loslaufen lassen.

Ich schlage vor, kurz vor der Stromversorgung des DTUs jeweils 
HF-Aufnahmen zu starten.
Evtl auch mit etwas weniger Samplerate, damit es weniger Aussetzer gibt.
Nach ein paar Aufnahmeversuchen müßte man zumindest die 
Start-Sequenz(en) des DTU finden können. Vielleicht kommt man dann etwas 
weiter.
Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?

[Daniel E. (Gast)]

Gute Idee! Und am besten auch mal ohne die Sniffer-NRFs, nicht dass wir 
uns mit deren ACKs oder dergleichen verrennen.

[martin (Gast)]

B. G. schrieb:
> Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?

Hallo golf,
ja, tatsächlich sind die so entstanden, zumindest was die DTU betrifft 
und die Kanäle 3 und 23. Man sieht das auch gut an den seriellen 
Aufnahmen. Die UART-Pegel sind zunächst auf Low, gehen dann auf High und 
dann kommt die Initialisierung des NRF24LE1E (3x Request/Response).
Danach beginnt das Suchen nach Invertern.
Kanal 40 habe ich dann im laufenden Betrieb aufgenommen, nachdem ich 
gemerkt hatte, dass da mehr los war.

Bei allen Versuchen war der Inverter vorher schon an, da er immer eine 
Weile braucht bis er initialisiert ist.

[Oliver F. (of22)]

Hallo zusammen.

Eine Frage an alle die hier fleißig die HF Daten analysieren.
Ich habe, wie bereits gesagt, auch einen NRF24 Sniffer am Laufen.
Leider kann dieser nur auf die eingestellten Adressen lauschen.
Der Chip unterstützt mehrere Datapipes. (Siehe Anhang)
Ich denke, die WR werden eine Datapipe betreiben, mit deren Seriennummer 
als Adresse. Es muss aber noch eine andere Pipe geben mit einer Art 
Broadcast Adresse, die für alle WR gleich ist?!? Ich komme darauf, weil 
ich mehrmals den Hochlauf der DTU gesnifft habe. Sinnvolle Kommunikation 
sehe ich nur auf den Kanälen 3, 23 und 40, wobei die DTU auf Kanal 40 
sehr selten vertreten ist.

In diesem Beispiel ist es so, dass die Wechselrichter (C1) auf einmal 
anfangen zu senden, ohne dass zuvor ein Telegramm von der DTU an die 
Wechselrichter (C3) zu sehen ist. Ich habe das ganze relativ häufig auf 
den einschlägigen Kanälen probiert. In der Regel sind die ersten 
Telegramme immer WR=>DTU, ohne dass ich eine initiale Aktion der DTU 
sehe.
Die Bedeutung der einzelnen Spalten habe ich versucht im Anhang zu 
dokumentieren.

C1 026566496 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1              
C1 026570128 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 026573400 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1              
C1 026595440 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
C1 026597740 00 0590817201 0002 00 1  AADE AADE                                                                         
C1 026613740 00 0590817201 00B8 17 0  95 73104439 73104439 83000000F303E80185000581B4BA142F 142F 1                      
C1 027707212 00 0590817201 00DC 1B 2  95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1              
C1 027713144 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 027716424 00 0590817201 00DC 1B 2  95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1              
C1 027740752 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
C1 027756120 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1              
C1 027764348 00 0590817201 0002 00 1  AADE AADE                                                                         
C1 027767624 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1              
C1 029551548 00 0590817201 00D8 1B 0  95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1              
C1 029557480 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 029560760 00 0590817201 00D8 1B 0  95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1              
C1 029585088 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
C1 029601636 00 0590817201 00DA 1B 1  95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1              
C1 029609864 00 0590817201 0002 00 1  AADE AADE                                                                         
C1 029613140 00 0590817201 00DA 1B 1  95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1              
C1 029635176 00 0590817201 0004 00 2  CA18 CA18                                                                         
C1 029637480 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 034225220 00 0590817201 00D8 1B 0  95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1              
C1 034235752 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 034239032 00 0590817201 00D8 1B 0  95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1              
C1 034261072 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
C1 035451152 00 0590817201 00DA 1B 1  95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1              
C1 035457080 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 035460360 00 0590817201 00DA 1B 1  95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1              
C1 035482388 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
C1 035484696 00 0590817201 0002 00 1  AADE AADE                                                                         
C1 035500772 00 0590817201 00BC 17 2  95 73104619 73104619 83000500F603E8018300213960F485BA 85BA 1                      
C1 035995516 00 0590817201 00D8 1B 0  95 73104439 73104439 010001014803A70BF5014803AC0C0600006AEB1C EB1C 1              
C1 036029056 00 0590817201 0004 00 2  CA18 CA18                                                                         
C1 036044500 00 0590817201 00DA 1B 1  95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1              
C1 036055028 00 0590817201 0006 00 3  EA5A EA5A                                                                         
C1 036058312 00 0590817201 00DA 1B 1  95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1              
C1 036080352 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
C3 037978808 00 1946107301 00DE 1B 3  15 73104619 72819005 801200623DA4AB000000000000000098C8DD09E3 09E3 1

Ist Euch bei der Analyse der HF Daten schon mal eine andere Adresse 
aufgefallen?

[Martin G. (petersilie)]

Hallo Oliver,

Danke für Deine Logs. Ich habe dazu wiederum ein paar 
Fragen/Anmerkungen:

(1)
Nach meinem Verständnis kann der NRF24 zwar von bis zu 6 "Pipes" = 
"Adressen" empfangen, aber nur Pipe 0 ist unabhängig, Pipe 1-5 teilen 
sich die ersten 4 Bytes, d.h. dürfen sich nur im letzten Byte 
unterscheiden (siehe Kapitel 7.7 "Multiceiver"). Das würde erklären, 
warum Du nur Nachrichten von C1 und C3 siehst.

(2)
In Deinen Mitschnitten tauchen auch wieder diese 0-Byte Payload Pakete 
auf. Laut Datenblatt sind das ACK-Pakete, die der Chip automatisch 
sendet, wenn er auf der jeweiligen Adresse etwas empfangen hat. Ich 
meine, bisher sieht es so aus, als sei diese ACK Funktion bei den 
Hoymiles Geräten deaktiviert. Wir sollten diese auf jeden Fall bei 
jeglichen Sniffern auch deaktivieren (setAutoAck(false)), sonst greifen 
die ja aktiv in den Funkverkehr ein. Vielleicht kommt da auch manche der 
Verwirrung weiter oben her - denn die Adresse dieser ACK-Pakete ist ja 
jeweils gleich der Adresse des ursprünglich empfangenen Pakets.

(3)
Bzgl. Deiner Frage wegen anderer Adressen - ich meine, martin (Gast) 
hatte auch schon einmal Adressen beobachtet, die in 0x00 (anstatt 0x01) 
enden. Als "Broadcast" zwischen allen WR würde das aber nicht wirklich 
taugen, hierzu würde sich vielleicht am ehesten die DTU Adresse eignen. 
Vielleicht gibt es bei Inbetriebnahme auch Broadcasts an 0x0000000000 
oder so - auf uC-Seite scheinen manche Pakete solch eine Adresse zu 
enthalten.

-- Petersilie

[Oliver F. (of22)]

Hallo Martin.

Also ich habe jetzt mal etwas mit dem RF25L01+ Chip experimentiert. So 
ganz bin ich noch nicht dahinter gestiegen wie er funktioniert. Es ist 
sicherlich irgend so ein ASIC der als Schrittschaltwerk funktioniert 
ohne abhängige Logic, bzw. ohne die eingestellten Parameter zu prüfen. 
Er macht etwas in Abhängigkeit der eingestellten Register. Es kann schon 
mal sein, dass er völlig durcheinander ist und nur ein Spannungsreset 
hilft. So meine Beobachtung.

Zu Deinen Fragen/Anmerkungen:
(1)
So wie ich es verstehe besteht die Möglicheit, dass die Adressen von 
Pipe 0 und Pipe 1 5 Byte lang sind. Pipe 2-5 betrachte ich nicht, diese 
hängen natürlich von den restlichen Bytes der Pipe 1 ab.
Ich habe die Pipes auf die beiden Wechselrichter programmiert:

pipe 0 ( open ) bound   = 0x3944107301                                                                                  
pipe 1 ( open ) bound   = 0x1946107301                                                                                  
pipe 2 (closed) bound   = 0xc3                                                                                          
pipe 3 (closed) bound   = 0xc4                                                                                          
pipe 4 (closed) bound   = 0xc5                                                                                          
pipe 5 (closed) bound   = 0xc6

Im Log werden die Einträge von C2 nicht angezeigt, weil die Abfrage der 
Pipe im Interrupt aus irgendeinem Grund nicht funktioniert. Darum stimmt 
die im Adurino generierte Prüfsumme nicht. Die Telegramme werden aber 
erfasst, jedoch der Pipe 1 zugeordnet, obwohl sie zu Pipe 0 gehören. 
Hier ein Beispiel, gehört eigentlich zu Pipe 0, die Abfrage

radio2.available(&pipe)

liefert aber Pipe 1, darum wird das Telegramm C3 zugeordnet und 
anschließend wegen falscher Prüfsumme (Die Berechnung legt die Adresse 
WR2 zugrunde) verworfen. In den Nutzdaten sieht man aber, dass das 
Telegramm eigentlich für 73104439 bestimmt ist.

C3 019634660 00 1946107301 00DE 1B 3  15 73104439 72819005 800B00623DD84B00000005000000009117A9035D 1565 0

(2)
Was Du sagst ist absolut richtig, aber wenn dann ist es in der RF24 
Dokumentation missverständlich beschrieben. Die AutoAck Funktion ist bei 
allen "Sniffern" deaktiviert. Darum sollten die nicht für die Ack Frames 
verantwortlich sein.
Die ACK Frames die ich sehe sind auch immer an die Adresse der DTU 
gerichtet. Meine RF24 sind so eingestellt, dass die TX_ADR auf Default 
steht:

TX_ADDR         = 0xe7e7e7e7e7

Das Datenblatt sagt ja, dass für die AutoAck Funktion TX und RX Addr. 
gleich sein müssen.

TX5 device: TX_ADDR = 0xB3B4B5B605
TX5 device: RX_ADDR_P0 = 0xB3B4B5B605
RX device: RX_ADDR_P5 = 0xB3B4B5B605

Muss man sicherlich noch weiter hinterfragen.

(3)
Als Ursache für die Adressen die mit 0x00 enden habe ich für mich den 
yveaux Sniffer ausgemacht. (Gut wenn man einen Schuldigen hat). Dieser 
stellt im RF 24 immer fest eine Adressbreite von 4 Byte ein (Bzw. 
Parametrierte Adressbreite - 1).

#define DEFAULT_RF_ADDR_PROMISC_WIDTH  (DEFAULT_RF_ADDR_WIDTH-1)

Das fehlende 0x01 in der Adresse wird dann schon der Payload zugeordnet. 
Dies ist der Grund, warum ich in älteren Aufzeichnungen immer ein Bit 
vor dem 9-bit PCF hatte. (Siehe Anhang) Die 0x02 ist die 0x01 in Byte 5 
der Adresse.

Martin (Gast) hatte noch eine Anmerkung:
> Was mir hier und auch in meinen Daten aufgefallen ist: In den
> Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer
> mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun
> haben, der für die Antwort verwendet werden soll?

Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über 
die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)

Turn unit off:
C2 850194040 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5CD8000000080000000013DAD8A73B 3BA7 1
Turn unit on:
C2 067083344 00 1946107301 00DE 1B 3  15 73104619 72819005 
800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1
Turn unit off:
C2 055407012 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5DC20000000A0000000076413F7EAF AF7E 1
Turn unit on:
C2 086582484 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5E4B0000000B000000002F872B6ABD BD6A 1

[Oliver F. (of22)]

Ich möchte gerne einen kleinen Teilerfolg vermelden.
Ich kann meine WR ohne die DTU abfragen und erhalte sporadisch 
Antworten. Ein Muster erkenne ich noch nicht.

Bisher kann ich meinen Aufbau nur mit RF24_PA_LOW betreiben.
Aber die Sendeleistung reicht um die 30m entfernten WR zu erreichen.
Beim Senden meldet sich bei einer höheren Sendeleistung immer der CH340 
Chip USB zum Rechner ab.
Zunächst ging sogar nur RF24_PA_MIN, bis ich die 3.3V zum RF Modul mit 
einem 100uF Elko gestützt habe.

Die DTU Radio ID in dem Code kann ich beliebig ändern, die WR antworten 
dann auf die neue DTU ID.
Als Anpassung sollte es reichen, die DTU Radio Ids zu ändern. Bei nur 
einem WR zunächst irgendeine Dummy Adresse verwenden oder diese 
belassen.

#define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL) 
#define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
#define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)

Die Wechselrichter scheinen irgendeinen proprietären Mechanismus bei dem 
Channel hopping zu verwenden. Den habe ich noch nicht verstanden.
Der Trick ist, auf einer anderen Adresse zu empfangen als zu senden und 
beim Senden bis die maximale Retransmit rate mit 2ms Pause zu verwenden.
Zur Zeit verwende ich die Kanäle 3 und 40. Auf einigen anderen Kanälen 
geht bei mir gar nichts, vermutlich wegen meinem WLAN. Muss man evtl. in 
jeder spezifischen Umgebung ausprobieren.
Versucht habe ich es mit einer Kombination aus den bereits weiter oben 
erwähnten Kanälen:

int channels[] = {3, 23, 40, 61, 75};

#define DEFAULT_RECV_CHANNEL (3)           // 3 = Default channel for Hoymiles
#define DEFAULT_SEND_CHANNEL (40)          // 40 = Default channel for Hoymiles

Kann dies jemand bei sich nachvollziehen?
Oder liegt es bei mir daran, dass die WR schon mal mit der DTU 
kommuniziert haben und dadurch noch irgendeine Konfiguration haben?

Bei Fragen oder Problemen einfach melden.

[B. G. (golf2010)]

Hallo Oliver,

was genau wird bei dir zur Anforderung an den WR gesendet ?

Vielleicht sende ich da was falsches. Bisher bei mir ohne Erfolg.
Ich hab 14 retransmits eingschalten, hab auf jeder Megahertz - Frequenz 
2400 - 2525 Mhz gesendet. Der WR hat nirgends geantwortet.

Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen 
und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, 
daß er irgendwo antwortet. Dann könnte ich immer noch mit Aufnahmen 
feststellen, wo.
(Die Messung mit dem AD8318 funktioniert einwandfrei, wenn ich den an 
meinen NRF dran stelle.)

Evtl fehlt dann doch irgendeine Grundinitialisierung an den WR, daß er 
was tut oder ich sende Schrott.

[Oliver F. (of22)]

B. G. schrieb:
>
> was genau wird bei dir zur Anforderung an den WR gesendet ?
>
Hallo B.G.

Der Quelltext ist dem Beitrag angehängt. Ich sende alle 200ms ein 
Telegramm an meine beiden Wechselrichter. Sie antworten nicht jedes mal, 
sondern gefühlt jedes 4-5 Mal. Ich denke das hat mit dem noch nicht 
durchschauten Channel Hopping zu tun.

Es wird nacheinander auf CH40 das 0x80 Telegramm mit einer simulierten 
Unix Zeit gesendet, da ich auf dem nano keine Echtzeituhr habe. Das 
scheint dem WR aber egal zu sein.

Dann das 0x81, 0x80, 0x83, 0xFF Telegramm, wie von Martin in der 
Protokollbeschreibung angegeben. Danke an Martin das ist sehr hilfreich.

Nach dem Senden wird direkt wieder auf CH3 umgeschaltet und gehorcht.

      if (tel > 4)
        tel = 0;
      if (tel == 0)
        size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8);
      else if (tel == 1)
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x81);
      else if (tel == 2)
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x80);
      else if (tel == 3)
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83);
      else if (tel == 4)
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0xFF);

      SendPacket(dest, (uint8_t *)&sendBuf, size);

      toggle = !toggle;
      if (!toggle)
        tel++;

Ein Dump mit Ausgabe von Send und Receive ist angehängt.

Die Zeilen mit diesem Inhalt sind dabei die vom WR empfangenen Daten.

 048491820 00 1234567801 00DC 1B 2  95 73104619 73104619 010001014F027908470150026D08220000FB9CDF 9CDF 1
 048540572 00 1234567801 00DE 1B 3  95 73104619 73104619 02FE300000F91307790762096413840FADF0AB62 AB62 1

"Send..." ist jeweils ein Send auf CH40. PL die Payload, WR1/2 gibt an 
an welche Adresse. Die 0 danach ist der Rückgabewert vom Write, da ja 
kein ACK von den WR kommt. Dann die millis() Zeit des Nano und die Dauer 
des Sendens in millis().

Send... CH40 PL: 1573104439785634128182  WR2 0 48677140 29204
Send... CH40 PL: 15731046197856341281A0  WR1 0 48877844 29204

[B. G. (golf2010)]

vielen Dank,
wenn es jemand gibt, der Erfolg mit dem zurücklesen hat, ohne eigene DTU 
zu besitzen, dann bitte melden.

bei martin müßte es ja evtl jetzt so funktionieren ?

[Martin G. (petersilie)]

Hallo @golf2010 und @of22,

das ist tolle Arbeit. Muss man erst mal drauf kommen! Hoffentlich komme 
ich morgen dazu, das mit meinem Raspi-Setup auszuprobieren.

Können wir eventuell noch weiter einschränken, welche Nachrichten 
wirklich notwendig sind?

(1)
@of22, Du wechselst zwischen den 5 Pakettypen im Kreis herum - hast Du 
mal probiert, ob weniger eventuell immernoch zum Erfolg führen?

(2)
Und habe ich das richtig verstanden, du hörst immer auf Kanal 3? D.h. 
angenommen, Du würdest nach dem Senden auf Kanal 40 bleiben, dann 
würdest Du nichts empfangen?

(3)
Und noch ne ganz ketzerische Frage: wenn Du garnichts sendest und nur 
auf Kanal 3 zuhörst, empfängst Du aber nie irgendwelche Nachrichten, 
oder doch?

[Oliver F. (of22)]

Hallo Martin G.

(1)
Habe ich versucht nur das 0x80 mit dem Unix Timestamp zu senden, das 
reicht aus. Aber dann kommt nur der 01 00 01 Response. Mit den anderen 
zwischendurch kommt auch mal ganz selten eine andere Antwort.
Ich hatte schon versucht mir die Saleae Captures von martin (Gast) 
20.03.2022 13:37 anzusehen, um hier vielleicht anhand der Serial 
Captures ableiten zu können welche Requests erforderlich sind. Könnte 
man die vielleicht als ASCII Dump oder so zur Verfügung stellen? Ich 
habe kein Saleae und so wie ich es veerstehe gibt es keine Stand Alone 
Version der Software.

(2)
Das ist richtig, so ist meine Beobachtung. Gesendet und Empfangen wird 
immer auf einem unterschliedlichen Kanal. Bleibe ich auf dem Sendekanal, 
egal ob 40 oder 3, empfange ich keinen Response.

(3)
Nein, wenn ich aufhöre zu senden kommen keine Responses vom WR mehr.
Er muss immer durch irgendein Telegramm getriggert werden.

[Thomas B. (tbnobody)]

Hallo @of22,

habe mir die Hardware mit dem Nano aufgebaut. Kommunikation mit dem 
NRF24 scheint zu tun. Also Register usw. werden ausgelesen. Nur kurz 2 
Fragen bevor ich hier tiefer in den Code einsteige.
1. Muss die Seriennummer des WR auch Rückwärts angegeben werden?
2. Wie funktioniert das Menü? Wird gleich nach dem Startup schon 
gesendet oder muss man das Senden zuerst über die Serielle Konsole 
starten?

Danke & Grüße
Thomas

[Oliver F. (of22)]

Hallo Thomas.

Die Seriennummer muss in dem define umgekehrt angegeben werden.

An meinem Beispiel:
WR1 = xxxx73104619
WR2 = xxxx73104439

Und im Byte 5 der Adresse die 01 nicht vergessen.

Die Adresse der DTU ist egal, da Du sie ja simulierts.

#define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL) 
#define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
#define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)

Das Menü ist erst einmal uninteressant. Der Code fängt direkt an zu 
senden.
Es waren nur Tests um die Kommunikation auf einzelne Telegramme 
einzuschränken.

Eine Anmerkung noch: Eventuell muss der Sendelevel angepasst werden.
Ich habe die Module ali-005 mit externer Antenne im Einsatz. Damit komme 
ich nicht über PA_LOW sonst hängt sich etwas auf (CH340), oder ich 
bekomme keine Antworten.
Vorhin habe ich es noch die ali-001 ausporbiert. Damit muss ich höher 
gehen auf PA_HIGH sonst bekomme ich keine Antwort von den ca. 30 m 
entfernten Wechselrichtern durch zwei Wände.
Aber auch mit denen kann ich nicht auf PA_MAX gehen sonst kommt wiederum 
keine Antwort.

radio1.setPALevel(RF24_PA_HIGH);

Und dran denken, jetzt ist dunkel. Da kommt nichts mehr, weil der WR aus 
dem DC Kreis versorgt wird.

[Thomas B. (tbnobody)]

Hallo Oliver,

alles klar danke! Habe hier auch den ali-005. Habe aber schon einen 10uF 
angelötet. Werde es erstmal mit LOW versuchen und mich notfalls mit dem 
Laptop raus stellen. Ich bin ja sooo gespannt. Jetzt wenn schon Sonne 
vorhanden wäre :)

Grüße
Thomas

[B. G. (golf2010)]

B. G. schrieb:
> Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen
> und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen,
> daß er irgendwo antwortet.

Ich hab tagelang völlig unnötig rumprobiert. Da war bei mir nur ein 
Zahlendreher in meiner eingegebenen WR-Seriennummer. Nachdem ich den 
heute Nacht gesehen hab, hat der WR heute morgen sofort geantwortet auf 
ein 80 Paket. Also brauchst doch keine extra Initialisierung.

Anbei der Ausgang von meinem Pegelmesser AD8318, am Oszi angeschlossen.
Ich muß jetzt schauen, wo er antwortet.

[B. G. (golf2010)]

B. G. schrieb:
> Ich muß jetzt schauen, wo er antwortet.

auf 2403 kam der gerade.
auf der 2405 gibts hier noch einen weiteren NRF, wohl ein Nachbar. Der 
auf 2405 kommt etwas stärker rein.

[Hubi (Gast)]

Hallo B.G.
dein Testprogramm funzt einwandfrei. Es werden zwar nicht alle Anfragen 
beantwortet, aber so alle 1 - 2 Sekunden kriegt man Daten. Und das ist 
doch schon was.

[B. G. (golf2010)]

Hallo Hubi,
das Programm ist von Oliver. Ich kann kein C, nur Pascal(Avrco) und 
Delphi.

[Thomas B. (tbnobody)]

Hallo,

kann es auch bestätigen. Daten werden empfangen. Ich kann auch 
bestätigen das es mit > RF24_PA_HIGH nicht funktioniert. Zumindest wenn 
ich den NRF24 via USB betreibe. Am Labornetzteil tut es.

[Oliver F. (of22)]

Hallo,
das freut mich zu hören, dass es auch bei anderen klappt.
Das man nicht jedes Mal eine Antwort erhält, liegt an dem noch nicht 
durchschauten Channel Hopping.
Ich habe mal noch ein paar Sachen zum Nachdenken, wer möchte, kann sich 
gerne beteiligen.
Ich habe meiner DTU und einem WR nochmal bei der Kommunikation mit 
diesem Aufbau zugehört: Zwei RF24 Chips. Einer lauscht auf Kanal x und 
der andere auf x + 40, jeweils für 60 s. Dann wird x inkrementiert von 0 
bis 39.
Dabei heraus gekommen ist diese Statistik. Das ist sicherlich eine 
Momentaufnahme, die sich aus meinem WLAN Umfeld und aus anderen Störern 
ergibt. Auch sind bei den Frames WR=>DTU die Antworten von dem zweiten 
Wechselrichter, dessen DTU Anfragen nicht geloggt werden, das könnte das 
Bild verfälschen.
Kommunikation läuft auf mehr als den bisher angenommenen Kanälen, wobei 
es bei den Kanälen 7, 8, 9 auch ein Übersprechen sein könnte.
WR an DTU sind am häufigsten auf Kanal 3 und 23 vertreten. DTU an WR 
springt lustig durch die anderen Kanäle, wobei 0, 7, 9, 23, 27, 35, und 
40 die Spitzenreiter sind. Als Kommandos DTU=>WR sieht man die Ids 0x80, 
0x81, 0x82, 0xFF.

Kanal | Frames | DTU=>WR | WR=>DTU | 0x80 | 0x81 | 0x82 | 0xFF
------+--------+---------+---------+------+------+------+------
    0 |     11 |      11 |      0  |    5 |    0 |    0 |    6
    3 |     81 |       8 |     73  |    5 |    4 |    1 |    2
    7 |     10 |      10 |      0  |    8 |    0 |    0 |    2   
    8 |      3 |       3 |      0  |    2 |    0 |    1 |    0   
    9 |     12 |      12 |      0  |    9 |    0 |    3 |    0 
   11 |      9 |       9 |      0  |    8 |    0 |    1 |    0
   14 |      1 |       1 |      0  |    1 |    0 |    0 |    0
   20 |      3 |       3 |      0  |    2 |    0 |    0 |    1
   23 |     59 |      12 |     47  |    7 |    1 |    4 |    1  
   27 |     13 |      13 |      0  |    9 |    1 |    1 |    2  
   29 |      8 |       8 |      0  |    4 |    0 |    3 |    1
   35 |     11 |      11 |      0  |    5 |    2 |    1 |    3
   37 |      8 |       8 |      0  |    6 |    0 |    2 |    0
   39 |      8 |       8 |      0  |    5 |    0 |    2 |    1
   40 |     10 |      10 |      0  |    6 |    0 |    1 |    3
   61 |     13 |       9 |      4  |    6 |    0 |    2 |    1
   75 |      8 |       3 |      5  |    2 |    1 |    0 |    0

Woher weiß die DTU, auf welchem Kanal der WR lauscht?
Und woher weiß sie, auf welchem Kanal die Antwort vom WR kommt?
So aus einem Bauchgefühl heraus:
Könnte das 0xFF Telegramm die Aufforderung zum Kanalwechsel sein, aber 
wohin?
Bei dem 0x80 Telegramm sehe ich im Byte hinter der 0x80 die Bytes 0x0B 
oder 0x11 (Siehe Screenshot). Die Bedeutung erschließt sich mir noch 
nicht.
Beigefügt der Dump aus dem Minuten Scan als Rohdump und aufbereitete 
Excel.

[Sorbit (Gast)]

Hallo,

es geht voran, aber nicht so direkt Beteilige verlieren den Überblick.
So auch ich.

Kann bitte jemand einmal kurz und knackig die benötigte Hardware 
skizzieren und die Software mit Sourcecode bereitstellen?

Dann kann jeder Homiles Nutzer sich schnell zurechtfinden.

Danke

[Martin G. (petersilie)]

@of22:
Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen 
Uhrzeit stehen?

[Martin G. (petersilie)]

Bezugnehmend auf Sorbit (Gast) würde ich gerne 
https://github.com/grindylow/ahoy als Sammelstelle vorschlagen.

Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf 
das Repository geben.

@Sorbit, ich glaube, so hundertprozentig "einstecken und tut"-Lösungen 
haben wir noch nicht - jeder hat leicht andere Hard- und Software, aber 
gerade deshalb geht es erstaunlich voran! Aber Du hast natürlich Recht, 
ich denke wir haben alle ein Interesse daran, dass das ganze früher oder 
später einfach(er) nachzuvollziehen und zu nutzen wird.

[Oliver F. (of22)]

Martin G. schrieb:
> @of22:
> Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen
> Uhrzeit stehen?

Hallo Martin,
gute Idee, das ist ja fast das Einzige was sich in den Telegrammen 
ändert.
Beziehe ich in meine Grübeleien ein.

> Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf
> das Repository geben.

Bisher ist das Ganze ja nur ein zusammengeklopptes Testprogramm.
z.B. könnte man die CRC Generierung auf eine Bibliothek umstellen.
https://github.com/RobTillaart/CRC oder so.
Auch wird im Testprogramm Kanal 40 zum Senden und 3 zum Empfangen 
verwendet.
Die Statistik oben zeigt ja, dass man auch auf 23 lauschen müsste und 
auf anderen senden.

Aber Du kannst gerne den jetzigen Stand hochladen.

@ Sorbit (Gast):
Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in 
China bestellt hatte. Ich mag die Atmel Dinger aber ansonsten nicht.
Dazu ein RF24 Modul ali-005 (Siehe weiter oben). Die Schaltung habe ich 
skizziert. Ich betreibe den nano mit den 5V vom Laptop USB. Problem ist 
hierbei noch die 3V3 Versorgung des RF24.
Wie Thomas B. (tbnobody) herausgefunden hat verwendet man besser noch 
ein externes Netzteil.
Die Leistung des Linearreglers im CH340 des nanos reicht nicht aus um 
die Versorgung bei höheren Sendeleistungen sicher zu stellen.

[Thomas B. (tbnobody)]

Hallo zusammen,

im Source von Oliver sollten ja die verschiedenen Packages nacheinander 
durchprobiert werden. Daher hätte ich erwartet, dass die Antworten mit 
gleicher Häufigkeit vorkommen. Aber siehe capture.txt im Anhang sehe ich 
hauptsächlich 1er und 2er... die 3er Messages kommen kaum vor. Könnt ihr 
das Nachvollziehen, ist das bei euch ähnlich?

Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu 
dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich 
daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, 
ggf. auch der Strom, aber spätestens bei der Leistung stimmt es 
zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe 
hier einen HM-1500)

Ggf. sind die Telegramme je nach Typ unterschiedlich aufgebaut. Dann 
müsste man aber seinen Typ entweder in der Hoymiles Cloud einstellen 
können oder dieser wird irgendwo noch mitgeschickt.

[Martin G. (petersilie)]

Oliver F. schrieb:
> Aber Du kannst gerne den jetzigen Stand hochladen.

Gesagt - getan: 
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

[Wie bitte? (Gast)]

Oliver F. schrieb:
> @ Sorbit (Gast):
> Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in
> China bestellt hatte.

Davon hab ich genug rumfliegen.
Welcher Code läuft da drauf?
RF Modul hab ich auch mal im 20 er Pack gekauft.

Alles da, auch ein produktiver HM-1200...


Danke

[Was bitte? (Gast)]

Wie bitte? schrieb:
> Welcher Code läuft da drauf?

Siehe zwei Nachrichten weiter oben.

[Martin G. (petersilie)]

Hallo @of22, ich bin noch über Deine Zeile 
https://github.com/grindylow/ahoy/blob/82ce2c9d8864dcc465af804ab0130dd7a7322a6b/tools/nano/NRF24_SendRcv/src/hm_packets.cpp#L49 
gestolpert:

  buf[19] = 0x05;

Warum? Und was passiert, wenn das nicht gemacht wird (also an dieser 
Stelle ein 0-Byte verbleibt)? Ist das der von Dir beobachtete Zähler, 
der sich mit jedem Schaltbefehl erhöht?

[Mag C. (magcode)]

Hallo, ich möchte mir schonmal die Hardware bestellen. Wir reden über 
sowas, richtig? https://www.ebay.de/itm/255283312809
(Einen Nano habe ich)
Danke sehr!

[Oliver F. (of22)]

Hallo @petersilie.

Ja, dass ist richtig. Es ist wie weiter oben beschrieben.
Ich habe gesehen, dass der Zähler mit jeder Schaltaktion inkrementiert 
wird.
Es ist wahrscheinlich ein 16-bit Wert. Durch die ganze Probiererei 
scheint der Zähler aus der Cloud mittlerweile bei 0x0537 zu stehen?!?
Es passiert erst einmal nichts offensichtliches, wenn man das weg lässt.
Keine Ahnung was das ist.

15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1

@Mag C. (magcode):
Ja das Modul verwende ich auch. Wichtig ist, dass es ein NRF24L01*+* 
(Plus) ist.

[Martin G. (petersilie)]

Thomas B. schrieb:
> Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu
> dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich
> daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen,
> ggf. auch der Strom, aber spätestens bei der Leistung stimmt es
> zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe
> hier einen HM-1500)

Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in 
Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier 
unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe 
geschaltet?

Wenn wir die Verläufe über ein paar Stunden betrachten, idealerweise mit 
gleichzeitiger Beobachtung der Ausleuchtung der 4 Solarpanels, dann 
kommen wir bestimmt hinter die genaue Bedeutung der einzelnen Felder.

Der WR-Typ wird ja vielleicht in einem der bisher als "unbekannt" 
gekennzeichneten Bytes/Bits übertragen. Oder vielleicht ist er in der 
Seriennummer kodiert? Oder die DTU fragt das bei der Einrichtung 
einmalig ab?

[martin (Gast)]

martin schrieb:
> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden

Hallo zusammen,
leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, 
wie es hier voran geht. Danke an alle Beteiligte.

Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher 
schon mal aufgenommen hatte:
Könnte es vielleicht sein, dass der Inverter generell auf einem anderen 
aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner 
Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen.
Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das 
wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben 
erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die 
Interferenzen sind.

Nur so eine Idee - auch wenn das von den im FCC Report genannten 
Frequenzen abweichen würde. Falls das den Hersteller überhaupt 
interessiert... (grübel)

[B. G. (golf2010)]

martin schrieb:
> martin schrieb:
>> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden
>
> Hallo zusammen,
> leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega,
> wie es hier voran geht. Danke an alle Beteiligte.
>
> Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher
> schon mal aufgenommen hatte:
> Könnte es vielleicht sein, dass der Inverter generell auf einem anderen
> aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner
> Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen.
> Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das
> wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben
> erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die
> Interferenzen sind.
>
> Nur so eine Idee - auch wenn das von den im FCC Report genannten
> Frequenzen abweichen würde. Falls das den Hersteller überhaupt
> interessiert... (grübel)

Das ist momentan bei mir nicht der Fall. Die WR senden auf den festen 
Channel-Frequenzen, wie es aussieht. Keine Ahnung, was damals alles 
aktiv war bei Deinen Aufnahmen. Das war auch komisch mit den instabilen 
Sendern, als wenn entweder der HackRF oder eine NRF instabil war.
Der WR scannt die Kanäle durch bis er was empfangen hat und, wie es 
aussieht, sendet er dann immer 3 Antwort Telegramme, oft auf 
unterschiedlichen Frequenzen. (Telegramme nicht näher untersucht)
Die Kanalwahl hat erst mal nichts zu tun mit der übermittelten Zeit.

Das Sonagramm der Aufnahme ist etwas schwach, hatte nur ein Stück Draht 
als Antenne.

[martin (Gast)]

B. G. schrieb:
> Das war auch komisch mit den instabilen
> Sendern, als wenn entweder der HackRF oder eine NRF instabil war.

Ok, danke für die Rückmeldung. Ich werde das bei Gelegenheit nochmal 
nachmessen.

[B. G. (golf2010)]

> Der WR scannt die Kanäle durch bis er was empfangen hat.

Deshalb wird vmtl immer mit 15 Retransmits gesendet.
Auch der DTU scannt vmtl einfach die Kanäle durch, die Telegramme werden 
ja genügend oft wiederholt.

[Marcel (Gast)]

Hallo,

ich versuche gerade mal durch den Code zu gehen und diesen zu verstehen. 
Dabei ist mir aufgefallen, das der Wert 0x05 an Stelle 19 gesetzt wird:

buf[19] = 0x05;

dennoch ist er bei deiner Ausgabe aber immer an Stelle 18:

15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1

Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben 
werden ?

Vielen Dank

[Oliver F. (of22)]

Marcel schrieb:
> Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben
> werden ?

Hallo Marcel.

Nein Du hast nichts übersehen. Das rudimentäre Testprogramm zur 
Simulation der DTU schreibt an dieser Stelle immer eine 0x05. So ist es 
momentan noch, weil wir die Bedeutung dieses Wertes noch nicht kennen.

Siehe Nachricht vom  27.03.2022 19:34 an Petersillie.

Das Beispiel was Du anführst ist aus einem aktuellen Scan der 
Kommunikation zwischen DTU und WR. Hier steht dieser "Zähler" jetzt 
schon auf 0x0537.

15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1

Siehe auch Nachricht vom 25.03.2022 15:35:
Dieser Zähler inkrementiert sich, wenn man aus der Hoymiles Cloud heraus 
eine Schaltaktion durchführt.

Turn unit off:
C2 850194040 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5CD8000000080000000013DAD8A73B 3BA7 1
Turn unit on:
C2 067083344 00 1946107301 00DE 1B 3  15 73104619 72819005 
800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1
Turn unit off:
C2 055407012 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5DC20000000A0000000076413F7EAF AF7E 1
Turn unit on:
C2 086582484 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5E4B0000000B000000002F872B6ABD BD6A 1

[Marcel (Gast)]

Vielen Dank,

ist aber auch ein witziger Zufall, das genau 05 um eine Stelle nach 
vorne gerückt ist. Somit hat der Counter da 16 bit, ergo 4 Stellen.

Danke

[Martin G. (petersilie)]

Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine erste 
Testimplementierung in Python für RaspberryPi.

Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf 
Kanal 40, ansonsten immer auf Kanal 3 zuhören.

Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit 
einer DTU in Kontakt war.

Ergebnis: siehe Anhang.

(Programm siehe 
https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)

[Hubi (Gast)]

Hallo zusammen
mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren.
Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB 
Leistung der letzten Tage, Wochen, Insgesamt?

[Sorbit (Gast)]

Martin G. schrieb:
> Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine
> erste
> Testimplementierung in Python für RaspberryPi.
>
> Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf
> Kanal 40, ansonsten immer auf Kanal 3 zuhören.
>
> Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit
> einer DTU in Kontakt war.
>
> Ergebnis: siehe Anhang.
>
> (Programm siehe
> https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)

Hardware Setup, Software?
Viele unterstützen und sollten es auch nachbauen Können.

Danke

[Oliver F. (of22)]

Hubi schrieb:
> Hallo zusammen
> mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren.
> Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB
> Leistung der letzten Tage, Wochen, Insgesamt?

Hallo Hubi,
das weiß ich zwar nicht zu 100% aber ich halte es für sehr 
unwahrscheinlich.
Das ist klassisch die Aufgabe der Cloud. Das wirst Du in ioBroker mit 
influxdb und/oder Grafana oer ähnlichem machen müssen.

[Martin G. (petersilie)]

Sorbit schrieb:
> Hardware Setup, Software?

Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den 
ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja 
noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben. 
Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon.

https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md

Gruß

-- petersilie

[Sorbit (Gast)]

Martin G. schrieb:
> Sorbit schrieb:
>> Hardware Setup, Software?
>
> Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den
> ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja
> noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben.
> Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon.
>
> https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md
>
> Gruß
>
> -- petersilie

Klasse, super Beschreibung, toll gemacht!

Woher bekommst Du die Seriennummer vom WR?
Meiner ist leider schon unter den Panels auf dem Dach verbaut😪😪

[Thomas B. (tbnobody)]

Sorbit schrieb:
> Woher bekommst Du die Seriennummer vom WR?

Die Seriennummer habe ich leider bisher nur auf der Rückseite des WR 
gesehen. Dort sind 2 Labels mit der Seriennummer aufgebracht.

[Wie bitte? (Gast)]

Thomas B. schrieb:
> Die Seriennummer habe ich leider bisher nur auf der Rückseite

Schei.......

Ohne die Nummer keine Kommunikation?

[Thomas B. (tbnobody)]

Wie bitte? schrieb:
> Ohne die Nummer keine Kommunikation?

Das ist korrekt.

[martin (Gast)]

Thomas B. schrieb:
> Dort sind 2 Labels mit der Seriennummer aufgebracht.

Genau. Damit man eines abziehen und auf den beigefügten 
Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu 
klettern ;-)

[temp (Gast)]

mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max. 
Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden? 
Gibt es dafür Beispiele auf Protokollebene?

[Wie bitte? (Gast)]

martin schrieb:
> Genau. Damit man eines abziehen und auf den beigefügten
> Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu
> klettern ;-)

Tja, nacher ist man immer schlauer  ;-(

[Oliver F. (of22)]

temp schrieb:
> mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max.
> Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden?
> Gibt es dafür Beispiele auf Protokollebene?

Hallo.
Das ist genau der Grund warum ich mich mit der Materie beschäftige. Ich 
habe eine DTU-WLite. Eigentlich hätte ich mit der Cloud Integration von 
Hoymiles prima leben können. Leider ist es aber so, dass Hoymiles die 
Funktion zum Begrenzen der Leistung bei der Lite DTU gesperrt hat. Man 
braucht dazu die sündhaft teure DTU-Pro.
Noch ist es ein weiter Weg, weil nur ein geringer Teil der Payload 
zwischen DTU und WR entschlüsselt wurde. Wir stehen da erst am Anfang, 
zu verstehen wie es funktioniert. Dazu kommt, dass zwar schon viele 
Telgramme gesnifft wurden, aber eben nur zwischen DTU-Lite und WR. Die 
Möglichkeit mit einer DTU-Pro zu sniffen habe ich z.B. nicht. Darum ist 
es für mich fraglich ob ich jemals diese Funktion der 
Leistungsbegrenzung nutzen kann.
Ich bekomme sporadisch viele verschiedene Antworten vom WR. Die 
Bedeutung muss erst einmal verstanden werden. Aber da ist bestimmt auch 
etwas dabei für WR mit mehr als zwei MPP Trackern.
P.S.
Autark wirst Du die WR der HM- Serie nie betreiben können, da sie ja 
einen NA Schutz haben und immer ein vorhandenes Netz in bestimmten 
Grenzwerten sehen wollen.

[Mag C. (magcode)]

Hallo,

ich habe die RF Hardware erhalten und werde es mal mit den Arduino 
Sourcen probieren.

Ich habs auf Anhieb nicht gefunden ... wo würde ich die Seriennummer 
eintragen?
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

Danke sehr!


Update: habs gefunden! -> WR1_RADIO_ID

[Marcel (Gast)]

Hallo,

bei mir antwortet der WR ziemlich präzise jede Minute (ich warte immer 3 
Sekunden auf Antwort). Aber alle Anfragen unter einer Minute werden 
nicht beantwortet (zumindest nicht auf Kanal 3)

Ich denke mal, die haben da einen Schutz drin, dass man eben nicht jede 
Sekunde abfragt. Vielleicht kann das jemand mit DTU und cloud 
bestätigen, indem man sich die Auflösung der Daten anschaut.

Time Tue Mar 29 15:59:32 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 24 00 88 00 00 40 A7 03 A5 08 EF E8  

Time Tue Mar 29 16:00:32 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 F9 FD  

Time Tue Mar 29 16:00:40 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 FA FE  

Time Tue Mar 29 16:01:40 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7A 00 23 00 84 00 00 40 A7 03 A5 08 FA FA  

Time Tue Mar 29 16:01:48 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 79 00 23 00 83 00 00 40 A7 03 A5 08 F6 F2  

Time Tue Mar 29 16:02:48 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 78 00 22 00 7F 00 00 40 A8 03 A6 08 FC 08  

Time Tue Mar 29 16:03:48 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 73 00 20 00 77 00 00 40 A8 03 A6 08 F5 00  

Time Tue Mar 29 16:04:49 2022
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 1D 00 6D 00 00 40 A8 03 A6 08 F7 20

Ich habe einen HM-400 (mit nur einem Anschluß für Solar Paneele). 
Dennoch sind haben bei mir die Position 18-23 Werte. Ich denke nicht, 
das diese den Wert Volt, Ampere und Power beinhalten. Die Positionen 
12-17 Stimmen mit meinen Messungen überein.

if (data[0] == 0x95 && data[9] == 0x01) {
        // Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7C 01 33 04 90 00 00 40 75 03 73 09 09 0B  
        DATA.voltage_pv1 = float(data[12] << 8 | data[13]) / 10;

        DATA.ampere_pv1 = float(data[14] << 8 | data[15]) / 100;

        DATA.power_pv1 = float(data[16] << 8 | data[17]) / 10;

        DATA.voltage_pv2 = float(data[18] << 8 | data[19]) / 10;

        DATA.ampere_pv2 = float(data[20] << 8 | data[21]) / 100;

        DATA.power_pv2 = float(data[22] << 8 | data[23]) / 10;
    } else if (data[0] == 0x95 && data[9] == 0x82) {
        // Received: 95 73 10 90 25 73 10 90 25 82 13 88 04 57 00 01 00 30 03 E8 01 5B 00 1F 2E 2A 44  
        DATA.frequency = float(data[10] << 8 | data[11]) / 100;

    }

Danke für die Arbeit bisher. Ich bin schon mal sehr happy, das ich 
einige Daten lesen kann.

Marcel

[Marcel (Gast)]

Wobei, ich revidiere. Da hatte er nur ein mal ein guten Lauf :) Nach 
erneutem Flashen des ESPs gehts jetzt nicht mehr so präzise.

Marcel

[Martin G. (petersilie)]

(1)
Das mit dem Abfragerhythmus ist noch mysteriös, aber je mehr Erfahrung 
wir sammeln, desto näher kommen wir der Sache.

Ich fände es logisch, wenn der WR ziemlich zeitnah auf eine Anfrage 
antwortet.

Aber er muss eben die Anfrage auch hören (in unserem Fall: gerade auf 
Kanal 40 lauschen), und sie dann (in unserem Fall) genau auf Kanal 3 
beantworten.

Ich meine, in einigen der frühen Posts hatten wir schon beobachtet, dass 
eine DTU auf jeden Fall immer gleich auf mehreren Kanälen anfragt. Ich 
spekuliere mal, dass der WR dann vielleicht auch immer gleich auf 
mehreren Kanälen antwortet.

Vielleicht ist garnicht viel mehr Magie dabei. Auf vielen Kanälen 
fragen. Auf vielen Kanälen antworten. Wenn auf einem Kanal "lange" nie 
eine Nachricht kommt, mal auf einen anderen der bekannten Kanäle 
wechseln. Presto, semi-verlässliche Kommunikation.

(2)
Nachrichten-Inhalte. Hier habe ich mir seit längerem keine Zeit mehr 
genommen, die Protokollbeschreibung upzudaten. Es gibt ja ein paar neue 
Erkenntnisse. Aber ich sammle jetzt eifrig Beispieldaten mit meinem WR, 
und Du und viele andere machen dasselbe. Da finden wir bestimmt nach 
einiger Zeit Muster/Werte, über die wir dann auf den Inhalt der 
jeweiligen Datenfelder schließen können.

Deine Daten von dem 1-kanaligen WR sind vielleicht ähnlich wie die von 
@tbnobody mit seinem HM-1500 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")? Er 
sagt ja auch, dass es sich hier nicht um V/A/W handeln kann.

Ruhig mal nen ganzen Tag mitloggen!

[Marcel (Gast)]

Ich hab die Daten jetzt mal mit meinem Esphome und Homeassistant 
Messungen verglichen. Ich gehe davon aus, das die Position 20 und 21 die 
Gesamtproduktion in Watt des WR und die Position 22 und 23 die 
Tagesproduktion in Watt sind. Die passen ziemlich genau mit den Daten 
von meinem HomeAssistant (wo ich den Strom messe, den ich ins Netz 
gebe).

DATA.total_production = float(data[20] << 8 | data[21]) / 1000;
DATA.daily_production = float(data[22] << 8 | data[23]);

Aber ich denke das werden die anderen bestimmt bald bestätigen oder 
widerlegen können :)

Marcel

[Mag C. (magcode)]

Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt. 
WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen.

Beim starten gibt die serielle Konsole aus:

-- Hoymiles test --
19:11:42.309 -> 
19:11:42.309 -> Radio 1:
19:11:42.309 -> SPI Speedz  = 10 Mhz
19:11:42.309 -> STATUS    = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0

19:11:42.309 -> RX_ADDR_P0-1  = 0xdeadbeef01 0x1234567801

19:11:42.309 -> RX_ADDR_P2-5  = 0xc3 0xc4 0xc5 0xc6

19:11:42.309 -> TX_ADDR    = 0xdeadbeef01

19:11:42.309 -> RX_PW_P0-6  = 0x20 0x20 0x20 0x20 0x20 0x20

19:11:42.309 -> EN_AA    = 0x00

19:11:42.309 -> EN_RXADDR  = 0x02

19:11:42.309 -> RF_CH    = 0x03

19:11:42.309 -> RF_SETUP  = 0x23

19:11:42.309 -> CONFIG    = 0x37

19:11:42.309 -> DYNPD/FEATURE  = 0x00 0x00

19:11:42.309 -> Data Rate  = 250 KBPS

19:11:42.309 -> Model    = nRF24L01+

19:11:42.309 -> CRC Length  = Disabled

19:11:42.309 -> PA Power  = PA_LOW

19:11:42.309 -> ARC    = 15

19:11:42.309 ->

Das wars dann leider. Mehr kommt nicht. Auch nach einigen Minuten 
warten. Ich war bis auf 4m am HM-400 ran. Der HM-400 hat während des 
Tests Strom produziert, war also aktiv. Verkabelung habe ich 
kontrolliert. Allerdings habe ich den Kondensator nicht und das RF Modul 
direkt an den 3.3v Pin des Nano angeschlossen...

[Oliver F. (of22)]

Mag C. schrieb:
> Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt.
> WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen.

Du darfst nichts in HEX wandeln, also umrechnen. Die dezimale 
Seriennummer wird einfach als Hex Wert eingetragen.

Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge 
angegeben werden:

An meinem Beispiel:
WR1 = xxxx73104619

Und im Byte 5 der Adresse die 01 nicht vergessen.
#define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = 
WR1

[Marcel (Gast)]

Zusätzlich braucht der HM ein wenig Sonne, sonst ist er aus. Hier in 
Nord Deustchland antwortet mein HM nicht mehr.

Da musst Du wohl bis morgen warten.

Marcel

[Thomas B. (tbnobody)]

Hallo zusammen,

ich habe gerade bei meinem HM-1500 einen etwas längeren Auszug von 
Sonntag Ausgewertet. (Rohdaten, leider ohne Timestamp siehe Anhang)

Hierbei habe ich mir zuerst die 1er Messages angeschaut. Ich habe mich 
hierbei am -r5 Dokument orientiert: 
https://www.mikrocontroller.net/attachment/550551/hoymiles-datenformat-r5.txt

PV1.u und PV1.i konnte ich soweit nachvollziehen. Die nächsten beiden 
Bytes machen dann keinen Sinn. Allerdings entsprechen die weiteren 
beiden Bytes (was im Beispiel oben PV2.u wäre) genau den Produkt von 
PV1.u und PV1.i, also der Leistung in .1W
Im Excel im Anhang habe ich dies auf dem Sheet 
"output_2022-03-27_18-20-16__1er" dargestellt. Spalte D - N entsprechen 
den HEX Werten, In Spalte P - W habe ich diese in Dez Werte umgerechnet.

Bei den 2er Messages konnte ich keine parallelen zum -r5 Dokument 
finden. Also es sieht hier nicht nach AC Werten aus. Spalte S 
multipliziert mit Spalte T entspricht aber Spalte V (+/- ein bisschen). 
Könnte also wieder U, I und P sein.

Bei den 3er Messages könnte Spalte V die AC Spannung sein. Aber das ist 
nur geraten.

[Thomas B. (tbnobody)]

Hier btw ein Link zu einer DTU Pro:
https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html

Interessanter als die Hardware finde ich aber den Link mit den 
Zugangsdaten.

Ich habe mal ein paar Bilder angefügt.
Irgendwo scheint also auch noch die Temperatur und die Firmware Version 
versteckt zu sein.

[Marcel (Gast)]

Hallo,

danke für die Screenshots. Das mit der Temperatur ist sehr hilfreich - 
ich hatte auch ein paar mal ähnliche Werte gesehen.

Danke
Marcel

P.s.: ich würde ein paar Sachen/Informationen in deinen Screenshots 
unlesbar machen. Wer weiß wie die drauf sind.

[Marcel (Gast)]

Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power) 
pro Solar Panel oder ist das immer pro WR zusammengefasst? Ich bin 
bisher der Meinung, das ma neben nur die Gesamtleistung sieht und nicht 
jedes PV einzeln.

Marcel

[Marcel (Gast)]

Sorry, für den SPAM. Basierend auf deinen Daten, könnte ich mir 
vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar 
Panel Nummer ist. Das würde auch Sinn machen, da ich in meinen Logs noch 
nie eine 02 gesehen habe und immer nur 01 gefunden habe (HM-400 hat nur 
einen Anschluß für einen Solar String).


WR1 - Solar Panel #1

95 71603546 71603546 01...
[code]

WR1 - Solar Panel #2
[code]
95 71603546 71603546 02...

Anbei auch mal meine Daten analyse, wobei ich mir mit den letzten 
Feldern nicht ganz sicher bin. Bei mir stimmen die Daten mit meinen 
Messungen überein, aber die von Thomas ergeben nicht so viel Sinn (ggf. 
bedeuten die Werte doch was anderes).

[Mag C. (magcode)]

Oliver F. schrieb:


> Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge
> angegeben werden:
>
> An meinem Beispiel:
> WR1 = xxxx73104619
>
> Und im Byte 5 der Adresse die 01 nicht vergessen.
> #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL =
> WR1

Danke für den Tipp! Jetzt läuft's

 000486220 00 1234567801 00DE 1B 3  95 74950839 74950839 010001014C000B00240000062C0000093AEEE320 E320 1
 005286328 00 1234567801 00DA 1B 1  95 74950839 74950839 010001014B000B00240000062C0000093BE85281 5281 1
 008486552 00 1234567801 00DA 1B 1  95 74950839 74950839 010001014C000B00240000062C0000093BEF5260 5260 1
 013286980 00 1234567801 00DC 1B 2  95 74950839 74950839 010001014A000B00240000062C0000093AE8C1A9 C1A9 1
 016487192 00 1234567801 00DE 1B 3  95 74950839 74950839 010001014B000B00240000062C00000939EA86F1 86F1 1
 021287296 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014B000B00250000062C00000938EA01FD 01FD 1
 024487512 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014B000B00250000062C00000937E5E02C E02C 1
 026085360 00 1234567801 00DA 1B 1  95 74950839 74950839 010001014B000B00250000062C00000937E5A904 A904 1
 026132564 00 1234567801 00DC 1B 2  95 74950839 74950839 82138700230000000103E9003B000858D3F33E3C 3E3C 1
 027687708 00 1234567801 00DC 1B 2  95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1
 029285564 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1
 029321264 00 1234567801 00DA 1B 1  95 74950839 74950839 82138700230000000103EA003B00081468072891 2891 1
 032486288 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1
 035685728 00 1234567801 00DC 1B 2  95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1
 037285832 00 1234567801 00DE 1B 3  95 74950839 74950839 010001014C000B00250000062C00000938EDDA64 DA64 1
 037333012 00 1234567801 00D8 1B 0  95 74950839 74950839 82138700230000000103EB003B0008D01AB0655A 655A 1

[Thomas B. (tbnobody)]

Marcel schrieb:
> Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power)
> pro Solar Panel oder ist das immer pro WR zusammengefasst?

Hallo Marcel,

bei dem oben genannten Account handelt es sich ja um einen öffentlichen 
Test-Account den jeder verwenden kann (Es handelt sich nicht um meine 
Anlage). Aktuell zeigt die Detailansicht (siehe Cloud-05.png) für jedes 
Panel unterschiedliche Watt angaben (33 vs. 32W). Spannung und Strom 
sind beim Klick auf die Panels identisch (32,5V und 1,0A).
Es kann sich hier natürlich auch um Rundungsungenauigkeiten handeln und 
Strom/Spannung/Leistung ist trotzdem individuell.

Bzgl. dem Hex Wert nach den WR Seriennummern... Dann müsste ich aber bis 
zu 4 Nachrichten erhalten, zumindest hat der HM-1500 vier individuelle 
Ports.

Grüße
Thomas

[martin (Gast)]

Marcel schrieb:
> asierend auf deinen Daten, könnte ich mir
> vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar
> Panel Nummer ist.

Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele 
angeschlossen und an der Stelle nie eine 02 gesehen.

Eine andere Frage:
Habt ihr schon mal andere Anfagecodes ausprobiert, um andere Daten zu 
erhalten?
Ich habe bei der seriellen Aufzeichnung mindestens 3 verschiedene 
Anfragepakete gesehen:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Marcel (Gast)]

Martin schrieb:
>Marcel schrieb:
>> basierend auf deinen Daten, könnte ich mir
>> vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar
>> Panel Nummer ist.

> Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele
>angeschlossen und an der Stelle nie eine 02 gesehen.

Hallo,

okay, das ist schon mal ein guter Hinweiß. Die Daten für das 02 Command 
machten auch nicht so viel Sinn.

Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten 
passen bisher mit meinem Messungen.

Werde heute auch mal probieren andere Requests zu senden und schauen ob 
und was zurück kommt.

Marcel

[Thomas B. (tbnobody)]

Marcel schrieb:
> Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten
> passen bisher mit meinem Messungen.

Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu 
bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor.

Du hattest einen HM-400 oder?

[Mag C. (magcode)]

Marcel schrieb:
> Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten
> passen bisher mit meinem Messungen.

Danke für die Doku! Kann ich so bestätigen mit meinem HM-400.

[Martin G. (petersilie)]

Sorry bin gerade krankheitsbedingt ziemlich außer Gefecht.
Hier sind mal die Logs von meinem HM-700 (2 Kanäle) für die letzten 2 
Tage:

- https://filetransfer.io/data-package/QBOaWm7M#link

Geloggt wie unter 
https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md#example-run 
beschrieben.

Wie viele Posts weiter oben ja entdeckt haben, sind die Antworten wohl 
je nach Wechselrichtertyp leicht unterschiedlich. Bei meinem sieht man 
plausibel die U, I, P-Werte für die beiden angeschlossenen Panels.

Vielleicht fällt jemand zu den "unknown"-Werten was ein - vielleicht 
sind das die gleichen, die bei anderen Wechselrichtern in den Feldern 
für das "2te Panel" stehen?

Kandidaten sind u.a. Tages- und Gesamtenergie (in Wh) sowie die 
Temperatur (in Zehntel-°C).

Als "Auslöser" für die Antworten sende ich bisher wohlgemerkt nur im 
Sekundentakt eine 0x80-Nachricht. Das scheint ausreichend häufig zu 
einer Rückmeldung zu führen.

[Martin G. (petersilie)]

So aus dem Bauch raus würde ich für CMD=0x02 mal tippen:

- uk4, uk5: Tages-Energie Panel 1, 2 [Wh] (läuft am nächsten Tag wieder 
mit 0 los)
- uk1, uk3: Gesamt-Energie seit Geburt (?), Panel 1, 2 [Wh]

[Martin G. (petersilie)]

...und dann gibt es noch die mysteriöse 0x83-Antwort. Über die beiden 
Tage verteilt kam die nur 49 mal:

$ cat two-days-hm-700.log | grep '95 74 60 81 45 74 60 81 45 83' | cut -b 28-
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e8 00 67 00 06 86 06 1e
: 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 75 00 06 4f ee 3f
: 95 74 60 81 45 74 60 81 45 83 00 00 00 17 03 e8 00 7c 00 06 94 08 0c
: 95 74 60 81 45 74 60 81 45 83 00 01 00 23 03 e8 00 91 00 06 3d a0 d5
: 95 74 60 81 45 74 60 81 45 83 00 01 00 29 03 e8 00 9e 00 06 d5 43 db
: 95 74 60 81 45 74 60 81 45 83 00 01 00 2d 03 e8 00 a3 00 06 51 61 44
: 95 74 60 81 45 74 60 81 45 83 00 01 00 32 03 e8 00 a5 00 06 5f 15 27
: 95 74 60 81 45 74 60 81 45 83 00 01 00 40 03 e8 00 b2 00 06 90 be 26
: 95 74 60 81 45 74 60 81 45 83 00 00 00 65 03 e8 00 d3 00 06 4d f8 f8
: 95 74 60 81 45 74 60 81 45 83 00 00 00 5e 03 e8 00 eb 00 06 a9 9c 7b
: 95 74 60 81 45 74 60 81 45 83 00 00 00 5d 03 e8 00 f3 00 06 08 dc 81
: 95 74 60 81 45 74 60 81 45 83 00 01 00 41 03 e8 00 f8 00 06 58 71 6a
: 95 74 60 81 45 74 60 81 45 83 00 00 00 5a 03 e8 01 00 00 06 03 6e cd
: 95 74 60 81 45 74 60 81 45 83 00 03 00 a3 03 e8 01 1b 00 06 a1 88 68
: 95 74 60 81 45 74 60 81 45 83 00 00 00 82 03 e8 01 57 00 06 9a ef 5a
: 95 74 60 81 45 74 60 81 45 83 00 02 00 61 03 e8 01 75 00 06 9e 7f 0d
: 95 74 60 81 45 74 60 81 45 83 00 02 00 6d 03 e8 01 5b 00 06 0f b5 74
: 95 74 60 81 45 74 60 81 45 83 00 02 00 52 03 e8 01 4d 00 06 2e 30 f9
: 95 74 60 81 45 74 60 81 45 83 00 00 00 4a 03 e8 01 4e 00 06 4d ef 5c
: 95 74 60 81 45 74 60 81 45 83 00 00 00 47 03 e8 01 4d 00 06 5e 07 a9
: 95 74 60 81 45 74 60 81 45 83 00 01 00 44 03 e8 01 4c 00 06 ac 22 7d
: 95 74 60 81 45 74 60 81 45 83 00 01 00 27 03 e8 01 2b 00 06 45 4e fc
: 95 74 60 81 45 74 60 81 45 83 00 00 00 15 03 e8 01 13 00 06 c3 c5 fa
: 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 01 07 00 06 55 2f 96
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 fd 00 06 83 78 f6
: 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 78 00 06 8f ef 08
: 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 7b 00 06 25 2a 64
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7f 00 06 b3 43 77
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7e 00 06 35 4f fc
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 ea 00 82 00 06 ed 4b df
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 8b 00 06 1c 6e 0d
: 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 8f 00 06 ae 48 83
: 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 90 00 06 a6 5e 82
: 95 74 60 81 45 74 60 81 45 83 00 00 00 13 03 e8 00 92 00 06 70 46 4c
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 9c 00 06 38 74 24
: 95 74 60 81 45 74 60 81 45 83 00 00 00 16 03 e8 00 9d 00 06 c8 67 df
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a0 00 06 5d 79 71
: 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 a3 00 06 c5 e0 64
: 95 74 60 81 45 74 60 81 45 83 00 00 00 12 03 e8 00 ae 00 06 85 5a 98
: 95 74 60 81 45 74 60 81 45 83 00 00 00 07 03 e8 00 aa 00 06 ca b1 2d
: 95 74 60 81 45 74 60 81 45 83 00 00 00 08 03 e8 00 a5 00 06 88 74 aa
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 a3 00 06 55 16 10
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0a 03 e8 00 9c 00 06 c0 56 fb
: 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 9b 00 06 82 e1 13
: 95 74 60 81 45 74 60 81 45 83 00 00 00 09 03 e8 00 9d 00 06 10 5d 22
: 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 9c 00 06 ef a9 38
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a4 00 06 cd e2 7e
: 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 a1 00 06 b5 ce 31
: 95 74 60 81 45 74 60 81 45 83 00 00 00 04 03 e8 00 9d 00 06 0f ac c1

Vielleicht ist da was bzgl. Kanal-Hopping drin? Hat jemand Ideen?

[Marcel (Gast)]

Hallo Thomas,

> Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu
> bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor.

Diese Antwort kommt bei mir so mehrmals auf 0x15er Request zurück

Send to channel: 40
Time Wed Mar 30 14:56:30 2022

Sending packet of size: 27
Now sending: 15 73 10 90 25 72 81 90 05 80 0B 00 62 44 6F 9E 00 00 00 05 00 00 00 00 94 87 EF  ok...
Listen channel: 3
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 82 00 1C 00 6C 00 00 41 C6 01 18 08 F7 07  
Got reply: 
        Voltage: 38.60V, Ampere: 0.28A, Power: 10.80W
        Daily production: 280.000 W, AC Voltage: 229.5 V, Total production: 16.838 kW
        Frequency: 0.000, Temperature: 0.0 °C
Received: 95 73 10 90 25 73 10 90 25 82 13 87 00 67 00 00 00 04 03 E8 00 FE 00 06 BB 44 0C  
Got reply: 
        Voltage: 0.00V, Ampere: 0.00A, Power: 0.00W
        Daily production: 0.000 W, AC Voltage: 0.0 V, Total production: 0.000 kW
        Frequency: 49.990, Temperature: 25.4 °C
This round is over.

Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief 
wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die 
wichtigen Teile des Codes in mein Programm kopiert. Das gibt mir die 
Möglichkeit mit dem Code zu spielen, da ich auch alle Teile davon genau 
verstehe. Ebenfalls setze ich auch immer die korrekte Zeit (vielleicht 
ist es das).

Mein Script sendet den Request und hört dann 3 Sekunden auf dem Kanal 3. 
Dann wartet es erneut 3 Sekunden und beginnt von vorne.

> Du hattest einen HM-400 oder?

Genau.

Ich habe jetzt auch einen zweiten ESP32 mit einem NRF Chip und die habe 
ich jetzt so synchronisiert, das der eine eine Message sendet und der 
andere dann zur gleichen Zeit verschiedene Kanäle durch hört. Ich hoffe, 
das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber 
vorstellen, das es eine Weile dauert.

Marcel

[[e-mail] (Gast)]

martin schrieb:
> Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele
> angeschlossen und an der Stelle nie eine 02 gesehen.

Schaut mal in die Wechselrichter nach, ob die tatsächlich 2 seperate 
MPPT-Tracker habe könnten. Bei meinen SG700 werden die 2 Eingänge für 
die Module intern gebrückt.

[B. G. (golf2010)]

Marcel schrieb:
> Ich hoffe,
> das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber
> vorstellen, das es eine Weile dauert.

Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen.
Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83  auf 
bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der 
Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz 
von den dreien kommen.
Wenn eine andere Sendefrequenz genutzt wird, dann sind das bei mir 3 
andere mögliche Antwortfrequenzen. z.b noch die 2475 Mhz.
Nochmal das jpg mit Kommentaren.

[Marcel (Gast)]

Hallo,

ich habe jetzt mal die Messages auf Kanal 40 gesendet und dann alle 
Kanäle einzeln von 1 - 128 für 3 Sekunden gehört. Da kam nie was, ausser 
eben auf Kanal 3.

Ebenfalls habe ich mal mit der Anfrage bits rumgespielt. Es kommen zwar 
bei einigen Kombinationen Antworten, aber die machen bisher noch keinen 
Sinn.

Hab die Daten mal angehängt.

Marcel

[Oliver F. (of22)]

Marcel schrieb:
> Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief
> wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die
> wichtigen Teile des Codes in mein Programm kopiert.

Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 
schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack 
Overflows kämpfe.
- Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit 
PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die 
ganzen Libraries quält. Ist das normal?
- Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme 
gab es?

B. G. schrieb:
> Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen.
> Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83  auf
> bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der
> Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz
> von den dreien kommen.

Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61?
Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger 
mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80 
gelauscht.
Meine WR antworten nur auf Kanal 3 und 23.
Die DTU sendet abwechselnd auf:
0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61.
Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung 
abhängen? z.B. auf welchem Kanal WLAN aktiv ist?

[Marcel (Gast)]

Hallo Oliver

> Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328
> schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack
> Overflows kämpfe.
Do it :)

> - Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit
> PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die
> ganzen Libraries quält. Ist das normal?

Also ich nutze auch Visual Studio Code mit der PlatformIO extension. 
Wenn bei mir alles ein mal gebaut ist, dann dauert das neu kompilieren 
unter 1sec. Das Hochladen und den Boot Button zu drücken ist das was am 
längsten dauert :). Ich hänge mal mein Programm hier mit an. Ist alles 
in einer Datei und ich nutze keine eigene CRC Berechnung, sondern eine 
externe offizielle Libs. Sobald alles einigermaßen geht, würde ich den 
Code dann sauber machen. Aber derzeit bin ich so schneller.

> - Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme
> gab es?

Um ehrlich zu sein, habe ich es noch nie hinbekommen Circular Buffer auf 
meinen ESPs zum laufen zu bekommen (ist aber auch schon Jahre her das 
ich es probiert habe). Soweit ich mich erinnern kann, muss man auf dem 
ESP Circular Buffer anders initialisieren und es gibt Probleme, die man 
beachten muss, mit irgendwelchen Integer Größen, die anders auf einem 
Nano und einem ESP32 sind. Bin mir da aber nicht mehr sicher. Ist 
wirklich schon sehr lange her und ich baue es immer um, wenn ich 
Circular Buffer sehe.

Marcel

[Mag C. (magcode)]

Hallo, ich habe auf Basis des Arduino Sketch ein kleines MQTT Gateway 
geschrieben (in JAVA) und teste die nächsten Tage.


Nun frage ich mich wo die Reise hingeht. Ich persönlich finde folgendes 
Setup clever:

Microcontroller (Arduino oder ESP ohne aktivem WIFI) und RF als relativ 
"dumme Empfängerhardware" mit USB Anschluss.
Die "Software" (nodeJS, python, java oder auch Plugins für 
Homeautomation Systeme) dann auf einem beliebigen Computer (Raspi, 
Windows, Linux, Mac) laufen lassen.
Die meiste "Intelligenz" ist in der "Software". Dies betrifft das Parsen 
der Daten sowie das Aufbereiten und versenden via MQTT. Falls die 
verschiedenen Hoymiles tatsächlich unterschiedliches Parsing erfordern, 
ist es m.E. einfacher das in der "Software" anzupassen (anstatt C code 
schreiben und Firmware Flash).
Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den 
Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte.


Wie ist Eure Meinung?

[Marcel (Gast)]

Hallo Mag,

ich finde schon, das es einen "Treiber" geben sollte der ein 
einheitliches Interface hat (unabhängig vom verwendetem Hoymiles). So 
wie du das beschreibst, klingt es ja wie ein Open MQTT Gateway 
Integration, die deine Anfrage in das jeweilige Protokoll (LORA oder 
dann eben Hoymiles umwandelt). Dann muss die Logic, in der Tat irgendwo 
anders sein.

Ich persönlich würde eine ESPHome Version bauen, die dann die Werte 
ebenfalls - in einem einheitlichem Format - via MQTT oder HomeAssistant 
API wegschreibt.

Höre aber auch sehr gerne andere Meinungen :)

Marcel

[B. G. (golf2010)]

Oliver F. schrieb:
> Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61?
> Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger
> mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80
> gelauscht.
> Meine WR antworten nur auf Kanal 3 und 23.
> Die DTU sendet abwechselnd auf:
> 0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61.
> Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung
> abhängen? z.B. auf welchem Kanal WLAN aktiv ist?

Ich hab das vielleicht falsch beschrieben. Nicht mein DTU sendet auf 
2403, sondern mein Atmel, der mir als DTU-Ersatz dient. Dein 
Original-DTU wechselt wohl schon die Sendefrequenzen. Ich bleibe mit 
meinem AVR beim Senden immer auf einer gleichen Frequenz ( 2403) und 
dann antwortet der WR mir immer mit den Telegrammen 01,02,80 auf den 
maximal 3 Frequenzen 2423,2440,2461, siehe jpg. Wenn ich eine andere 
Sendefrequenz nehme, dann antwortet der WR z.b. auf 2475 2423 und 2403.

Aber mir scheint es, daß es vielleicht auch Unterschiede bei den 
jeweiligen WRs gibt. Ich selbst habe einen HM-600

[Marcel (Gast)]

Hallo,

ich glaube die Bytes von den Seriennummern der Wechselrichter werden 
berücksichtigt. Wenn ich hier mal die letzten Daten anschaue und die 
Texte mit den Angaben zu dem Versionen der Wechselrichter lese, ergibt 
sich ein Muster. Ich denke, dieses Byte kann dazu genutzt um die 
Antworten auszuwerten. Weil meine HM-400 Antwort hat Fundamental andere 
Werte als die von einem HM-600 (Ampere, Volt etcpp).


Vielleicht kann ja jeder, der demnächst hier schreibt, seine Version des 
Wechselrichters (HM-XXX) reinschreiben und seine Seriennummer? Dann kann 
man meine These mal validieren.

HM-1500:
 - 71 60 35 46
HM-700:
 - 74 60 81 45
HM-600: 
 - 72 22 02 00 
HM-400: 
 - 73 10 90 25

Es sieht fast so aus, als wenn jede Version eines erste Byte hat.

Marcel

[Mag C. (magcode)]

HM-400:
 - 74 95 08 39

[Marcel A. (a-marcel)]

> 74 95 08 39

Verdammt :D Die passt nicht ins Schema.

Wobei die DTU ja die ganze Seriennummer kennt. Ggf. ist den ersten 4 
Zahlen die Version kodiert.

Meine wäre dann für den HM-400 Serial No: 1121 73109025

Marcel

[Thomas B. (tbnobody)]

Schaut mal hier (Kapitel 6):

https://www.manualslib.de/manual/793350/Hoymiles-Mi-300.html?page=16#manual

Mit den ersten 4 Zeichen scheint man wohl Inverter als auch Version 
identifizieren können...

Fehlersuche
Hoymiles hat die interaktive Leistung des Mikroumwandlersystems Mitte 2020 aktualisiert.
Wenn Sie den Mikroumwandler mit Seriennummer "1022xxxxxxxx" verwenden, so beziehen Sie
sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikroumwandler mit
Seriennummer "1020xxxxxxxx" und "1021xxxxxxxx" verwenden, so beziehen Sie sich bitte auf
Abschnitt 6.2 und Abschnitt 6.4.
*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.

Gleiches gibt es wohl auch für die größere Reihe: 
https://www.manualslib.de/manual/811724/Hoymiles-Mi-1000.html?page=17#manual

Fehlersuche
Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems Mitte 2020 aktualisiert.
Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" verwenden, so beziehen
Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikrowechselrichter mit
Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen Sie sich bitte auf
Abschnitt 6.2 und Abschnitt 6.4.
*Anmerkung: Der Mikrowechselrichter 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.

[Mag C. (magcode)]

Hm-400
11 21 74 95 08 39

[Thomas B. (tbnobody)]

HM-1200
1161xxxxxxxx

HM-1500
1161xxxxxxxx

[Marcel A. (a-marcel)]

Sehr gut,

das hilft schon mal wenn wir weitere Daten analysieren und später um den 
Parser zu schreiben. Ich denke mal, das die ersten 4 Ziffern immer eine 
Gruppe beschreiben und die Antworten im gleichen Format sind.

Danke
Marcel

[B. G. (golf2010)]

Hm-600    11 41 xx xx xx xx

[isnoAhoy (Gast)]

Hallo Zusammen,

*Anmerkung: Der Mikrowechselrichter 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.

Das mit den og. unterschiedlichen Versionen der Wechselrichter und DTUs 
könnte mit dem verbauten NRF24L01+ Chip gegenüber den bei Seriennummer 
1062x, bzw. DTU-Pro, DTU-G100 und DTU-W100 vermutlich verbauten NRF5x 
Chip zusammenhängen.

Folgendes Zitat aus dem Enhanced ShockBurst (ESB) Dokument scheint die 
beiden Modi und Kombinationen zu erklären:

Enhanced ShockBurst (ESB) - Features
https://developer.nordicsemi.com/nRF_Connect_SDK_dev/doc/PR-3842/nrf/ug_esb.html

* 1 to 32 bytes dynamic payload length in legacy mode
* 1 to 252 bytes static payload length between nRF5 Series devices

[Mo (Gast)]

HM300: 11 21 71 ...

[Martin P. (mpolak77)]

HM-350: 1121 72xxxxxx
HM-700: 1141 74xxxxxx

[Chris A. (cherio7)]

HM 1200

1161 70523283

ich habs mal einen Tag lang laufen lassen und sehe 4 arten von Antworten
hab sie mal beigefügt.

[Thomas B. (tbnobody)]

Hallo,

ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht 
und nach Bildern von Hoymiles Wechselrichtern mit Seriennummern gesucht.
Ebenfalls habe ich die Seriennummern aus diesem Thread verwendet.
Das Ergebnis, insgesamt 29 WR, befindet sich im Anhang. Als Bild habe 
ich noch das Ergebnis angehängt. Also das Mapping zwischen Typ und 
Prefix. Das sieht erstmal recht eindeutig aus.

[Mag C. (magcode)]

Hier ist noch ein HM-800 :-) -> 1141
https://youtu.be/FL7BI6b4-00?t=139

[Thomas B. (tbnobody)]

Mag C. schrieb:
> Hier ist noch ein HM-800 :-) -> 1141

Danke für den Hinweis :)
Habe ich noch in das Ergebnis aufgenommen (siehe Anhang).
Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten 
auch die Telegramme der farbig markierten Inverter kompatibel sein.

[Marcel A. (a-marcel)]

Hallo Thomas,

> ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht

Das ist natürlich clever und erheblich effizienter als hier zu fragen. 
Chapeau

> Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten
> auch die Telegramme der farbig markierten Inverter kompatibel sein.

Davon gehe ich auch aus.

In hab mir vorhin noch mal den Thread durchgelesen und dabei die Bilder 
von der geöffnetem DTU angeschaut. Darin ist ja scheinbar eine RTC 
verbaut. Da ich in den vergangenen Tagen ein einziges mal wirklich aller 
60 Sekunden für einen längeren Zeitraum konstant Antworten vom WR 
bekommen habe, kann es sein, das der WR ggf. den Timestamp und die 
differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren 
ggf. die Uhren meiner ESP32 und des WR grob syncron.

Was denkt Ihr ?

Ebenfalls habe ich mich mal in das Konzept von channel hopping (grob) 
eingelesen und eine synchronisierte Zeit oder Tackt ist dabei wohl 
essentiell.

Ich hab vor ein paar Minuten mal ein RTC DS3231 an meinen ESP geklemmt 
und den code so verändert, das die Zeit immer von der RTC kommt. 
Vielleicht klappt es ja morgen bei Sonne.

Marcel

[Comix (Gast)]

Hallo,
hab nen HM-1200 116172216067

Tolles Projekt
bin mal auf das Ergebnis gespannt.

[Hubi (Gast)]

Mag C. schrieb:
> Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den
> Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte.

Da ich weder MQTT noch ESPHome oder sonstige Home-Automation nutze, wäre 
gerade das zitierte meine Lösung. Bei mir laufen mehrere ESPs und als 
Master fungiert ein RasPi, der mittels cron-Jobs die Daten von den ESPs 
sammelt, speichert, auswertet, grafisch darstellt, ...

Zu der "Software" : die brauch man nur einmal zu entwickeln, die 
Auswertung der empfangenen Daten könnte man über eine Tabelle (im 
EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so 
aussehen:
1141 HM-600 AC-Spannung 02 12 2 10
bedeutet: Die Wechselspannung ist im Telegramm 02, beginnt ab Byte 12, 
ist 2 bytes lang und muss noch durch 10 geteilt werden.
Wenn das Projekt so richtig in Software umgesetzt wird (Github), hätte 
ich folgenden Vorschlag:
1) Die Kommunikation in einen Kern packen, der für Arduino, ESP, RasPi 
passt, am besten in C.
2) Funktionalität darüber hinaus in Plugins packen, die man über #define 
mit dazu linkt. Weitere Funktionalität wären zB: MQTT, ESPHome, Display, 
Webserver, Upload, ...

[Martin G. (petersilie)]

Marcel A. schrieb:
> kann es sein, das der WR ggf. den Timestamp und die
> differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren
> ggf. die Uhren meiner ESP32 und des WR grob syncron.

Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer 
konstanten 0x80-Anfrage (jede Sekunde) laufen:

15 74 60 81 45 78 56 34 12 80 0b 00 62 46 d3 0f 00 00 00 05 00 00 00 00 92 ea c3

Er scheint damit genauso häufig zu antworten wie zuvor, als ich jede 
Sekunde die aktuelle Uhrzeit mitgeschickt hatte (siehe 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?").

[Martin G. (petersilie)]

Mag C. schrieb:
> Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den
> Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte.

Meine Interessen liegen da ähnlich, ich komme eher aus der 
RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für 
verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an 
seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen.

Das nette daran ist, dass man insbesondere während der 
Experimentierphase sehr einfach Anpassungen machen kann, ohne dass man 
immer gleich einen Controller neu flashen muss.

Aber na klar gibt es auch gute Gründe für Arduino/ESP32 
Implementierungen. Unsere Forschungen hier sind für beide Ansätze 
gleichermaßen hilfreich.

Habe soeben nochmals die in Entstehung befindliche `ahoy` 
Python-Software aktualisiert, diese sendet jetzt die empfangenen Daten 
gleich via MQTT raus.

* https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py

[Marcel A. (a-marcel)]

Hallo petersilie,

> Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer
konstanten 0x80-Anfrage (jede Sekunde) laufen:

Ja, ich habe meinen Logger mit RTC seit heute morgen laufen und sehe 
ebenfalls keine Besserung in der Antworthäufigkeit :/


Marcel

[B. G. (golf2010)]

Logs von meinem HM-600, auf die Schnelle ein altes Projekt umgeändert.

[martin (Gast)]

Hubi schrieb:
> Zu der "Software" : die brauch man nur einmal zu entwickeln, die
> Auswertung der empfangenen Daten könnte man über eine Tabelle (im
> EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so
> aussehen:
> 1141 HM-600 AC-Spannung 02 12 2 10

Hallo Hubi,
ich bin mir nicht sicher, ob dass so einfach möglich ist. In meinen 
Daten von früher habe ich gesehen, dass die gleiche Paket-ID wohl 
verschiedene Inhalte haben kann, je nach dem welcher Request zuvor kam 
(siehe Bild oder früherer Post):
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Anscheinend kommt es auf die vorige Abfrage an. Allerdings habe ich das 
bisher nicht in den Funk-Daten beobachtet, die Mitschnitte in der Excel 
sind von der DTU-internen seriellen Kommunikation.

Kann das jemand verifizieren?

[Sergey S. (sergey_s632)]

Guten Tag! Ich habe H M 600 114170810815
und DTU W100 10D 373114359. Kann mir jemand helfen, die 
“S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer 
gibt es nicht an, sagt, dass er selbst der Installateur ist.

[Waldemar K. (wwkk)]

Hello All.

I just bought 3 x Hoymiles HW1500 for my PV installation.
I will install them within one month.

How could I contribute to your project to proceed with creating a 
reverse-engineered and open source solution to communicate with those 
micro inverters.

I have some SDR usb dongle available to put it to work as well.

Kind regards
WK

[Heinz R. (heijz)]

Martin G. schrieb:
> Meine Interessen liegen da ähnlich, ich komme eher aus der
> RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für
> verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an
> seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen.

Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder 
ESP32 zur Verfügung stellen könnte

Raspi, schön und gut - aber meiner ist zu weit weg vom WR - gerade die 
Hoymiles-WR sind ja eigentlich dafür gedacht auf dem Dach montiert zu 
werden?

[mtet (Gast)]

Sergey S. schrieb:
> Guten Tag! Ich habe H M 600 114170810815
> und DTU W100 10D 373114359. Kann mir jemand helfen, die
> “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer
> gibt es nicht an, sagt, dass er selbst der Installateur ist.

Hallo,
eventuell können die helfen:
https://www.enercab.at/hoymiles/1067-hoymiles-pv-monitoring-dtu-wlite.html
Dort ist eine +49er Telefonnummer vorhanden.

Mein HM600 SNR: 114172609296 wartet noch auf die PV-Module.

[Thomas B. (tbnobody)]

Heinz R. schrieb:
> Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder
> ESP32 zur Verfügung stellen könnte

Mein Plan wäre eine Library aka. https://github.com/atc1441/NETSGPClient

Durch die NRF24 Library wäre dies dann vmtl. auch sowohl für ESP32 als 
auch ESP8266 nutzbar (und mit etwas Glück auch nativ unter Linux). Was 
man außen rum baut ist wieder ein ganz anderes Thema. Aber wie 
@petersilie schon sagt, die Grundlegenden Dinge die aktuell laufen 
eignen sich sowohl für Python als auch für eine C Implementierung. 
Erstmal muss man allgemein verstehen was passiert :)

Habe heute einen ganzen Tag mitgelogged und werde das jetzt Auswerten. 
Spontan sehe ich aber nur 01er, 02er und 03er Nachrichten. (Gepulled 
habe ich die Daten mit dem ahoy.py Script)

[Martin G. (petersilie)]

Waldemar K. schrieb:
> How could I contribute to your project to proceed with creating a
> reverse-engineered and open source solution to communicate with those
> micro inverters.
>
> I have some SDR usb dongle available to put it to work as well.

Hello Waldemar, and welcome!
One of the unsolved mysteries is how the inverters and DTU "hop" between 
different frequencies. Maybe scans with your SDR dongle can help.

[Martin G. (petersilie)]

Ich habe mal wieder das Format-Beschreibungs-Dokument aktualisiert.

Leider immer noch ein bisschen durcheinander und unvollständig. Falls 
jemand Lust hat, hier mitzuhelfen - gerne melden!

https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt

[Thomas B. (tbnobody)]

Martin G. schrieb:
> Falls
> jemand Lust hat, hier mitzuhelfen - gerne melden!

Gerne. Ich bin dir gerade auch schon auf github gefolgt.

Also 0x83 Nachrichten sehe ich bei mir garnicht. Das ahoy.py Script 
liefert bei mir wie gesagt 1-3er Nachrichten. Ich habe in der Excel 
Datei im Anhang mal 3 Sheets gemacht. Für jede Nachricht eines. Ich habe 
aktuell am HM-1500 nur 3 Panels. Daher sollte irgendein Wert null sein. 
(Muss morgen mal prüfen welcher Kanal genau nicht angesteckt ist)

Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x 
übertragen, der Strom und die Leistung jedoch 4x.

Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung 
ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw. 
geben aktuell Sinn. (bzw. ich sehe es gerade nicht)

[Heinz R. (heijz)]

Thomas B. schrieb:
> Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x
> übertragen, der Strom und die Leistung jedoch 4x.

Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel

Deshalb evtl. nur 2 Messwerte?

[Sergey S. (sergey_s632)]

Heinz R. schrieb:
> Thomas B. schrieb:
>> Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x
>> übertragen, der Strom und die Leistung jedoch 4x.
>
> Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel
>
> Deshalb evtl. nur 2 Messwerte?

Und HM-600 auch zwei?

[Carsten B. (carstenb)]

Sergey S. schrieb:
> Und HM-600 auch zwei?
Ja der HM-600 hat 2 Eingänge mit separaten MPT. Ich hoffe, dass ich dies 
Wochenende meines Setup endlich soweit bekomme, dass ich auch an meinem 
HM-600 lauschen kann...

[Martin G. (petersilie)]

Thomas B. schrieb:
> Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung
> ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw.
> geben aktuell Sinn. (bzw. ich sehe es gerade nicht)

Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem 
HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten:

- Spalte T: Energie [Wh] seit letztem Start
- Spalte S: aktuelle AC-Leistung [W]
- Spalte R: Energie [Wh] seit Geburt
- Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum?
- Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung
  um die 0,6°C/0,7°C kalt?

[Mag C. (magcode)]

Hallo,

Ich habe mal ein paar Daten des HM-400 aufgezeichnet zum Vergleich mit 
meinem AC-seitigen Shelly Plus 1PM. Sieht alles sehr gut aus!

Das Setup mit Nano (FDTI Version) und nRF24L01+ zieht sich übrigens etwa 
0,35W aus dem USB.
Die Scanhäufigkeit habe ich verringert auf ca. 1 mal pro Minute.
Ich nutze "RF24_PA_MIN"

[Peter L. (leliep)]

Es gibt ein Dokument mit der Modbus-Beschreibung. Evtl. helfen die dort 
vorhandenen Beschreibungen der Telegramme und Befehle.

Quelle:
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

[Thomas B. (tbnobody)]

Martin G. schrieb:
> Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem
> HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten:
>
> - Spalte T: Energie [Wh] seit letztem Start
> - Spalte S: aktuelle AC-Leistung [W]
> - Spalte R: Energie [Wh] seit Geburt
> - Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum?
> - Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung
>   um die 0,6°C/0,7°C kalt?

Hallo Martin,
An dem Tag von dem die Aufzeichnung stammt hat ein Gosund 
Zwischenstecker ca. 1kWh gemessen. Die Gesamtproduktion die die Gosund 
gemessen hat seit Inbetriebnahme des Inverters liegt bei ca. 240kWh.
  - Spalte T: Wäre damit zu hoch, und ich würde eher einen Kommawert 
erwarten
  - Spalte S: Nachdem es ein ganzer Tag ist hätte ich einen ähnlichen 
Verlauf wie bei den DC Kurven erwartet. Also erst steigend, dann 
fallend.
  - Spalte R: Kommt mir für den Gesamtertrag zu hoch vor
  - Spalte P: Ggf. sind das auch Werte um 200 herum wenn man den Wert 
statt durch 10 durch 100 teilt. Muss ich beobachten wie sich das heute 
entwickelt. (Ggf. Gesamtleistung seit Geburt, dann würde aber der Gosund 
Mist messen)
  - Spalte E: Hätte die Temperatur v.a. unterm Tag eher im Bereich 5-10 
Grad geschätzt.

[Martin P. (mpolak77)]

Marcel schrieb:
> Hallo Oliver
>
>> Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328
>> schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack
>> Overflows kämpfe.
> Do it :)

Hallo Marcel,

ich habe deinen Code mit einem ESP8266 Nodemcu am laufen:

-musste das getLocalTime(..) nachimplementieren, weil das das nur am 
ESP32 gibt
-musste natürlich die Pins ändern
-musste in der Receive-Loop ein yield(); einbauen, da sonst der wdt 
getriggert hat.

habe meine WR und DTU Serial eingetragen ....
.... sehe auf den Request zwar ein "ok"
.... dann kommt aber keine Antwort vom WR

[Carsten B. (carstenb)]

Hurra, es hat geklappt :)

Ich empfange jetzt stabil Daten vom HM-600 aus etwa 15m Distanz.

Setup:
* HM-600 S/N 114172014650
* Arduin0 Nano V3
* NRF24L01 + separater Spannungsregler (damit geht bei mir RF24_PA_HIGH 
ohne Probleme)
* Software von 
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

Hilft es weiter, wenn ich einfach mal laufen lasse und den Output 
protokolliere und hochlade?

[Thomas B. (tbnobody)]

Carsten B. schrieb:
> Hilft es weiter, wenn ich einfach mal laufen lasse und den Output
> protokolliere und hochlade?

Auf jeden Fall. Damit kann man das über einen längeren Zeitraum 
betrachten. Das macht es einfacher die Werte und Felder in den 
Telegrammen zu bestimmen!

[Solarliebhaber (Gast)]

Hallo,

ich habe,
HM-1200
3*350 W Panels angeschlossen
Arduin0 Nano V3
NRF24L01 +

Ich koennte auch Daten sammeln, helfen.
Was muss ich tun um dieses Setup zum Fliegen zu bringen.
Kurzanleitung moeglich?
Danke

[Martin P. (mpolak77)]

Ich hätte jetzt je eine Version von
-NR24_SendRcv
-Marcel's ESP32 code

der auch auf ESP8266/Nodemcu kompiliert und läuft. Wenn das für noch 
jemanden von Interesse ist bitte melden.

[Heinz R. (heijz)]

Hallo Martin,

ich hätte großes Interesse an der ESP-Version.

Versuche mich hier gerade an einem Arduino Mini Pro - bekomme den in 
Platformio nicht geflasht...
ESP8266 würde es evtl einfacher machen

Viele Grüße

[Carsten B. (carstenb)]

Auf die Schnelle:

Hardware

Nano V3 pin --- pin NRF24L01
D2  ----------- IRQ
D6  ----------- CSN
D9  ----------- CE
D11 ----------- MISO
D12 ----------- MOSI
D13 ----------- SCK

Software: 
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

Ich habe es im Arduino IDE übersetzt und hochgeladen

Seriennummer des HM musst du im Sourcecode eintragen wie folgt 
(NRF24_sniff.cpp):
#define WR1_RADIO_ID ((uint64_t)0x5046017201ULL) // WR1 HM-600

Das ist sind die letzten 4 Byte der S/N Rückwärts plus eine 01 am Ende. 
Meine S/N ist 114172014650

[Heinz R. (heijz)]

Carsten B. schrieb:
> Ich habe es im Arduino IDE übersetzt und hochgeladen

welche Datei lädst Du hier in der Arduino IDE?
Müsste es hierzu nicht eine .ino geben

[Martin P. (mpolak77)]

Heinz R. schrieb:
> ich hätte großes Interesse an der ESP-Version.

Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die 
Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann 
trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von 
Links nach rechts ein ... das 5. byte muss 01 sein.

Ich habe den Code auf das originale CircularBuffer vom Arduino portiert, 
deshalb sind hier auch weniger Files dabei als im GitHub Link von weiter 
oben. Es sollte auch für Arduino Nano / Uno weiter kompilieren.

[Martin P. (mpolak77)]

...hier ein scan von meinen 2 (HM-350 und HM-700) WR

[Carsten B. (carstenb)]

Heinz R. schrieb:
> Müsste es hierzu nicht eine .ino geben

Ich habe sie einfach umbenannt...

[Heinz R. (heijz)]

Carsten B. schrieb:
> Ich habe sie einfach umbenannt...

Ach das geht?  lass uns das gerne mal in einem separaten Thread 
erörtern? :-)

[Carsten B. (carstenb)]

Thomas B. schrieb:
> Auf jeden Fall. Damit kann man das über einen längeren Zeitraum
> betrachten. Das macht es einfacher die Werte und Felder in den
> Telegrammen zu bestimmen!

Hallo in die Runde,

Angehängt die Daten, die ich heute mitgeschrieben habe mit dem HM-600. 
Zwischendrin hat der Nano 2x kurz neu gestartet (Wackelkontakt), die 
Bereiche ggf.raus löschen.

Ich bin grade dran, das mit der Excel, die hier gepostet wurde ein wenig 
auszuwerten. Mit den "01" Messages bin ich fertig und komme zu dem 
Ergebnis auf dem angehängten Sreenshot.

Spalte T enthält die addierten Leistungswerte bei der DC-Anschlüsse. 
Passt grafisch ganz gut überein mit dem, was mein Shelly heute auf der 
AC-Seite mitgeloggt hat.

Ich poste nachher noch meine Auswertung für die weiteren Messages.

Viele Grüße

Carsten

[Chris A. (cherio7)]

Hier mal ein Tageslog von meinem HM-1200

es sind 2x 19V Panels in reihe je 130W an einem der 4 Anschlüsse dran.
Das ergebniss passt noch nich ganz zu der format description.

Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert?
bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, 
was kann das sein ? :)

[Carsten B. (carstenb)]

Chris A. schrieb:
> Hier mal ein Tageslog von meinem HM-1200

> bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden,
> was kann das sein ? :)

Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02 
plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die 
Netzspannung und die Netzfrequenz drin ist. Siehe Bild.

[Chris A. (cherio7)]

> Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02
> plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die
> Netzspannung und die Netzfrequenz drin ist. Siehe Bild.

ok, aber Netzspannung und Frequenz ist bei meiner 02.. Anwort nicht zu 
finden. Oder überseh ich was ?

auch bei der 01.. Antwort scheint es einen Unterschied zu geben.
Die Amps machen da keinen sinn oder ?

020000BC8B0000000F0009000100010000A6E639
010001015200020032000600A800000283D9A089

[Carsten B. (carstenb)]

Carsten B. schrieb:
> Ich poste nachher noch meine Auswertung für die weiteren Messages.

Hier nun meine Auswertung, soweit wie ich gekommen bin:

Ergebnis Excelauswertung 02.04.2022:

01 Telegramme:
Spalte N: U1 0,1V
Spalte O: I1 0,01A
Spalte O: P1 0,1W
Spalte Q: U2 0,1V
Spalte R: I2 0,01A
Spalte S: P2 0,1W

02 Telegramme:
Spalte N: E seit „Geburt“ ? Wh
Spalte O: E DC akt. Tag ? Wh
Spalte Q: E AC akt. Tag ? Wh
Spalte R: U AC 0,1V (Netzspannung)
Spalte S: F 0,01 Hz (Netzfrequenz)

Ob die kumulierten Tagesangaben zutreffen zeigt sich Morgen...

03 Telegramme: empfange ich keine

81 Telegramme: kann ich mir keinen Reim drauf machen

83 Telegramme: kann ich mir keinen Reim drauf machen

Ergänzung zum Setup des HM-600: An beiden Eingängen sind je 350Wp 
angeschlossen

Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum 
erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht 
messen.

[Carsten B. (carstenb)]

Manchmal bin ich einfach naiv-pragmatisch und hin und wieder klappt das 
sogar...

Ich bin jetzt nicht der Programmierprofi und habe bisher nur die 
Arduino-Umgebung benutzt. Bevor ich mir die Mühe mache, eine neue 
Umgebung aufzusetzen, dachte ich, ich probiere es einfach mal :-)

[SM D. (bandit7311)]

Carsten B. schrieb:
>
> Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum
> erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht
> messen.


Guten Abend,

die Wechselrichtern werden aus dem DC Anteil versorgt und deshalb sind 
sie bei wenig Licht bzw Nacht nicht ansprechbar.

ich lese hier schon eine ganze Weile mit. Momentan habe ich einfach 
keine freien Zeitslots mich hier einzubringen, leider.
Auch ich hätte gerne den momentan benutzten DTU Pro ausser Betrieb und 
würde gerne irgendwo auf meinem Synology NAS ein Datengrab schaffen um 
meine Ertragszahlen zu speichern.

Was mir persönlich aufgefallen ist, dass aus meinen 60 Wechselrichtern 
in allen Paketen die Seriennummern nicht fortlaufend einsortiert sind 
sondern immer in einer gewissen Struktur und hierbei meine ich nur die 
letzten 4 Ziffern. Kann es sein dass sich darin die Kanalnummern für den 
jeweiligen Wlan Kanal verschlüsseln, man stellt sich vor dass bei einer 
grösseren Anlage sonst schnell zu einer Menge Datenkollisionen kommen 
würde.

Viel Erfolg in die Runde, programmiere aus Leidenschaft in C und würde 
gerne helfen, habe aber momentan zu viel andere Dinge die in der 
Priorität weiter oben sind

Solong
B

[Thomas B. (tbnobody)]

Chris A. schrieb:
> Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert?
> bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden,
> was kann das sein ? :)

Hallo Chris,

die Telegramme von HM-1200 und HM-600 werden nicht kompatibel sein.
Siehe: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"


Schau dir mal das Excel in 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" an

In den 1er Messages habe ich einmal die Spannung, 2x den Strom und 2x 
die Leistung.
In den 2er Messages habe ich bisher 1x die Spannung und 1x die Leistung 
gefunden. Ich habe nur 3 Panels dran, darum vmtl. nur insgesamt 3x Strom 
und Leistung.

In den 3er Messages habe ich nur die AC Spannung gefunden. Werde mir 
aber deinen Dump noch ansehen.

[Peter L. (leliep)]

Carsten B. schrieb:
> 81 Telegramme: kann ich mir keinen Reim drauf machen
>
> 83 Telegramme: kann ich mir keinen Reim drauf machen
>
> E

Wenn Du in das von mir weiter oben bereitgestellte Dokument (Hoymiles 
Modbus implementation..., 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")
ab Seite 8 unter 4.2.1 schaust, dann wirst Du dort bei den Function 
Codes diese Werte als Antwort auf fehlerhaften "Read Single Device 
Status" und "Read Device Data" finden.

Könnte vielleicht passen...?

[Carsten B. (carstenb)]

Moin Peter,

danke für den Hinweis, kann wirklich sein, dass 81 nur Fehlerhafte 
Übertragungen sind.

Bei den 02-Messages bin ich mir bei Spalte Q inzwischen recht sicher, 
dass Spalte T die WR-Temparatur ist. O und Q sind vermutlich eher der 
Tagesertrag je Kanal.

02 Telegramme:
Spalte N: E seit „Geburt“ Wh (sieht gut aus, zählte heute morgen weiter 
hoch)
Spalte O: E DC akt. Tag ? Wh (vielleicht doch E für Kanal 1 ?)
Spalte Q: E AC akt. Tag ? Wh (vielleicht doch E für Kanal 2 ?)
Spalte R: U AC 0,1V (Netzspannung) (passt)
Spalte S: F 0,01 Hz (Netzfrequenz) (passt)
Spalte T: Temperatur 0,01 °C (neu)

Mal sehen, was der Tag bringt...

Carsten

[Martin G. (petersilie)]

Mal zwischendurch ein Themenwechsel zu "Channel Hopping":

Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen 
"Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im 
Anhang.

Da zeichnet sich klar ab, dass

* die "0x01"-Nachrichten immer nach ca. 18 ms eingehen,
* die "0x02"-Antworten immer nach ca. 67 ms und
* die "0x83"-Antworten immer nach ca. 116 ms.

Das ist für "Anfrage auf Kanel 40, Antwort auf Kanal 3".

[Heinz R. (heijz)]

Martin P. schrieb:
> Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die
> Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann
> trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von
> Links nach rechts ein ... das 5. byte muss 01 sein.

Hallo Martin,

danke, scheint zu funktionieren

Ich bekomme jetzt beiliegende Daten - sieht richtig aus?

Es ist ein HM-1200 - nur 2 Eingänge belegt
Aktuell liefert er ca. 35W


Viele Grüße

[Chris A. (cherio7)]

Heinz R. schrieb:
> Ich bekomme jetzt beiliegende Daten - sieht richtig aus?
>
> Es ist ein HM-1200 - nur 2 Eingänge belegt
> Aktuell liefert er ca. 35W

Hi Heinz,

ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber 
keine Leistung.

An welchen Anschlüssen hast du die Panels dran ? links oder rechts?
Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann 
nichts sinnvolles mehr bei der 01 Antwort.

[Thomas B. (tbnobody)]

Chris A. schrieb:
> Heinz R. schrieb:
>> Ich bekomme jetzt beiliegende Daten - sieht richtig aus?
>>
>> Es ist ein HM-1200 - nur 2 Eingänge belegt
>> Aktuell liefert er ca. 35W
>
> Hi Heinz,
>
> ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber
> keine Leistung.
>
> An welchen Anschlüssen hast du die Panels dran ? links oder rechts?
> Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann
> nichts sinnvolles mehr bei der 01 Antwort.

Das sieht so aus wie bei meinem HM-1500. Allerdings würde ich nur Spalte 
N als Spannung interpretieren.
- Spalte N: 26,2V
- Spalte O: 0,02A
- Spalte P: 0,03A
- Spalte Q: 0,6W (26,2 x 0,02 mit Rundungsfehlern?)
- Spalte R: 0,9W (26,2 x 0,03 mit Rundungsfehlern?)

[Heinz R. (heijz)]

Chris A. schrieb:
> ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber
> keine Leistung.
>
> An welchen Anschlüssen hast du die Panels dran ? links oder rechts?
> Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann
> nichts sinnvolles mehr bei der 01 Antwort.

Hallo Chris,

je ein Panel aktuell pro Seite

Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt
Ich messe an ihm ca. 23V, ca. 10mA

Das andere Panel hat aktuell ca. 29V, ca. 1 A

Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte 
ungefähr passen?

Hast Du DIr eine Excel-Vorlage gebaut?

Viele Grüße

[Chris A. (cherio7)]

> Hallo Chris,
>
> je ein Panel aktuell pro Seite
>
> Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt
> Ich messe an ihm ca. 23V, ca. 10mA
>
> Das andere Panel hat aktuell ca. 29V, ca. 1 A
>
> Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte
> ungefähr passen?
>
> Hast Du DIr eine Excel-Vorlage gebaut?
>
> Viele Grüße

Hi Heinz,

ich hab das hier verwendet:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Lars B. (docbmuc)]

Hallo zusammen,

endlich habe ich meinen WR HM-700 bekommen, läuft auch, aber antwortet 
nicht. grmpf

Ich habe sowohl eigene Entwicklungen als auch adaptierte Sniffer am 
Arduino Mega2560 erfolglos versucht. Zudem widersprechen sich aktuell 
die Aussagen bzgl. der nötigen Seriennummern-Bytes etwas:

Martin P. schrieb:
> Heinz R. schrieb:
> Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die
> Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann
> trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von
> Links nach rechts ein ... das 5. byte muss 01 sein.

In der (ursprünglichen) github-Doku von Petersilie heisst es:
> Hier werden 4-Byte-Adressen verwendet, die direkt aus den letzten 8 Stellen der 
Seriennummer des Wechselrichters bzw. der DTU gewonnen werden...

Verwirrung... ;-)
Sind es nun die ersten 4 oder die letzten 4? - Ich nehme mal an, es sind 
die letzten 4 BCD Bytes der Seriennummer.
Jetzt ist noch die Frage, wie rum die Dinger in das Define rein müssen.
MSB oder LSB neben der abschließenden 0x01?
Laut Doku würde ich mal annehmen, dass das MSB daneben kommt.
Also z.B. bei WR Serno. 11 41 74 60 84 85:
#define WR1_RADIO_ID ((uint64_t)0x8584607401ULL)


Ich habe beide Varianten schon getestet, die PA settings sowie SPI speed 
rauf und runter genudelt. - Nix geht... :-(
Config und erweiterte Ausgabe bei mir wie folgt - ich sende nur das 80er 
Telegramm:

Radio 1:
SPI Speedz  = 1 Mhz
STATUS    = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1  = 0xdeadbeef01 0x2888817201
RX_ADDR_P2-5  = 0xc3 0xc4 0xc5 0xc6
TX_ADDR    = 0xdeadbeef01
RX_PW_P0-6  = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA    = 0x00
EN_RXADDR  = 0x02
RF_CH    = 0x03
RF_SETUP  = 0x23
CONFIG    = 0x37
DYNPD/FEATURE  = 0x00 0x00
Data Rate  = 250 KBPS
Model    = nRF24L01+
CRC Length  = Disabled
PA Power  = PA_LOW
ARC    = 15

Send... CH40 157460848572818828800B00623C8EA30000000500000000375EC7 
Dest: 0174608485    WR1 TX error! 288828 37640
Send... CH40 157460848572818828800B00623C8EA5000000050000000097754A 
Dest: 0174608485    WR1 TX error! 2488380 37700

usw.

Achja: Ich habe das lustige PA-Modul mit externer Antenne, das hängt 
über den mitgelieferten LDO Adapter am Arduino 2560 folgendermaßen:

VCC->5V,
GND->GND,
SCK->52,
MI->50,
MO->51,
IRQ->2,
CE->7,
CSN->8

IMHO sollte das passen.

Was übersehe ich? Hat irgendjemand einen heissen Tipp?

Danke für die Geduld,
Lars

[Martin P. (mpolak77)]

Lars B. schrieb:
> Also z.B. bei WR Serno. 11 41 74 60 84 85:
> #define WR1_RADIO_ID ((uint64_t)0x8584607401ULL)

ja genau so - sorry für die Verwirrung!

[Lars B. (docbmuc)]

Hi Martin,

danke für die Bestätigung. - Ich suche dann mal weiter, wo der Hund 
begraben liegt... ;-)

***UPDATE ***
Habe den begrabenen Hund gefunden! :-) :-) :-)

Der Receive-Interrupt im Arduino-Code wurde nicht aktiviert/deaktiviert.
Die Routine wird zwar über das attach eingehängt, aber die existierenden 
Defines
#define DISABLE_EINT EIMSK = 0x00
#define ENABLE_EINT EIMSK = 0x01
lassen den klassischen Arduino eher kalt. ;-)

Ich habs mal durch folgendes ersetzt und dann klappert das auch:
#define DISABLE_EINT   noInterrupts();
#define ENABLE_EINT    interrupts();

Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe 
anbei... :)

Cheers,
Lars

[Martin P. (mpolak77)]

Lars B. schrieb:
> Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe
> anbei... :)

ja das mit den Interrupts musste ich für den ESP auch so machen ...

Ich lese ja auch einen HM-700 (und einen HM-350) aus und habe 
mittlerweile den von mir auf ESP angepassten NF24Send_Rcv Code auch um 
das parsing/printing und MQTT publishing erweitert ... bei der 
Unterscheidung der Geräte hapert es noch ein wenig ... und die 
Temperatur finde ich beim HM-700 nicht an der Stelle wie hier im Thread 
beschrieben.

Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch 
gerne ...

[Thomas B. (tbnobody)]

Hallo,

ich wurde gerade hierauf verwiesen:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fgzll_02_user_guide.html&cp=4_1_0_5_0

Kann es sein das dieses Gazell unser Channel hopping ist?
Auch wenn sich oben genannte Doku auf einen nRF52833 bezieht steht bei 
den Features: Backward compatible with legacy nRF24L Series Gazell.

[Jan-Jonas S. (janjonas_s)]

Hallo,

hier scheint wohl so eine Implementierung des gzll Protokolls zu sein
https://github.com/wangdong/cpod/blob/master/lib/nrf24/gazell/common/gzll.c
Leider kann das wohl die nRF24 lib nicht.

[Heinz R. (heijz)]

Martin P. schrieb:
> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
> gerne ...

ch bekunde Interesse :-)

Habe allerdings einen HM-1200

[Lars B. (docbmuc)]

Hi Thomas,

guter Hinweis mit dem Gazell-Protokoll... das hatte ich schon 
erfolgreich verdrängt. ;-)

Das Kommunikationsschema von Gazell sieht aber IMHO anders aus. Das ist 
Device-getriggert und der Host lauscht erstmal nur und antwortet auf 
Anfragen der Devices.

Insofern müssten die HMs von sich aus auf einem Anker-Kanal "ungefragt" 
vor sich hin senden.
Das tun sie aber nach aktuellem Kenntnisstand nicht, sondern antworten 
auf Anfragen des Hosts. Das Kommunikationsschema stellt sich für mich 
eher "klassisch" dar, also Anfrage Host->Device, dann Antwort 
Device->Host.
Die max. Anzahl der für die DTUs spezifizierten "Solarmodule" ist mit 99 
auch deutlich höher, als die für Gazell maximal spezifizierten 8 
Teilnehmer.

...aber ich kann mich ja auch irren... ;-)

[lpb (Gast)]

Hallo zusammen,

ich habe auch ein wenig an meinem HM600 gelauscht.
Ich kann die Informationen für den HM600 wie im Anhang bestätigen.

Ich hoffe, das hilft dem einen oder anderen weiter.
Vielen Dank für die tollen Beiträge hier!

[lpb (Gast)]

Nanu, kein Anhang? Neuer Versuch...

[1N 4. (1n4148)]

Martin P. schrieb:
> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
> gerne ...

Ja, da hätten mein HM-600 und ich auch Interesse :)

[Carsten B. (carstenb)]

lpb schrieb:
> Hallo zusammen,
>
> ich habe auch ein wenig an meinem HM600 gelauscht.
> Ich kann die Informationen für den HM600 wie im Anhang bestätigen.

Ich habe auch weiter gelauscht und die 01-Message kann ich so bestätigen 
an Hand meiner Daten.

Bei der 02-Message bin ich unsicher, was Gesamt-Ertrag und Wochenertrag 
angeht. Der letzte Wert ist die AC-Leistung und nicht wie Samstag noch 
von mir vermutet die Temperatur. Wenn ich mir die HM-Software ansehe, 
würde ich aber denken, das irgendwo noch die Temperatur versteckt ist...

[Carsten B. (carstenb)]

Martin P. schrieb:
> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
> gerne ...
Da hätte ich großes Interesse :-)

[Martin P. (mpolak77)]

Carsten B. schrieb:
> Martin P. schrieb:
>> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
>> gerne ...
> Da hätte ich großes Interesse :-)

Ok - ein Zipfile gibt es hier:

https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0

Hab leider gerade keine andere Möglichkeit den Code zu sharen (Handy)

Disclaimer: das Original ist nicht von mir - ich habe nur Code und 
Wissen aus dem Forum kombiniert, so wie es für
mich nützlich ist.

Es ist auch noch nicht besonders ausführlich getestet. Es unterstützt 
mehrere Wechselrichter, denen man in der Definition einen Namen geben 
kann um sie an der Konsole/Mqtt unterscheidbar zu machen. Das Mqtt topic 
und Format hab ich mal so gewählt, wie es zu meinem
Homesetup passt.

Was m.E. noch fehlt:
zB das Timing entspannen
Nur requests schicken, in der Nacht deepsleep
Und vieles mehr
Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe 
leider nur die Basic DTU und kann daher die Nachrichten nicht loggen ….

[Carsten B. (carstenb)]

Martin P. schrieb:
> Carsten B. schrieb:
>> Martin P. schrieb:
>>> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
>>> gerne ...
>> Da hätte ich großes Interesse :-)
>
> Ok - ein Zipfile gibt es hier:

> Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe
> leider nur die Basic DTU und kann daher die Nachrichten nicht loggen ….

Danke, sehr cool. Ich hoffe, ich finde morgen die Zeit es zu 
installieren. Das Thema Leistungsbegrenzung interessiert mich auch sehr. 
Gemeinsam mit mehreren kommen wir da sicher weiter.

[Jan-Jonas S. (janjonas_s)]

Hallo,

ich vermute die Inverter-Temperatur beim HM600 im cmd 131 (83), byte 4.

2022-04-04T11:23:54.973594Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=84, uk3=1000, uk4=393, uk5=1757, uk6=47334
2022-04-04T11:26:28.900800Z MSG src=72220143, dst=72220143, cmd=131,   uk1=1, uk2=36, uk3=1000, uk4=397, uk5=1765, uk6=13181
2022-04-04T12:16:51.839332Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=98, uk3=1000, uk4=460, uk5=1998, uk6=53222
2022-04-04T14:03:09.826004Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=59, uk3=1000, uk4=516, uk5=2492, uk6=12253
2022-04-04T14:36:51.087562Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=46, uk3=1000, uk4=496, uk5=2642, uk6=42061
2022-04-04T17:20:05.465478Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=0, uk3=0, uk4=327, uk5=3372, uk6=17290
2022-04-04T17:20:33.714355Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=0, uk3=0, uk4=327, uk5=3375, uk6=25778

Quelle: Relevanter Log-Output mit 
https://github.com/Sprinterfreak/ahoy/tree/dev

[Jan-Jonas S. (janjonas_s)]

Hallo,

habe gerade mal ein poormans Channel hopping über die bekannten Kanäle 
beim empfangen gefrickelt.
Siehe da: Mehr erfolgreiche Übertragungen als Fehlschläge.
Also wir reden jetzt von mindestens 3-4 vollständigen Datensätzen pro 
Minute.

Ich habe ein HM600 und bekomme cmd=1,2,131 nun etwa 4x/Minute.

https://github.com/Sprinterfreak/ahoy/commit/86715ac116188f27247d2beb65fe0f3a39a2eeab

[Hubi (Gast)]

Hallo lpb
so ganz passen die Werte für Week und Total bei mir nicht. Ich notiere 
mir jetzt schon ein paar Tage day1 und day2 power (Summe ist 
Gesamtleistung am Tag). Die Summe der letzten 5 Tage + aktuell ergeben 
bei mir 10.000, aber im Telegramm gibt das week power nur 5102 (Stand 
jetzt) aus.
Da meine Anlage seit 1.1.2022 läuft, schätze ich mal eine Gesamtleistung 
von ca 100.000 Wh, im HM-Telegramm stehen aber 68.990 Wh. Scheint mir 
etwas wenig zu sein.
Bist du dir mit den Daten sicher?

[Thomas B. (tbnobody)]

Jan-Jonas S. schrieb:
> habe gerade mal ein poormans Channel hopping über die bekannten Kanäle
> beim empfangen gefrickelt.

Also ich kann bestätigen, dass mit der Modifikation von Jan teilweise 
mehr Pakete empfangen werden. Also z.B. auf eine einzige 0x80 Anfrage 
kam folgendes:

2022-04-05 18:14:04.512796 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 01 00 01 01 36 00 08 00 08 00 1a 00 18 00 01 54 76 83
2022-04-05 18:14:04.559483 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 02 00 01 57 4e 00 b5 00 ac 01 33 00 07 00 02 00 17 b6
2022-04-05 18:14:04.595240 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 03 00 05 00 01 5e 4f 00 00 02 4e 00 a9 00 06 08 dd b5
2022-04-05 18:14:04.641578 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 84 13 89 00 49 00 c9 00 03 01 57 00 55 00 07 39 23 16

Ein 0x84 hatte ich vorher noch nie gesehen. Man achte auch auf die 
verschiedenen Kanäle.

[Thomas B. (tbnobody)]

Ich hatte gerade auch die Möglichkeit von einem HM-600 eine Matrix über 
die Empfangenen Message ID's vs. Channel Number zu bilden (siehe 
Anhang).
1er und 2er scheinen nur auf Kanal 3 zu kommen. Ob das nun Zufall ist, 
oder Jans Implementierung so geschuldet ist (das zufällig durchs Timing 
immer die 1er und 2er auf Channel 3 erscheinen und andere ggf. verworfen 
werden) kann ich erstmal nicht sagen.
Also ich muss sagen, ich hab keine Ahnung von Channel Hopping 
Algorithmen usw... ich stochere hier nur etwas in den Daten.

[isnoAhoy (Gast)]

Martin G. schrieb:
> Mal zwischendurch ein Themenwechsel zu "Channel Hopping":
>
> Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen
> "Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im
> Anhang.
>
> Da zeichnet sich klar ab, dass
>
> * die "0x01"-Nachrichten immer nach ca. 18 ms eingehen,
> * die "0x02"-Antworten immer nach ca. 67 ms und
> * die "0x83"-Antworten immer nach ca. 116 ms.
>
> Das ist für "Anfrage auf Kanal 40, Antwort auf Kanal 3".

Das würde doch dafür sprechen das Channel Hopping mal zufällig zu 
gestalten. Aktuell fängt die Implementierung von Jan-Jonas ja immer mit 
Kanal 3 an und macht dann mit den Kanälen 23, 61, 75 immer die selbe 
Reihe durch. Bei einer zufälligen Abfolge könnte man auch statistische 
Auswertungen der Daten vornhemen. So wie der Code aktuell ist bleibt die 
Präferenz für die schnellen Antworten auf Kanal 3 wie von Martin / 
Petersilie ausgewertet.

[Jan-Jonas S. (janjonas_s)]

Hallo,

bekomme jetzt bei meinem HM-600 nahezu sekündlich alle Daten.
https://github.com/Sprinterfreak/ahoy/tree/dev

Habe das Channel Hopping nochmal überarbeitet, sodass der RX Start 
Channel mit jeder Transaktion rotiert. Das empfängt jetzt auch cmd=1,2 
auf verschiedenen Channeln.

Nachdem ich AutoAck mal auf True gesetzt habe findet die Kommunikation 
jetzt nahezu zuverlässig statt.

An jemanden mit ner DTU und Sniffer:
Kann mal wer versuchen herauszufinden wie man das "Zero Export 
Control"-Feature setzt?
Laut Bedienungsanleitung kann der HM-600 ja auch noch Fehlercodes 
ausgeben. Eine Tabelle ist in der Bedienungsanleitung, jedoch finde ich 
keine halbwegs passenden Werte in den bisher bekannten Datensätzen.

[isnoAhoy (Gast)]

In der nRF24L01+ Product Specs findet sich noch der folgende Absatz auf 
Seite 34 von 78: 
https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf?cp=12_4_0_0

> Two packet loss counters are incremented each time a packet is lost, ARC_CNT and 
PLOS_CNT in the
> OBSERVE_TX register. The ARC_CNT counts the number of retransmissions for the 
current transaction.
> You reset ARC_CNT by initiating a new transaction. The PLOS_CNT counts the total 
number of retrans-
> missions since the last channel change. You reset PLOS_CNT by writing to the 
RF_CH register. It is possi-
> ble to use the information in the OBSERVE_TX register to make an overall 
assessment of the channel
> quality.

Das würde dafür sprechen, daß es bei Übertragungsfehlern auf einem der 
bekannten Kanäle eine Retransmission auf einem der anderen Kanäle gibt 
um ggf. Störungen durch WLAN, PCM oder andere Funkteilnehmer 
auszugleichen. Offenbar scheint das "Channel-Hopping" ja auch speziell 
im Zusammenhang mit den vermuteten "Fehlermeldungen" 0x83 (und evtl. 
0x81 / 0x82 ?) in Verbindung zu stehen.

Oder täuscht mich da mein Eindruck ?

[Jan-Jonas S. (janjonas_s)]

Hi,
habe ein HM600;

0x83 (cmd=131) ist bei mir ein Werteblock, keine Fehlermeldung
  Hier stecken vmtl. load%, Temperatur, Status, Statuswechselzähler 
drin.
0x81 (cmd=129) ordne ich den Fehlern zu.
  Das kommt zurück, wenn man Müll mit korrekter CRC hin schickt.

https://www.alpha-solar.info/media/Dokumente/Wechselrichter/Hoymiles%20HM/Deutsch/Bedienungsanleitungen/HM-600%20%20HM-800%20Bedienungsanleitung.pdf
Alarmcode 129 deckt sich u.A. auch mit der Fehlertabelle in der 
Bedienungsanleitung vom HM-600. "Softwarefehlercode 129". Zufall?
Dann könnte der WR ja prinziepiell auch die anderen Alarmcodes senden. 
Dafür bräuchte es aber eine Art Session zwischen der DTU und dem WR. 
Weil ich habe noch keine unbekannten Pakete rein purzeln sehen, wenn ich 
z.B. das Netz abtrenne. Das müsste dann laut Anleitung 0x93/147 oder 
0x94/148 sein

[B. G. (golf2010)]

zu den genutzten Frequenzen.
Bei meinem HM-600 ist es immer so:
Wenn ich ein 80 Telegramm sende auf 2403, dann antwortet der WR mit den 
Antworten 01,02,83  auf den möglichen Frequenzen 2423,2440,2461 MHz.
also bei TX 2403, Antworten auf 2423,2440,2461
     bei TX 2423, Antworten auf 2403,2440,2475
     bei TX 2440, Antworten auf 2403,2423,2475
     bei TX 2461, Antworten auf 2403,2423,2475
     bei TX 2475, Antworten auf 2403,2423,2440
Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt 
man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie 
empfangen.

[martin (Gast)]

B. G. schrieb:
> Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt
> man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie
> empfangen.

Hallo BG,
hast du es mal mit einer 0x80 0x11 Anfrage versucht? Da dürften andere 
Daten zurückkommen, siehe hier:

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[B. G. (golf2010)]

martin schrieb:
> Hallo BG,
> hast du es mal mit einer 0x80 0x11 Anfrage versucht?

Das muß ich mal testen.
Anbei noch ein jpg , NRF sendete auf 2475. HM-600 antwortete auf 
2440,2423,2423 (3. Antwort 83 nicht mehr auf jpg)
Man sieht, wann ich beim Scan auf die Frequenz kam und den Block 
quittiert habe.

[Oliver F. (of22)]

Nach einiger Zeit hatte ich auch noch einmal Gelegenheit mich mit der 
Materie zu beschäftigen. Momentan bin ich noch der Meinung, dass das 
Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein 
Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen.
Auf den unterschiedlichen Kanälen kommen auf die 0x80 Anfrage immer 3 
verschiedene Antworten mit verschiedenen Ids, wenn Sie nicht durch 
irgendwelche Übertragungsprobleme gestört werden.
Ich empfange die Ids 0x01 bis 0x0B. Siehe beigefügter Beispiel Dump.
Da ist mit Sicherheit auch etwas dabei für Inverter mit mehr als 2 MPP 
Trackern.

Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt.
https://github.com/OFreddy/hm_poll
Eventuell kann man das nutzen und für verschiedene Platformen anpassen 
um solche Probleme zu vermeiden, dass bei einem nano z.B. andere 
Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu 
einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der 
hm_config_x.h geschehen.
Wer dort erweitern möchte ist herzlich willkommen.

Momentan unterstützt die Library 4 Inverter Instanzen, ist aber 
erweiterbar.
Das Channel Hopping kann noch optimiert werden.
Geplant habe ich eine Art Callback Funktion, bei der die Library 
empfangene gültige Pakete an die Applikation signalisiert. Diese könnten 
dann von der Applikation nach Datenpunkten zerlegt werden.

[B. G. (golf2010)]

martin schrieb:
> hast du es mal mit einer 0x80 0x11 Anfrage versucht?

Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85 
zurück, bei 800B 01,02,83

[Jan-Jonas S. (janjonas_s)]

Hallo Martin,

80 0b ist das "Zeit setzen" was mit normalen Werten antwortet
80 11 liefert bei mir cmd=129, Error
80 03 liefert ein ganzen Haufen, siehe Log.
u.A. cmd=1-7, wobei die Werte in 1 und 2 nicht identisch sind wie bei 0b

Hab das mal durchprobiert.
80 0b, 0c, 0d sind sehr ähnlich aber Werte scheinbar mit einem falschen 
Faktor.

Das ganze Tageslog muss ich mal aufarbeiten. Da ist auf jeden Fall 
einiges drin, was neu ist und bisher keinen Sinn ergibt, wenn man mit 
den Anfragen spielt und keinen Fehler schmeißt.

[Martin G. (petersilie)]

Oliver F. schrieb:
> Momentan bin ich noch der Meinung, dass das
> Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein
> Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen.

Das mit dem "Gießkannenprinzip" ist bisher auch mein Eindruck: 
Vielleicht so etwas in diese Richtung:

- Die "DTU" sendet eine Anfrage auf mehreren Kanälen "zeitlich dicht 
hintereinander".
- Die WR hören permanent auf einem der Kanäle, und schalten nur mal 
einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hören.

- Die WR antworten auf mehreren Kanälen "zeitlich dicht hintereinander"
- Die DTU hört permanent auf einem der Kanäle, und schaltet nur mal 
einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hört.

Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen Empfänger 
scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes 
Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt.

Hier wäre es toll, wenn jemand mit einem SDR-Sniffer und DTU derartige 
Muster beobachten könnte. Ich meine, @tbnobody hat sowas zumindest 
ansatzweise mal gesehen?

Leider ist meine DTU noch immer nicht geliefert worden - und viel 
Hoffnung mache ich mir nicht mehr...

[Jan-Jonas S. (janjonas_s)]

Martin G. schrieb:
> Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen *Empfänger*
> scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes
> Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt.
Das ist das, was ahoy.py aus meinem Fork sieht.

> Ich meine, @tbnobody hat sowas zumindest ansatzweise mal gesehen?
Ja, in meinen Logs. Heute Nacht nach Einspeiseende werden meine Logs 
wieder untersucht. Mit Sicherheit. Mit entsprechenden Änderungen in 
ahoy.py, die genau das dämliche Verhalten mit verbessertem hopping-code 
zeigen, was ich so den Tag über bereits beobachtet habe.

[B. G. (golf2010)]

Das glaube ich eher nicht.
Ich meine, die WR scannen die wenigen genutzten Kanäle durch. Durch das 
Retransmit erkennen sie immer die Nachricht. Ebenso können die DTUs oder 
eigene NRFs durch das Scannen sicher alle Telegramme empfangen. So hab 
ich das jedenfalls bei mir.
Wenn ich auf einer anderen Frequenz sende, kommen immer gleich die 
Antworten.
Ebenso ist es beim Empfang der Antworten.

[Jan-Jonas S. (janjonas_s)]

Das ist bei mir (HM600) eben anders.
Bei TX auf einem anderen Kanal als 40 kommt nichts. Nie.
Wenn ich nur auf einem fixen Kanal, auch über die Zeit empfange, bekomme 
ich nur hin und wieder mal ein einzelnes Paket. Wenn ich nach dem Tx 
über die Kanäle scanne, bekomme ich recht zuverlässig alle Pakete. Jedes 
mal auf anderen Kanälen. Auch nach einem Tx die Antwortpakete 
nacheinander auf unterschiedlichen Kanälen.

[Jan-Jonas S. (janjonas_s)]

Der Code, der das generiert ist hier:
https://github.com/Sprinterfreak/ahoy/blob/dev/tools/rpi/ahoy.py

Am Ende habe ich ein wenig mit den Tx-Daten gespielt, da sind sicher 
interessante Rohdaten dabei.

[Oliver F. (of22)]

Mein Testprogramm funktioniert jetzt so, dass die simulierte DTU die 
Kanäle durchwechselt und dann auf einem der Kanäle lauscht.
Empfängt es eine Antwort, so bleibt es auf dem Sendekanal und wechselt 
nur noch die Empfangskanäle durch. Dabei empfängt es immer auf einem der 
anderen Kanäle bis zu 3 verschiedene Frames. Siehe Screenshot.
Wechselt auch bei jedem mal auch der Sendekanal kommen deutlich weniger 
Antworten.

Voraussetzung ist allerdings, dass der Request mit 0x80 0x11 beginnt. 
Verwende ich die 0x80 0x0B kommen nur 0x01, 0x02 und 0x83 Antworten.

[Martin G. (petersilie)]

@janjonas_s - Wow! Phänomenal! Mit Deinen Channel-Hopping-Versuchen 
kommen auf jeden Fall wesentlich häufigere Antworten. Und ein paar neue 
Feldbedeutungen hast Du auch eingepflegt.

Ich hab Deine Commits mal gemerged, danke!

Hatte noch ein paar lokale Änderungen, die sind jetzt auch drin. Die 
JSON-Daten enthalten jetzt alle Infos, die wir bisher erarbeitet haben.

* https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py

[Jan-Jonas S. (janjonas_s)]

Hallo Martin,

danke. So ganz "richtig" kann das alles noch nicht sein. Speziell weil 
wohl  z.B. cmd=1,2,3 nicht immer den selben Inhalt haben. Dies ist wohl 
noch zwischen Modellen und je nachdem was man anfragt unterschiedlich. 
Siehe z.B. mein ahoy.log.gz um 17:46 rum. Da habe ich mit den 
Anfragedaten gespielt.

Bisher habe ich damit allerdings mit meinem HM600 die höchste 
Wahrscheinlichkeit erziehlt auf eine Anfrage möglichst alle Antworten zu 
bekommen.

Ich habe die ahoy.conf erweitert, sodass man da seine DTU-, Inverter 
serial und broker eintragen kann. Wenn man die außerhalb des Repos 
lagert und die ahoy.py vom Ort der ahoy.conf startet, geht das Updaten 
leichter.

[Abdul K. (ehydra)]

So langsam wird mir klar, warum ich auf dem WLAN-Band so einen hohen 
Hintergrundstörnebel gemessen habe. Echt bizarr.

[Martin P. (mpolak77)]

also ich habe die ESP8266 Version jetzt auch soweit, dass man sie wo 
headless parken könnte (musste auch einen 100uF und Dipol-Antenne an die 
nrf24l01 Platine löten, um beide WR empfangen zu können) .. geschickt 
werden Messwerte per Mqtt und gelogged wird per rsyslog. Sonnenaufgang 
und Untergang wird berechnet um so über Nacht in DeepSleep gehen zu 
können.

Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht 
ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste, 
bekomme ich:

Vom HM700:
viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 
mit Temp (hier scheint der Wert auch nicht zu stimmen)

Vom HM350:
Bekomme ich nur 01 DC Daten und etwa halb so oft wie vom HM700

Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der 
Python Version breiter nach dem HM350 zu loggen.

[Oliver F. (of22)]

Martin P. schrieb:
> Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der
> Python Version breiter nach dem HM350 zu loggen.

Hi.
Könntest Du mal die Bibliothek aus
https://github.com/OFreddy/hm_poll
ausprobieren? Es würde mich interessieren welche Antworen von anderen WR 
kommen. Ich kann nur mit HM-600 loggen.
Bei Fragen einfach melden.

[Jan-Jonas S. (janjonas_s)]

Martin P. schrieb:
> Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht
> ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste,
> bekomme ich:
Das vermute ich, weil meine Versuche da eher blindes Huhn spielen. Wenn 
da tatsächlich Gazell, oder in Teilen Gazell, dahinter steckt wären die 
Channel vorhersagbar.

> Vom HM700:
> viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131
> mit Temp (hier scheint der Wert auch nicht zu stimmen)
Das kann gut sein. Habe ich ja gestern bei meinem HM600 auch provoziert, 
als ich das byte nach 0x80 im "Zeit setzen" verändert habe. Das hat die 
Werte im cmd=2,131 um irgendwas faktorisiert. Gut möglich, dass da jeder 
WR einen eigenen Requests braucht. Sicher jedenfalls sein eigenes Schema 
hat wie die Payload(s) aufgebaut ist. Glaube Thomas frickelt schon an 
Modellbezogenen Dekodern?

Thomas hat gestern aus meinen Daten auch komische Timing-Effekte 
extrapoliert Sah aus als ob über die Zeit (range unbekannt) mit meinem 
Hopping Werte nach einem Muster mal mehr und weniger werden.

> Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der
> Python Version breiter nach dem HM350 zu loggen.
Mein Gedanke war auch schon 5 nRF's als reinen Receiver, je einen Pro 
Kanal, laufen zu lassen. Ich hab leider nicht die Möglichkeit ein 
Spektrum im Gigahertz-Bereich aufzuzeichnen.

[Martin P. (mpolak77)]

Oliver F. schrieb:
> Hi.
> Könntest Du mal die Bibliothek aus
> https://github.com/OFreddy/hm_poll
> ausprobieren? Es würde mich interessieren welche Antworen von anderen WR
> kommen. Ich kann nur mit HM-600 loggen.

Hallo Oliver,

anbei ein Scan von HM350 und HM700.

das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem 
Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC 
erscheinen schlüssig und passen auch zu den Shelly Werten.

[Oliver F. (of22)]

> Hallo Oliver,
>
> anbei ein Scan von HM350 und HM700.
>
> das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem
> Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC
> erscheinen schlüssig und passen auch zu den Shelly Werten.

Hallo Martin,
vielen Dank, super das Du das gemacht hast. Aber das verstehe ich nicht. 
Bei mir sieht das ganz anders aus. Ich erhalte eigentlich auf jede 
Anfrage eine Antwort von den Wechselrichtern.
Kann es sein, dass sie bei Dir nicht in Reichweite sind? Oder sind sie 
zu nahe? Du verwendest PA_HIGH. Ich hatte auch schon das Problem, dass 
das Verhalten schlechter wird, wenn die Sendeleistung zu hoch ist, oder 
die 3.3V Versorgung für die RF24 Module zu schlecht ist.

[Martin P. (mpolak77)]

ja leider sind meine beiden WR ein Stück voneinander entfernt.
Bei meinem 2. Board mit ESP8266 + Dipol Antenne (selbstgebaut) kommen 
auch wesentlich mehr Messages ... vielleicht kann der Spannungsregler am 
NodeMCU einfach mehr leisten, als der des Nano.

Wenn der Laptop wieder aufgeladen ist (anders geht es leider nicht, wo 
ich beide WR empfange) kann ich es ja nochmals mit dem Dipol Board und 
PA_LOW probieren.

Morgen sollte ich außerdem so ein Board mit PA + LNA bekommen.

[Martin G. (petersilie)]

Martin P. schrieb:
> Vom HM700:
> viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131
> mit Temp (hier scheint der Wert auch nicht zu stimmen)

Witzig, das deckt sich genau mit meiner Erfahrung (siehe 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?").

"Oft" 01, "seltener" 02, sehr selten 131.

Mysteriös. Aber wir sammeln eifrig weiter...

[Thomas B. (tbnobody)]

Hallo,

dank Jans Modifikation habe ich einen ganzen Tag aufgezeichnet und bei 
fast allen 0x80 vier Antworten bekommen. Dadurch konnte ich schon schon 
viele Felder identifizieren. Siehe Anhang. (Die #NV bitte ignorieren, 
die benötige ich zum Diagramme rendern)

Spalte F - G zeigen die Rohdaten. Spalte AH bis BA die bisher bekannten 
Felder. Vielleicht hilft es jemanden.

(Und DC1-4 sind bisher beliebig zugewiesen. Da müsste ich mal alle 
Panels bis auf eines abstecken und das genau machen)

[Thomas B. (tbnobody)]

Und ich glaube ich habe auch die Temperatur gefunden...

[Thomas B. (tbnobody)]

Und ich glaub ich hab den Power Faktor gefunden. Zumindest korreliert 
der Graph recht gut zu dem was der Gosund Zwischenstecker aufzeichnet 
(und im Grafana landet).

[Thomas B. (tbnobody)]

B. G. schrieb:
> martin schrieb:
>> hast du es mal mit einer 0x80 0x11 Anfrage versucht?
>
> Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85
> zurück, bei 800B 01,02,83

Hallo B. G.,

könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse 
nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere 
Pakete und Frequenzen interessieren.

[B. G. (golf2010)]

Thomas B. schrieb:
> könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse
> nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere
> Pakete und Frequenzen interessieren.

Das Bild vom 6.4. ist ja noch verfügbar.
Ich hab gerade nochmal so eine Aufnahme gemacht. Komischerweise sendet 
der HM-600 gerade andere Pakete.
Anbei der Frequenzverlauf über die Zeit und die empfangenen Pakete.

[B. G. (golf2010)]

nochmal eine kleine Aufnahme. Jetzt sendet der HM-600 wieder anders.
Aufnahme ist etwas schwach, aber man erkennt die Frequenzen noch.

[Thomas B. (tbnobody)]

Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig 
machen können. Die Port Zuordnung ist ggf. noch zu verifizieren.

In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen 
enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt 
zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der 
täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes 
gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem 
was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man 
summiert die letzten 3 Wochen).
Kann jemand ein ähnliches Phänomen beobachten?

[Mike (Gast)]

Thomas B. schrieb:
> Habe noch die Gesamtproduktion sowie die täglichen Counter
> ausfindig
> machen können. Die Port Zuordnung ist ggf. noch zu verifizieren.
>
> In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen
> enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt
> zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der
> täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes
> gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem
> was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man
> summiert die letzten 3 Wochen).
> Kann jemand ein ähnliches Phänomen beobachten?

Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in 
Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen 
später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt 
habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst.

[Thomas B. (tbnobody)]

Mike schrieb:
> Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in
> Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen
> später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt
> habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst.

Das ist wunderbar dass das so passt!

Ich habe eine ähnliche Tabelle auch für einen HM-600 erstellt. 
Vielleicht findet der ein oder andere darin noch Werte die er bisher 
noch nicht hat. (AC_I z.B.)

Die letzten 4 Bytes in der HM-600 0x83 Message sind im gleichen 
unbekannten Format wie die letzten 4 Bytes in der 0x84 Message des 
HM-1500 (letzte 4 Bytes ohne die letzte CRC)

[Mike (Gast)]

Thomas B. schrieb:

> Vielleicht findet der ein oder andere darin noch Werte die er bisher
> noch nicht hat. (AC_I z.B.)

Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw. 
die S-Miles Enduser App zeigt keine an.

[Thomas B. (tbnobody)]

Mike schrieb:
> Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw.
> die S-Miles Enduser App zeigt keine an.

Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die 
entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese 
entsprechen exakt der Leistung (P) durch der Spannung (V).


[1] 
https://www.mikrocontroller.net/attachment/553106/HM-1500_20220408_01.png
[2] 
https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png

[Mike (Gast)]

Desweiteren kann die Energie (Wh) und die Leistung (W) jeweis für 
Tag/Monat/Jahr/Gesamt angezeigt werden.

Jedes PV Modul hat auch eine Ortangabe (0,0 / 0,1 / 0,2 / 0,3)

[Martin P. (mpolak77)]

Thomas B. schrieb:
> Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die
> entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese
> entsprechen exakt der Leistung (P) durch der Spannung (V).

Also ich kann die HM-600 Decodierung auch für den HM-700 bestätigen.

Beim HM-350 bin ich auch etwas weiter gekommen:
Da sind die DC Daten im 0x1:
DC_V, DC_A, DC_P (and der selben Stelle wie bei HM600 .. der erste byte 
ist 10 und das letzte ist 0.

und AC Daten kommen in 0x82:
2byte Frequenz /100
2 byte Power /10
2 byte u1 (entweder 1 oder 0)
2 byte Strom /100
2 byte u2 (1000 dezimal)
... die restlichen Bytes geben für mich noch keinen Sinn. Spannung fehlt

Mit dem NRF24Sniff code, der TimePacket, gefolgt von 0x81,0x80,0x82 
Pakete schickt, bekomme ich vom HM-350 sehr oft mit einem 0x81? Das ist 
doch Command-Error?
Schicke ich nur das TimePacket, kommen nur die 01/02/82 zurück

[Martin P. (mpolak77)]

Thomas B. schrieb:
> Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig
> machen können. Die Port Zuordnung ist ggf. noch zu verifizieren.

Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die 
Tagesleistung pro Eingang sind?

Das ist nämliche meine Theorie bei der Auswertung des HM-700 .... die 
Werte sind mir zu ähnlich (und wir hatten sehr wechselhaftes Wetter)

[Martin P. (mpolak77)]

Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut)

01:
2bytes unbekannt "1"
2bytes dc_volt  / 10
2bytes dc_amps  / 100
2bytes dc_power / 10
2bytes unbekannt "0"
2bytes Total_w
2bytes Daily_w
2bytes ac_volt / 10

82:
2bytes ac_freq / 100
2bytes ac_power / 10
2byte  unbekannt "0"
2bytes ac_current / 100
2byte  unbekannt  "1000" vielleicht /10 Power Factor in %?
2bytes temp / 10
2bytes unbekannt ansteigend
2bytes random

[Mag C. (magcode)]

Oliver F. schrieb:

> Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt.
> https://github.com/OFreddy/hm_poll
> Eventuell kann man das nutzen und für verschiedene Platformen anpassen
> um solche Probleme zu vermeiden, dass bei einem nano z.B. andere
> Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu
> einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der
> hm_config_x.h geschehen.
> Wer dort erweitern möchte ist herzlich willkommen.

Hallo, super Arbeit! Das ist sehr sauber aufgesetzt.
Wäre es möglich die "Konfiguration via Seriell" zu unterstützen?

Mit Konfiguration meine ich: Die Seriennummer der/des Hoys. 
(Idealerweise nutzerfreundlich mit der "richtigen" Seriennummer.)
Weiterhin fände ich es gut, wenn man das Senden/Empfangen pausieren 
könnte sowie den Scanintervall einstellen könnte.
Ich werde selber mal bisschen probieren, aber an Deine C++ Skills komme 
ich sicher nicht ran :-)

[Thomas B. (tbnobody)]

Martin P. schrieb:
> Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die
> Tagesleistung pro Eingang sind?

Aehm ja, die  Day1 - 4 ist jeweils pro Port. Was ich noch nicht 
verfiziert habe ist die genaue Portzuordnung.

[Oliver F. (of22)]

Mag C. schrieb:
> Hallo, super Arbeit! Das ist sehr sauber aufgesetzt.
> Wäre es möglich die "Konfiguration via Seriell" zu unterstützen?

Hallo Mag.
Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas 
dauern, da ich in Osterurlaub fahre.
Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im 
EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du 
willst ja sicher nicht bei jedem Start erst die Seriennummern wieder 
schreiben, oder?

[Mag C. (magcode)]

Oliver F. schrieb:
> Mag C. schrieb:
>> Hallo, super Arbeit! Das ist sehr sauber aufgesetzt.
>> Wäre es möglich die "Konfiguration via Seriell" zu unterstützen?
>
> Hallo Mag.
> Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas
> dauern, da ich in Osterurlaub fahre.
> Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im
> EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du
> willst ja sicher nicht bei jedem Start erst die Seriennummern wieder
> schreiben, oder?

Ich nutze einen Arduino Nano.
Der Gedanke bei den Seriennummern war dass man anderen/nicht so 
versierten Hoymiles Nutzern vielleicht den Einstieg etwas leichter 
machen könnte.
Man braucht im Falle des Nano ja immer noch ein weiteres Stück Software 
um die Daten auszulesen, weiterzusenden oder zu speichern. (Etwas in der 
Art baue ich gerade.) Das könnte dann auch die Konfiguration übernehmen, 
also beim Starten die Seriennummer(n) übergeben und z.b. das Scannen 
Nachts abschalten.

Wenn man das Ganze standalone auf einem ESP aufbaut (Siehe oben 
"ESPHome" Beitrag von Marcel), dann würde es vielleicht ein UI geben, wo 
man die Seriennummern eintippt...

Kein Stress! Schönen Urlaub!

[Hubi (Gast)]

Moin
Das mit der Temperatur würde mich auch interessiern, das fehlt mir noch. 
Aufbauend auf der Nano-Variante von der ahoy-Seite habe ich mir eine 
ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt, 
die recht gut funzt (siehe Bild).
Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die 
Temp?

[Thomas B. (tbnobody)]

Hubi schrieb:
> Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die
> Temp?

Hallo Hubi,

siehe [1]. Die Temperatur sollte in Telegramm 0x83 in den Bytes 17 und 
18 (wenn man bei 1 zu zählen anfängt) stehen. Der dort enthaltene Wert 
muss durch 10 geteilt werden.



[1] 
https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png

[B. G. (golf2010)]

Hubi schrieb:
> 83er, aber wo ist da die
> Temp?

ich hab die aktuellen Werte beim HM-600 mal angehängt von heute.
Temperatur steigt an von 5,1 bis aktuell 26,6°

[lpb (Gast)]

Hallo,

für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert:
Message 0x83    Start  Bytes  Unit  Factor
--------------------------------------------------
Output Level 0-5?  10    2    -    x1
Grid Cuurent    12    2    A    x100
0 or 1000      14    2    -    -1    Status info?
Temperature      16    2    °C    x10

Das, was ich 'Output Level' nenne passt in den Stufen prinzipiell recht 
gut mit meiner Ausgangsleistung zusammen (siehe Anhang). Allerdings wird 
der Wert immer wieder Null, obwohl ich eine Ausgangsleistung habe - von 
daher passt das noch nicht ganz - aber eine bessere 
Beschreibung/Erklärung habe ich noch nicht gefunden :)

Die 0x02 Daten habe ich auch überarbeitet. Die total 1 und 2 steigen 
täglich mit den Werten daily 1 und 2, von daher sollte das jetzt so 
passen:
Message 0x2      Start  Bytes  Unit  Factor
--------------------------------------------------
Total Production 1  10    2    Wh    x1
Total Production 2  14    2    Wh    x1
Daily Production 1  16    2    Wh    x1
Daily Production 2  18    2    Wh    x1
Grid Voltage    20    2    V    x10
Grid Frequency    22    2    Hz    x100
Grid Power      24    2    W    x10

Ich vermute, dass die Hoymiles Cloud die anderen Werte für die Wochen- 
und Monatsdaten ermittelt. Ebenso könnte der Power Level in % aus der 
Maximal-Leistung des Inverters und der aktuellen Leistung von der Cloud 
berechnet werden.

Ich habe übrigens auch mit dem 'poor man rx channel switching' die 
Empfangsquote der Nachrichten deutlich erhöhen können (ich sende alle 6 
Sekunden eine Anfrage), aber ich erwische damit immer noch nicht alle, 
evtl ist dabei neben dem Timing auch noch die Reihenfolge wichtig...

Auf alle Fälle reicht das schon mal, um die wesentlichen Daten erfassen 
zu können, was ich sehr cool finde. Dafür ein großes Danke an alle, die 
hier so fleißig beigetragen haben!

[Herbert K. (avr-herbi)]

Hubi schrieb:
> Moin
> ... habe ich mir eine
> ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt,...

Hallo Hubi,
würdest Du mir Bitte Deinen Source zur Verfügung stellen ? Ich habe 8266 
und auch 32 hier. "C++" kann ich allerdings noch nicht. Mir würde das 
auch erst mal so reichen, wie Du es bisher hinbekommen hast.
Viele Grüße und einen schönen Sonntag wünscht Dir Herbert

[Daniel M. (Gast)]

Hallo meine Lieben Tüftler,

den ganzen Thread am Stück lesen war jetzt doch ne Menge Input, Respekt 
für eure Arbeit.

Ich habe zwar keinen Hoymiles, allerdings eine abgewandelte Variante: 
TSUN TSOL-M800.
Dieser hat die Seriennummer 104163500316
Passend dazu könnte der Hoymiles 1141... passen.

Datenstick und die große Basisstation sind identisch, auch in den 
Anleitungen zur Cloud ist Hoymiles drin.

Ich hätte einen Wemos D1 Mini hier, suche aber noch ein passendes NRF 
Modul.
Gefunden habe ich dieses hier: 
https://smile.amazon.de/DollaTek-NRF24L01-Funk-Transceiver-Modul-antistatischem-kompatibel/dp/B07PQPFTWZ/
Alternativ hat AZDelivery noch was im Sortiment. Wäre davon was richtig?

Auch den Sourcecode für einen ESP8266, den ich mit der Arduino-Software 
laden kann, wäre hilfreich.

Parallel habe ich noch 2 SG700MD hier, deren Protokoll ich aber schon 
habe und demnächst in NodeRed die Steuerung weiterbaue.
Die Databox habe ich schon versucht, jedoch ist keine Kommunikation mit 
dem TSUN möglich. Hier ist der Chip Beken bk2461 verbaut. Was in den WR 
drin ist, werde ich nochmal schauen, wenn ich die Folien der Silikonpads 
entferne.

Zur Software an sich: ich bevorzuge NodeRed und habe dazu einen Raspi am 
start. Hier könnte man auch wegen Python schauen, jedoch bin ich damit 
nie wirklich warm geworden. NodeRed finde ich da irgendwie angenehmer :)

Programmierskills habe ich keine, finde mich aber in Beispielcode 
zurecht. C/C++ ist mir weitgehend fremd, Python ist nicht so meins, 
Arduino geht, JS in NodeRed basics vorhanden.

Wäre cool, wenn ihr mir den Start erleichtert und wir den TSUN-Kunden 
einen ähnlichen Kompfort ermöglichen können :)

lg
Daniel

[Hubi (Gast)]

Hallo Herbert u. Daniel
anbei mein Fork von der ahoy-Seite. Läuft bei mir auf einem Wemos D1 
mini.
Was ist anzupassen:

in wifi.h :
 - SSID_PREFIX zur Suche des besten WLan; wenn auskommentiert, werden 
alle WLans in der Nähe beachtet
 - password für Wlan

in ModWebserver.h: die defines für Serverport und OTA-Zugriff

Einfach im Browser die IP eingeben, dann kommt die Tabelle wie oben.
Wenn man IP/data eingibt, kommen nur die Werte als Text, das ist meine 
einfache Datenschnittstelle, die ich dann mittels RasPi und cron 
abspeichere.

Ich benutze die Arduino IDE, also wer platform.io benutzt muss sich das 
anpassen.

Viel Spaß

[Herbert K. (avr-herbi)]

@Hubi,
Herzlichen Dank, die Beschäftigung die nächsten Stunden (Tage) ist nun 
gesichert  :-)
Einen schönen Abend wünsche ich Dir. Danke nochmals.

[Marcel A. (a-marcel)]

Hallo,

mithilfe von

> https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0

hab ich jetzt auch das Programm (mit Circular Buffer) auf meinem ESP32 
zum laufen bekommen. Danke Martin.

Heute lief das ganze mal ein paar Stunden und ich habe dazu mal ein paar 
Fragen.

Was genau ist denn dieses "// Packet control field - PID Packet 
identification" ?

// Packet control field - PID Packet identification
    uint8_t val = (p.packet[1] >> 1) & 0x03;
    Serial.print(val);
    Serial.print(F("  "));

Ebenfalls habe ich mal ein paar Debugausgaben mit hier rangehangen. Ich 
hab ja einen HM-400 und bekomme jetzt sehr viele dieser 0x81 Antworten. 
Wobei diese immer gleich per PID sind.

Und ich hatte sogar eine 0x82 dabei.

Weiß da schon jemand etwas mehr über dessen Bedeutung?

Marcel

[Martin P. (mpolak77)]

Der HM-400 ist ja auch ein Single Modul Inverter … wahrscheinlich wirst 
du da die Dekodierung für den HM-350 verwenden können, wie ich sie 
gestern gepostet habe.

Bei mir hat es auch gereicht nur das TimePacket zu schicken … damit 
liefern beide Wechselrichter (350 und 700) die relevanten Nachrichten.

Ich habe mal alles aus dem ursprünglichen Code geschmissen was ich nicht 
brauche und schicke die Dekodierung für beide WR per RSyslog und Mqtt 
raus (der ESP ist am Dachboden installiert, damit er beide WR sieht)

[Marcel A. (a-marcel)]

Hallo Martin,

die Werte des HM hatte ich selber schon rausgefunden und gepostet. Ich 
nutze die schon seit ein paar Wochen. Mit deinem Code konnte ich es 
jetzt aber auf diese Interrupt Methode und CircularBuffer umstellen und 
sehe jetzt die o.g. Daten. Würde schon gerne wissen was das ist und wozu 
das gut ist ;)

Ebenfalls wäre ich super dankbar, wenn jemand den Request von der DTU 
Pro rausfindet um die Einspeisung zu limitieren. Dann könnte ich 
demnächst auf Akkubetrieb mit Konstanteinspeisung umstellen.

Marcel

[Ziyat T. (toe_c)]

lpb schrieb:
> Hallo,
>
> für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert:
> Message 0x83    Start  Bytes  Unit  Factor
> --------------------------------------------------
> Output Level 0-5?  10    2    -    x1

hallo
dieser "output level" wert ist interessant!
in hoymiles modbus register 0xC001 oder 0x9D9D "Limit Active Power" wird 
der wert als % eingegeben, und zwar für MI series zwischen 10-100% für 
MH series 2-100% der wr-nennleistung.
die frage ist, wie passt das zusammen? oder gibt es ein anderer befehl 
zur limitierung?

Ziyat T.

[Herbert K. (avr-herbi)]

Manchmal sind es die kleinen Dinge dieser Welt, über die man sich freut 
:-)
Nach dem ich noch einige LIBs zu meiner Arduino: 1.8.13 hinzufügen 
mußte,
habe ich mich durch div. warnings gekämpft bis ich gefunden habe, was 
der Grund für "exit status 1" war:

wifi.h:76:54: error: ...

....

....

exit status 1

cannot pass objects of non-trivially-copyable type 'class String' 
through '...'

(Source von "Hubi" vom 10.04.2022 17:49)

in wifi.h habe ich dann diese Zeile auskommentiert:

//    DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID);

Keine Ahnung, warum da gemeckert wird. Dafür reichen meine Kenntnisse 
leider nicht aus.

Nun sehe ich die Webseite und muss jetzt noch die Verbindung zum 
nRF24L01+ Modul herstellen.
Ich freue mich jedenfalls, das ich schon mal bis hier hin gekommen bin. 
Danke "hubi"

[Hubi (Gast)]

Sorry, dass ich nicht erwähnt habe welche libs ich noch benutze 
(TimeLib, Pinger). Warum du den error mit exit status=1 in wifi.h hast 
ist mir unverständlich. Ich habe dort nur eine warning und mit
DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID.c_str());
ist die warning weg.

[Daniel R. (Gast)]

Ein herzliches DANKE an alle beteiligten für die großartige Arbeit 
bisher! Vielen Dank Hubi für deinen Arduino-Code für den D1 mini. Die 
Beobachtungen von Herbert K. kann ich bestätigen. Mit DEBUG_OUT.printf 
("Bestes Wifi unter: %s\n", SSID.c_str()); habe ich jedoch keinen Fehler 
mehr, sodass ich nun den Webserver erreiche. Tests mit dem HM-600 stehen 
noch aus...

[Martin P. (mpolak77)]

Marcel A. schrieb:
> Was genau ist denn dieses "// Packet control field - PID Packet
> identification" ?

Hallo Marcel,

https://www.sparkfun.com/datasheets/Wireless/Nordic/nRF24L01P_Product_Specification_1_0.pdf

Section 7.3.3.2
The 2 bit PID field is used to detect if the received packet is new or 
retransmitted. PID prevents the PRX device from presenting the same 
payload more than once to the receiving host MCU. The PID field is 
incremented at the TX side for each new packet received through the SPI. 
The PID and CRC fields are used by the PRX device to determine if a 
packet is retransmitted or new. When several data packets are lost on 
the link, the PID fields may become equal to the last received PID. If a 
packet has the same PID as the previous packet, nRF24L01+ compares the 
CRC sums from both packets. If the CRC sums are also equal, the last 
received packet is considered a copy of the previously received packet 
and discarded.

Was es allerdings in dem Code macht, hab ich nicht weiter nachgeforscht. 
Ich hab ja auch nur den Code von Github genommen und das stdinout / 
CircularBuffer Thema für den ESP aus dem Weg geschafft.

[Martin P. (mpolak77)]

Früher oder später wird auch eine etwas robustere Hardware interessant 
werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 
Combo gefunden:

http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge
Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein. 
Sollte als Ersatz-DTU aber auch seinen Dienst machen.

Hier noch etwas minimalistischer:

https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/

was mich bei letzterem allerdings verwundert, sind die fehlenden 
Widerstände, die der ESP12 normalerweise braucht.

[Thomas B. (tbnobody)]

Martin P. schrieb:
> Früher oder später wird auch eine etwas robustere Hardware interessant
> werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01
> Combo gefunden:

Mit einem ESP32 sähe das hier auch ganz nett aus:
https://www.openhardware.io/view/698/MY-ESP32-GW

[Herbert K. (avr-herbi)]

Wieder einen kleinen Schritt weiter  :-)  worüber ich mich freuen kann 
:-)
Dies habe ich aktualisiert. "....SSID.c_str());" Nun klappt das 
Compilieren auch damit  :-)
Durch Ändern der S/N meiner HM400 bekomme ich die ersten 3 Werte 
vermutlich sogar richtig :-)  wieder ein kleiner Schritt  :-)
Die restlichen Werte sind leider noch "0"  . Aber so weiss ich jetzt das 
die HW schon mal tut  :-)  ali-003.jpg hat nicht funktioniert. Mit 
ali-005.jpg klappt es so weit schon mal.

[Dietrich (Gast)]

Moin moin,

ich habe gerade mal probiert das Ganze für mein Wemos D1 zu compilieren. 
Bekomme das Programm auch hochgeladen und eine IP. Nur leider kann ich 
nicht auf die Website zugreifen. Pingen kann ich den D1, somit sollte 
die Netzwerkverbidung stehen.

Habe hier noch einen PiHole usw. laufen und somit nicht wirklich 
"Standard" Netzwerksettings. Kann es sein das sich der D1 in einer 
Whileschleife verläuft?
Kann ich das Debuggin irgendwie aktivieren? Habe schon DEBUG_SEND auf 1 
gesetzt, im Serial-Monitor ändert das jedoch die Ausgabe nicht.

Grüße aus HH
Jan

[Herbert K. (avr-herbi)]

Herbert K. schrieb:
ali-003.jpg funktioniert ebenfalls (konnte meinen Beitrag leider nicht 
mehr editieren)

[Herbert K. (avr-herbi)]

Dietrich schrieb:
...
Hallo Jan,
Keine Ahnung, welchen Source Du verwendest. Ich habe den von Hubi und 
der Start in der Seriellen Console sieht zu Beginn so aus wie in der 
Anlage.
Vielleicht hilft Dir das als Vergleich. Webserver ist vom Firefox und 
Chrome erreichbar. Egal ob der NRF24L01+ vorhanden ist oder nicht.

[Dietrich (Gast)]

Moin Herbert,

ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl. 
SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und 
mich wieder melden.

Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss 
sich mein D1 weghängen.

[Hubi (Gast)]

Hallo
da inzwischen einige Leute meine Source benutzen und noch Probleme 
haben, meine Frage: Soll ich eine Version bereitstellen mit einer 
Settings.h, in der genau beschrieben ist was einzustellen ist?

[Marcel A. (a-marcel)]

Hubi schrieb:
> Hallo
> da inzwischen einige Leute meine Source benutzen und noch Probleme
> haben, meine Frage: Soll ich eine Version bereitstellen mit einer
> Settings.h, in der genau beschrieben ist was einzustellen ist?

Würde sich anbieten denke ich, da sonst viele Fragen bzgl. des Programms 
aufkommen, wir aber noch herausfinden  müssen wie Channel Hopping und 
Werte setzen funktioniert sowie weitere Antworten/Werte herausfinden 
müssen.

Bisher ist ja alles noch in Entwicklung.

Marcel

[Herbert K. (avr-herbi)]

Martin P. schrieb:
> Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut)
>
> 01:
> 2bytes unbekannt "1"
> 2bytes dc_volt  / 10
> 2bytes dc_amps  / 100
> 2bytes dc_power / 10
> 2bytes unbekannt "0"
> 2bytes Total_w

Hallo Martin P., vielen Dank für Deine Analyse.
Im Telegram "01" für die HM-Single (300/350/400) ist dies
-- 2bytes unbekannt "0" --
evt. der Überlauf von
-- 2bytes Total_w --

Bei einem WR habe ich schon einen Überlauf, bei einem 2. WR erwarte ich 
den Überlauf in ca. 5 Tagen je nach Sonne. Dann werde ich das sehen.

Habe die Telegramme "01" und "82" erst mal so von Dir übernommen und bei 
meinen 2 HM 400 scheint das auch zu passen.

Danke an ALLE für die bisherige Arbeit.

[Martin P. (mpolak77)]

Herbert K. schrieb:
> Im Telegram "01" für die HM-Single (300/350/400) ist dies
> -- 2bytes unbekannt "0" --
> evt. der Überlauf von
> -- 2bytes Total_w --

das ist ein guter Tipp - und macht auch Sinn, weil die 64 kWh (mit nur 
16 bit) sind ja doch bald mal erreicht" .... bei mir dauert das noch .. 
bin erst bei 20 kWh...


Was mir generell noch aufgefallen ist: Gestern war meine Hoymiles DTU 
als Offline im System und die Cloud zeigte auch keine aktuellen Daten. 
Mein ESP hingegen loggte ganz normal in den IOBroker mit.
Heute Früh zeigt die Cloud plötzlich die fehlenden Daten von gestern 
bist Mitternacht an. Nach einem Aus/Einstecken der DTU loggt sie heute 
wieder normal.

Entweder hatte die Cloud gestern ein Problem, oder die WR dürften eine 
Art Historie speichern und die DTU hat sie heute nach Sonnenaufgang noch 
irgendwie rausgeschickt?

[Dietrich (Gast)]

Hubi schrieb:
> Hallo
> da inzwischen einige Leute meine Source benutzen und noch Probleme
> haben, meine Frage: Soll ich eine Version bereitstellen mit einer
> Settings.h, in der genau beschrieben ist was einzustellen ist?

Hallo Hubi,

ich denke das ist eine gute Idee um die Source von dir besser Nutzbar zu 
machen.

Grüße
Jan

[Dietrich (Gast)]

Dietrich schrieb:
> Moin Herbert,
>
> ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl.
> SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und
> mich wieder melden.
>
> Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss
> sich mein D1 weghängen.

Hallo zusammen,

soo Fehler gefunden. Ich habe keine Fritzbox, daher funktiniert der 
TimeServer define #define TIMESERVER_NAME "fritz.box" natürlich nicht. 
Einfach auskommentieren und Hubis Angabe "pool.ntp.org" benutzen.

Nun läuft der Webserver - jetzt muss nur noch der WR ankommen... :)

Grüße
Jan

[Marcel A. (a-marcel)]

Hallo,

ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp.

Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten 
im Log ?

1649772015 00 00DC 1B 2  95 73109025 73109025 010001017F00C702F900005E44039E08FBA3F89D AF08 A2DC DAA8 AF08 E3D3 E787 AF08 A2DC AF08 1F4A AF08 7860 0978 A436 A2DC A9E2 AEB6 08FE AF08 A2DC AF08 A9E2 25BB A2DC A9E2 F891
hm400:  Voltage: 38.30V, Ampere: 1.990A, Power: 76.10W
        Total Production: 24.132kW, Daily Production: 926.00W, AC Voltage: 229.90V

(erste spalte ist epochtime, welches ich hinzugefügt habe)

Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen 
des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ?

Marcel

[Herbert K. (avr-herbi)]

Marcel A. schrieb:
> Hallo,
>
> ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp.
>
> Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten
> im Log ?

Hallo Marcel, ja bei mir kommt auch des öfteren etwas merkwürdiges. 
Bisher mache ich mir da nicht viel drauss.
Bin froh, das ich das mit 2 Stk. HM400 so weit hinbekommen habe, trotz 
fehlender "C++" Kenntnisse.
Ich versuche die nä. Tage mal Fehler zu produzieren, ob man die in den 
unbekannten Feldern wiederfindet.

An die "C++" Programmierer:  Bitte was muss ich wo ändern, um die 4 Byte 
zu
Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr 
als 65535 werden können ? Danke schon mal.

[Dietrich (Gast)]

Martin P. schrieb:
> Früher oder später wird auch eine etwas robustere Hardware interessant
> werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01
> Combo gefunden:
>
> 
http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge
> Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein.
> Sollte als Ersatz-DTU aber auch seinen Dienst machen.
>
> Hier noch etwas minimalistischer:
>
> https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/
>
> was mich bei letzterem allerdings verwundert, sind die fehlenden
> Widerstände, die der ESP12 normalerweise braucht.

Hallo,

ich habe mal den Creator angeschrieben ob es okay ist, wenn wir uns ein 
paar Platinen machen lassen. Wenn das okay bist, bestelle ich mal 5 
Stück. 4 davon würde ich dann kostenlos an die Hauptverantwortlichen 
hier verschicken, wenn ihr was damit anfangen könnt. Quasi als Support 
:)

Grüße
Jan

[Martin P. (mpolak77)]

> Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen
> des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ?
> Marcel

Ich habe solche bei mir auch gesehen … habe aber auch die gleiche 
CodeBase..

[Chris (Gast)]

Hallo zusammen, ich bin heute auf der Suche nach einer DTU alternative 
auf euren Thread gestoßen. Dies ist mein erster Eintrag hier im Forum. 
Ich bin absolut beeindruckt was hier alles geleistet wurde. Ich bekomme 
auch bald einen HM-1500 und möchte die Daten selbst per MQTT auslesen. 
So wie ich es gelesen habe, besteht die Hardware aus ESP8266 + NRF24L01. 
Die hab ich zufällig schon rumliegen. Wo finde ich denn den Code?

Viele Grüße an die großartigen Unterstützer, Analysten, Programmierer 
hier!!!!

Gruß Chris

[Hubi (Gast)]

Herbert K. schrieb:
> An die "C++" Programmierer:  Bitte was muss ich wo ändern, um die 4 Byte
> zu
> Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr
> als 65535 werden können ? Danke schon mal.

Ich mache das so:

float extractValue4 (uint8_t *p, int divisor) {
//-------------------------------------------
  uint32_t ret  = *p++;
  for (uint8_t i = 1; i <= 3; i++)
    ret = (ret << 8) + *p++;
  return (ret / divisor);
}

Du übergibts einen Zeiger auf die Stelle in der Payload wo dein 4-byte 
Wert beginnt und als Divisor 1 (kannst du also auch weglassen), etwa so:
[b]
float wert = extractValue (&payload[??], 1)
[/b]
Das findest du aber alles in meinem am 10.4. geposteten Code.

[Hubi (Gast)]

Im Anhang überarbeitete Version meiner Software, die auf ESP als auch 
Arduinos läuft. Neu ist:
- extra Settings.h mit den möglichen Einstellungen
- automatische Konvertierung der WR-Seriennummer in diese umgedrehte 
Radio-ID
- Source Sonne.h enthält Berechnung von Sonnenauf- und -untergang => 
nachts nicht mehr den WR abfragen

[Jan-Jonas S. (janjonas_s)]

@Hubi, kannst Du das bitte via git bereitstellen? Sourcen in zip-Files 
ohne Versionierung in Foren teilen ist wenig hilfreich. Danke.

[Peter L. (leliep)]

Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss 
der Funkmoduls an den ESP8266 D1 mit Hubis Software (Danke dafür!) nicht 
korrekt gemacht habe. Die Software an sich läuft und verbindet sich 
problemlos mit meinem WLAN, die Web-Oberfläche kann ich auch aufrufen, 
aber alles 0.

Möglicherweise bin ich nicht der Einzige, der nicht sicher ist, welche 
Pins ausser den in Settings.h erwähnten mit dem ESP verbunden werden 
müssen.

Meine Bitte: wäre jemand so nett, die komplette Verschaltung dieser 
Konfiguration zu dokumentieren...? Dankeschön!

aus Settings.h:
// Hardware configuration
#ifdef ESP8266
#define RF1_CE_PIN  (D4)
#define RF1_CS_PIN  (D8)
#define RF1_IRQ_PIN (D3)

GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für 
den NRF24) sind klar.

Aber was ist mit MO (D7?) und MI (D6?)...

[Herbert K. (avr-herbi)]

Peter L. schrieb:
> Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss
....
> Aber was ist mit MO (D7?) und MI (D6?)...

Hallo, natürlich musst Du MISO, MOSI, CLK anschliessen, damit die RF24 
LIB funktioniert. Einfach mal in die Datenblätter schauen vom ESP8266 
und NRF24...
Hab die HW gerade nicht zur Hand.

[Daniel M. (daniel_m821)]

Peter L. schrieb:

> aus Settings.h:
> // Hardware configuration
> #ifdef ESP8266
> #define RF1_CE_PIN  (D4)
> #define RF1_CS_PIN  (D8)
> #define RF1_IRQ_PIN (D3)
>
> GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für
> den NRF24) sind klar.
>
> Aber was ist mit MO (D7?) und MI (D6?)...

Ich habe:
D4 -> CE
D8 -> CSN
D3 -> IRQ
D5 -> SCK
D6 -> MIso
D7 -> MOsi
VCC und GND ergeben sich.

Leider auch noch kein Signal.

@Hubi: war da nicht noch was mit der "ersten Taufe" damit der Gerät 
spricht?
Sonnenoffest hab ich mal auf 120min gestellt, du verwendest da UTC, 
oder?

Sonst sehr gute Arbeit :)
Vielen dank!

[Martin P. (mpolak77)]

Es gibt viele Bespiele in Google - aber halte dich nicht an die … 
sondern Google nach nrf24l01 Pinout und welchen Controller du hast. 
Verbinde die SPI Pins wie sie der Controller hat und wähle für CE und 
CSN und IRQ Die Pins aus dem Code. Beachte, dass es unterschiedliche 
Nomenklatur gibt (deshalb haben diese Pinout Bilder immer mehrere Namen)

[Peter L. (leliep)]

OK, wie auch von Daniel geschrieben, habe ich es so gemacht:

NRF24       ESP8266
----------------------
RF1_CE_PIN  D4
RF1_CS_PIN  D8
RF1_IRQ_PIN D3

RF1_MO_PIN  D7
RF1_MI_PIN  D6
RF1_SCK_PIN D5

GND         G
VCC(5V)     5V (NRF24 mit Spannungsregler-Platine)
VCC(3,3V)   3V3

Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>.
Morgen kommt die Sonne wieder ;-)

[Daniel M. (daniel_m821)]

Peter L. schrieb:
> OK, wie auch von Daniel geschrieben, habe ich es so gemacht:
>
> NRF24       ESP8266
> ----------------------
> RF1_CE_PIN  D4
> RF1_CS_PIN  D8
> RF1_IRQ_PIN D3
>
> RF1_MO_PIN  D7
> RF1_MI_PIN  D6
> RF1_SCK_PIN D5
>
> GND         G
> VCC(5V)     5V (NRF24 mit Spannungsregler-Platine)
> VCC(3,3V)   3V3
>
> Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>.
> Morgen kommt die Sonne wieder ;-)

Wir werden sehen ob ein Reboot über Nacht hilft. Ic hvermute trotzdem 
eher den initialen "Hello" Schritt, der noch fehlt, quasi ein Setup, 
damit erstmal WR und "Databox" zueinander finden.
Sonst muss ich sagen, ist der Arduino-Code echt genial, sehr sauber und 
übersichtlich.

Danke Hubi :)

[Hubi (Gast)]

Hallo zusammen
da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In 
meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob 
Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS) 
und dazu eine CS( Chip select).
Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als 
ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe.
Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software 
in Verbindung mit einem RasPi als "Datensammler" und Webserver mit 
grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder 
meine neue Weiterentwicklung kann sich bitte hier gern melden.

[Daniel M. (daniel_m821)]

Hubi schrieb:
> Hallo zusammen
> da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In
> meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob
> Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS)
> und dazu eine CS( Chip select).
> Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als
> ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe.
> Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software
> in Verbindung mit einem RasPi als "Datensammler" und Webserver mit
> grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder
> meine neue Weiterentwicklung kann sich bitte hier gern melden.

Ein Git-Account sollte nicht kompliziert sein, wäre halt praktisch.
Welche Belegung nutzt du an deinem Wemos? Vielleicht kann man das 
zusammen dort in die readme packen.

Ich warte mal auf den Reboot über Nacht, vielleicht hilft der.
Ich hab noch das große Fragezeichen, weil ich einen potentiell 
kompatiblen Typ nutze, kein originalteil.
Laut Anleitung soll ein initiales binding durchgeführt werden, ob das 
wirklich nötig ist, weiß ich nicht.
Ist es sehr aufwändig, so ein "Hello" zu implementieren, das man über 
Konsole oder Webserver anstoßen kann?

Du hast gerade den vielversprechendsten Ansatz für den ESP8266.
Ein Paypal-Spendenlink für den einen oder anderen Kaffee würde ich auch 
sehr begrüßen, genauso von den anderen, die hier so einiges beigetragen 
haben :)

Ich hoffe noch auf die Leistungsregulierung, wenn das mit der 
Kommunikation komplett klappt. Dann kann man auf Nulleinspeisung oder 
Akku-laden via NodeRed schauen, der SDM z.B. ist ja auch keine 
Raketentechnik. Da würde ich mich dann mehr einbringen, wenn ich das 
ganze richtig zum laufen gebracht hab.

lg

[Marcel A. (a-marcel)]

Hallo Daniel,

mich würde mal Interessieren, woher die Annahme kommt, das der TSUN 
gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja 
schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu 
sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche 
Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen 
technischen Angaben weichen beide eben ab.

Zusätzlich die Information, das es ein hello signal geben soll weisen 
ggf. sogar schon drauf hin, das es eine andere Software hat.

Und Hubi hat doch schon die Software bereitgestellt und erhebliche 
Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf 
GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde 
den Github Link zu einer anderen Code Version und mache einen Pull 
Request und füge diesen Code hinzu.

Marcel

[Daniel M. (daniel_m821)]

Marcel A. schrieb:
> Hallo Daniel,
>
> mich würde mal Interessieren, woher die Annahme kommt, das der TSUN
> gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja
> schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu
> sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche
> Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen
> technischen Angaben weichen beide eben ab.

In der Anleitung zu den Kommunikationsadaptern beider Hersteller steht 
Hoymiles drin. Die cloud bei Tsun läuft auf einer anderen URL, 
allerdings identisch aufgebaut. Es würde mich nicht wundern, wenn es 
eine Kopie ist.
Die Initialisierung beider Geräte auf Kommunikationsebene ist identisch 
beschrieben. Was am Ende im Protokoll passiert, kann anders sein, ganz 
klar.

> Zusätzlich die Information, das es ein hello signal geben soll weisen
> ggf. sogar schon drauf hin, das es eine andere Software hat.

Das Hello wurde schon in anderen Postings beschrieben, ebenfalls steht 
es in der Anleitung.

> Und Hubi hat doch schon die Software bereitgestellt und erhebliche
> Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf
> GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde
> den Github Link zu einer anderen Code Version und mache einen Pull
> Request und füge diesen Code hinzu.

Und ich bin ihm sehr dankbar dafür. Einen ESP8266 als Interface nutzen 
zu können, ist ein großer Vorteil.
Da ich noch einen Raspi und ein 2. RF24 Interface habe, schau ich die 
Tage mal, was ich tun kann. Werde auch noch einen Stick von Tsun 
besorgen und schauen, was der tut. Es wäre ungewöhnlich, wenn bei dieser 
Schnittmenge zwischen den Geräten, das nicht einfach nur eine Kopie mit 
kleinen Änderungen in der Ziel-URL ist, zumal selbst die 
Bedienoberfläche des Stick laut Anleitung beim Tsun identisch zu der von 
Hoymiles ist.

Das mit Git werd ich gerne mit machen, sofern Hubi nichts dagegen hat.

[Herbert K. (avr-herbi)]

Hallo,
Hubi´s Code funktioniert bei mir ohne Probleme. Ich habe auch keine 
DTU...
Der Code hat sofort funktioniert, nachdem ich die WR SN eingetragen 
habe.

1. Es muss (!) der nRF24L01+   sein. Das PLUS ist wichtig !  Ein "alter" 
nRF24L01 (ohne Plus) funktioniert NICHT !

2. Sucht im Code nach
"// radio1.printPrettyDetails();"

und übersetzt den Code mal, in dem Ihr das wieder einkommentiert
"radio1.printPrettyDetails();"

Dann findet Ihr in der Seriellen Konsole was das - sofern der RF24 
richtig verdrahtet ist - so aussieht.

Steht da NICHT  "RF Data Rate            = 250 KBPS " ist was Faul in 
der Kommunikation zum nRF24L01+ .


SPI Frequency           = 10 Mhz
                                Channel                 = 3 (~ 2403 MHz)
RF Data Rate            = 250 KBPS
RF Power Amplifier      = PA_MAX
RF Low Noise Amplifier  = Enabled
CRC Length              = Disabled
Address Length          = 5 bytes
Static Payload Length   = 32 bytes
Auto Retry Delay        = 250 microseconds
Auto Retry Attempts     = 0 maximum
Packets lost on
                   current channel      = 0
Retry attempts made for
                           last transmission    = 0
Multicast               = Disabled
Custom ACK Payload      = Disabled
Dynamic Payloads        = Disabled
Auto Acknowledgment     = Disabled
Primary Mode            = RX
TX address              = 0xe7e7e7e7e7
pipe 0 (closed) bound   = 0xe7e7e7e7e7
pipe 1 ( open ) bound   = 0x1234567801
pipe 2 (closed) bound   = 0xc3
pipe 3 (closed) bound   = 0xc4
pipe 4 (closed) bound   = 0xc5
pipe 5 (closed) bound   = 0xc6

[Martin P. (mpolak77)]

Ja, wenn die Kommunikation mit dem nrf24l01+ erst mal funktioniert, kann 
es immer noch an der Funkschnittstelle scheitern.

Einen Kondensator an +- des Moduls anlöten.
Eine Zwischenplatine mit eigenem LDO (hier scheint es auch 2 Varianten 
am Markt zu geben: mit kleinen und großen SMD caps drauf)

Eine nrf24l01+ Variante mit PA/LNA und   SMA Antenne verwenden.

Eine Dipolantenne an das kleine Modul löten.

Wenn Kondensator dran ist, auch mal PA_MODE_HIGH oder PA_MODE_MAX 
probieren.

[Hubi (Gast)]

Hallo
anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine 
Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja 
nur ein paar Strippen zu löten.
Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht 
nur für den HM-600, und auch für mehrere (unterschiedliche) WR 
gleichzeitig.
Eine Version für RasPi könnte da auch noch drin sein.
Ich überleg's mir mal. Vllt könten sich auch ein paar von uns 
zs-schließen und das mit Git machen, Aufgaben verteilen etc.

[Ziyat T. (toe_c)]

Hubi schrieb:
> Hallo
> anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine
> Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja
> nur ein paar Strippen zu löten.
> Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht
> nur für den HM-600, und auch für mehrere (unterschiedliche) WR
> gleichzeitig.
> Eine Version für RasPi könnte da auch noch drin sein.
> Ich überleg's mir mal. Vllt könten sich auch ein paar von uns
> zs-schließen und das mit Git machen, Aufgaben verteilen etc.

Hallo Hubi
Herzlichen Dank für die SW und die Bilder.
Und natürlich an dieser Stelle Danke auch an allen Beteiligten am 
Projekt.
Ich habe eine DTU-Pro und MI1500 am Laufen, da die Zero Export Funktion 
nicht so lief, wie sie sollte (und wie die Hotmiles behauptet), steuere 
ich mit einem Python/Modbus script über die DTU den MI1500, so wie ich 
es richtig halte.

Ich möchte gerne die DTU-Pro ersetzen, die SW hat Fehler (bei kleineren 
Loads) und die Hoymiles will es nicht korrigieren.

Ich werde deine SW verwenden, mit WEMOS D1 mini und nrf24l01+ PA/LNA/SMA 
Antenne.

Mich interessiert die WR Steuerung bzw. Limitierung, ich würde gerne 
hier mit machen, da ich den MI1500 über myPython/DTU prozentual 
limitieren und dort halten kann, könnte ich ev. die Limitierung heraus 
finden.

Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die 
raw-Packete beobachten?

Danke und grüsse aus dem Süden.
Ziyat T.

[Hubi (Gast)]

Toe C. schrieb:
> Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die
> raw-Packete beobachten?

Meine SW arbeitet auf Telegramm-Ebene. Ich weiß nicht so genau was du 
mit raw-Paketen meinst, wahrscheinlich eher sowas wie oben mittels 
Sniffer mitgeschnittenen Datenverkehr. Musst wohl doch den Thread 
nochmals lesen.
Steuerung des WR wäre natürlich auch ganz nett, also dass man 
limitieren kann bzw diese auch aufheben kann. Wenn da was zu 
programmieren ist bin ich dabei, auch wenn ich keine DTU habe.

[Herbert K. (avr-herbi)]

Eine Frage an die DTU-Wlite und DTU-Pro Besitzer:

Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR 
über die offiziellen hoymiles Wege bekommen und auf welche 
Kommunikatiosart ?
(also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem 
Smartphone, RS485 ?, ...)
Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU... 
übertragen werden.

[Ziyat T. (toe_c)]

Herbert K. schrieb:
> Eine Frage an die DTU-Wlite und DTU-Pro Besitzer:
>
> Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR
> über die offiziellen hoymiles Wege bekommen und auf welche
> Kommunikatiosart ?
> (also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem
> Smartphone, RS485 ?, ...)
> Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU...
> übertragen werden.

Hallo Herbert
Ich steuere meinen MI1500 über DTU-Pro/ModbusRTU selber.
Ich habe bisher an der DTU-Pro die folg. WR-Port-Status herausgefunden:

PORT_STATUS = ["can't read", "?", "?", "Normal", "?", "(ev.)PV not 
connected", "?", "?", "Reduced"]
Die 8=Reduced wird im S-miles als "remote shutdown" ersichtlich, 
manchmal;-).

Grüsse
Ziyat

[Hans W. (hans_w801)]

Hallo,

auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich 
hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann 
es noch nicht montieren.

Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1 
laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht 
verpackt und hatte beim Transport ganz schön gelitten.

Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine 
Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht 
weiß, ob er den Transport überlebt hat.

Gruß Hans ...und Hut ab vor eurer Arbeit hier !!!

[Daniel M. (daniel_m821)]

Hallo in die Runde,

wie versprochen kommt meine DTU für den TSUN am Dienstag. Bin gespannt 
wie das Innenleben aussieht.

Mit welchen Tools macht es am meissten Sinn, die DTU auf rx/tx zu 
überwachen?
Ich hätte USB-Serial Adapter hier und kann vom ersten Einschalten 
beobachten, theoretisch.

Bislang komme ich mit dem Wemos nicht weiter, keine Kommunikation mit 
dem WR, was ich aber fast erwartet habe.

Ich hab mal dein Stück des Bootvorgang und der Kommunikation mit 
angehängt.
Debug ist aktiviert und die Sendedaten lasse ich mir mit anzeigen.

lg
Daniel

[Reinhard B. (reinhardb)]

Hans W. schrieb:
> Hallo,
>
> auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich
> hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann
> es noch nicht montieren.
>
> Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1
> laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht
> verpackt und hatte beim Transport ganz schön gelitten.
>
> Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine
> Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht
> weiß, ob er den Transport überlebt hat.
>
> Gruß Hans ...und Hut ab vor eurer Arbeit hier !!!

Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem 
"+" bekommt?
Vielen Dank!

[Martin P. (mpolak77)]

Ich habe diese:
WayinTop 2pcs NRF24L01+PA+LNA... https://www.amazon.de/dp/B07PBBC4H9
(Mit PA und LNA - die breakout boards dabei sind nicht gut)

Und die:
AZDelivery 5 x NRF24L01 mit 2,4... https://www.amazon.de/dp/B075DBDS3J

[Marcus (Gast)]

Hallo,

kann man eigentlich auch einen RF-NANO (z.B. 
https://de.aliexpress.com/item/1005003513445043.html) verwenden?
NRF24_SendRcv kompiliert, aber hier scheint es keinen IRQ zu geben?!

[Marcus (Gast)]

Der RF-Nano verhält sich merkwürdig:
- isPVariant liefert true also PLUS
- setDataRate liefert mit 250KBPS false - unterstützt also keine 250KBPS

Insofern also wohl nicht brauchbar :-(

[Hubi (Gast)]

Hakko Marcus
das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem 
Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben, 
also sollte D2 der INT0 sein.
Bei den Kundenbewertungen ist auch erwähnt, dass wohl nicht die 
Plus-Variante des RF-Moduls verbaut wurde, also keine 250 kbps.

[Peter L. (leliep)]

Reinhard B. schrieb:
> Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem
> "+" bekommt?

bei mir gerade von AZ-Delivery angekommen: funktioniert! :-)

Der Tip mit dem "PLUS" war entscheidend, Danke für Eure Unterstützung, 
mein HM-1200 spricht nun mit mir!

[Martin G. (petersilie)]

Hubi schrieb:
> Vllt könten sich auch ein paar von uns
> zs-schließen und das mit Git machen, Aufgaben verteilen etc.

Also mein Vorschlag steht ja und wird auch schon fleißig geforkt:

* https://github.com/grindylow/ahoy

Persönlich bin ich eher an der Raspi-Seite interessiert, aber die beiden 
ergänzen sich ja gegenseitig.

[Martin G. (petersilie)]

Wir bräuchten dringend mal noch längere Logs von Datenverkehr mit echten 
DTUs.

Ich meine, in den ursprünglichen Mitschnitten war das 0x80 ja garnicht 
notwendigerweise als das fortwährend zu sendende Paket zu erkennen - 
macht ja eigentlich auch keinen Sinn, sekündlich die Uhrzeit neu zu 
setzen. Vielleicht bringt das ja auch jedesmal das Channel Hopping 
wieder durcheinander?

Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu 
belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24 
zu tun. Das wäre spitze, aber natürlich Hardware-intensiv...

Meine DTU kam immernoch nicht - und die Hoffnung schwindet.

[Oliver F. (of22)]

Martin G. schrieb:
> Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu
> belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24
> zu tun. Das wäre spitze, aber natürlich Hardware-intensiv...

Hallo Martin.
Das war mein Plan.
Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die 
erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren 
bin. Konnte es leider noch nicht richtig ausprobieren.
Aber ich denke, das wird neue Erkenntnisse bringen.
Erste Tests haben aber schon gezeigt, dass die DTU leider auf mehr als 6 
Kanälen sendet.

[Marcus (Gast)]

Hubi schrieb:
> das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem
> Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben,

Mhh - ich dachte der IRQ wird (beim Aufbau Wemos D1/NRF-Modul) 
verwendet, um einen IRQ bei Empfang auszulösen (für die ISR). Der 
IRQ-Pin des NRF auf dem RF-Nano ist nicht verbunden. Meinst Du der Nano 
löst dennoch einen Interrupt auf D2 / D3 aus? Kann ich mir jetzt nicht 
vorstellen - außer man würde den IRQ-Pin des NRF mit dem Nano PIN D2 
oder D3 verbinden. Normal ist da ja bei einem Nano nichts verbunden 
(außer eben wenn man ein externes NRF-Modul anschliesst).

Fazit für das Topic:
Der RF-Nano ist für das Auslesen der Hoymiles weniger (bzw. nicht) 
geeignet. Wenn man diesen dennoch testen möchte, dann ist zu prüfen, ob 
er wirklich ein NRF+ Modul hat (am besten die Datenrate von 250KPBS 
setzen und überprüfen). Es scheint wohl welche mit und ohne zu geben. 
Wenn er ein NRF+ Modul hätte, müsste man aber vermutlich auch die 
Software bzgl. der ISR / IRQ Thematik anpassen.

Ich habe mir nun die hier im Thread genannten Module bestellt: 
[[https://www.amazon.de/dp/B075DBDS3J]]
Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca. 
10-15m LOS + 1 Holzdach überbrückt?

[SUNPOWER (Gast)]

Hallo,

habe einen HM1200.
Aufschrift 1200HR. EU .HM.
Die Seriennummer ist rein numerisch 116170522231, kann das sein?
Habe die leider nicht vorher aufgeschrieben und nun mit einer
Iphone/Holzlattenkombination auf dem Dach abgefilmt......

Danke

[Hubi (Gast)]

Marcus schrieb:
> Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca.
> 10-15m LOS + 1 Holzdach überbrückt?

Hallo Marcus
genau diese benutze ich auch. Die reihen hier vom Wohnzimmer, wo 
programmiere und teste bis zum WR auf dem Gartenhaus, ca. 20 m entfernt, 
dazwischen eine Tür mit Isolierglas und Büsche/Bäume.

[Lukas P. (lumapu)]

> Die Seriennummer ist rein numerisch 116170522231, kann das sein?

Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch 
mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde 
ein 0x vorangestellt sein.

[Marcus (Gast)]

@Thomas B.
Noch etwas für die Statistik 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" - da ich 
gerade den WR fotografiert habe:

Die Seriennummer meines HM-400 beginnt mit: 1121

[Peter L. (leliep)]

11617… mein HM-1200

[Was (Gast)]

Lukas P. schrieb:
>> Die Seriennummer ist rein numerisch 116170522231, kann das sein?
>
> Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch
> mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde
> ein 0x vorangestellt sein.

Danke,

wo fange ich an?
Der Thread ist etwas unüberschaubar.
Ich habe NRF, Atmega, Espxxxx und Raspi…

[isnoAhoy (Gast)]

Danke an Hubi für das Update des ESP8266/ESP32 Codes und die anderen die 
hier schon fleißig getraced haben!

Seit ich meine HM-600 Seriennummer (beginnt mit 1141 7310 xxxx) 
eingetragen habe und das in der alten Version (vom 10.4.) fehlende 
Debug.h auskommentiert habe funktioniert es bei Tageslicht problemlos.

Ich habe diese Bibliotheken extra installiert:
* RF24
* TimeLib
* Pinger (braucht man in der neuen Version vom 13.4.  evtl. nicht mehr 
?)

Hier sind die Verbindungen meiner beiden Komponenten:

* Pinout des PA nRF24L01+ Moduls:

Ich habe dieses hier von derpaule auf eBay bestellt, scheint nur jetzt 
vergriffen zu sein.
Aber man kann wie bei den AZ-Delivery aus der Zone sehr gut das nRFL01 
"+" sehen.
https://www.ebay.de/itm/165071116650

Die Debug Ausgaben sollte m.E. immer das og. 
radio1.printPrettyDetails(); aktiviert haben, damit man etwas über die 
korrekte Belegung des nRF24L01 Moduls erfährt.

|Colour|Description|Pin|Pin|Description|Colour|
|------|-----------|---|---|-----------|------|
|black | GND       |[1]|[2]| VCC +3.3V |white |
|grey  | CE        |[3]|[4]| CSN       |purple|
|blue  | SCK       |[5]|[6]| MOSI      |green |
|brown | MISO      |[7]|[8]| IRQ       |yellow|

* ESP8266 / NodeMCU Anschlüsse:

Wire Connections

    +-----------+          +-----------+
    | nRF24L01+ |--colour--| ESP8266   |
    |           |          |           |
    |       GND |---black--| GND       |
    |       VCC |----red---| +3.3V     |
    |        CE |---grey---| D4        |
    |       CSN |--purple--| D8        |
    |       SCK |---blue---| D5        |
    |      MOSI |---green--| D7        |
    |      MISO |---brown--| D6        |
    |       IRQ |--yellow--| D3        |
    +-----------+          +-----------+

Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in 
das Readme.md auf dem Ahoy Github einchecken.

@Hubi unter welcher Lizenz steht denn Dein Source Code und darf der 
ebenfalls eingecheckt werden ?
Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter 
verbessern.

Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter 
(Liste/Array mit WR IDs) in einer Schleife abfragen kann ?
Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher 
praktisch.

Eine Ausgabe der Daten im Serial Plotter Format wäre für einfache Tests 
ohne MQTT, etc. ebenfalls geschickt.
Hier ist die PDF Dokumentation [1] und hier die offizielle Markdown Doku 
[2] der Arduino Software zum Serial Plotter Protokoll.

[1] 
https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.pdf

[2] 
https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.md

[Lukas P. (lumapu)]

Hallo,

seit Mitte Februar lese ich begeistert in diesem Thread. Leider hatte 
ich bis jetzt nur Zeit die unglaubliche Anzahl der Beiträge zu lesen. 
Vielen Dank für eure Arbeit, es ist einfach toll zu sehen wie schnell es 
hier weitergeht!

Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier 
möchte ich was beitragen. Ein pull-request habe ich erstellt.

Mein Setup:
- HM1200
- NRF24L01+ https://www.ebay.de/itm/255283312809
- ESP8266 (ESP-07)
- Verdrahtung wie in dem Post darüber

Aktueller Stand:

Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich 
es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station).
Ich konnte damit auch schon loggen, allerdings habe ich festgestellt, 
dass ich nur Antworten mit Command 0x81 bekomme. Wenn ich den Code von 
Hubi direkt verwende, dann kommen auch andere Commands.

Zur Verifizierung der Werte habe ich einen Sonoff-POW-R2 vor dem 
Wechselrichter und kann damit die Leistung vergleichen. Die Werte aus 
Hubi's Webinterface stimmen nicht für meinen HM1200.

[Hubi (Gast)]

isnoAhoy schrieb:
> @Hubi unter welcher Lizenz steht denn Dein Source Code und darf der
> ebenfalls eingecheckt werden ?
> Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter
> verbessern.
>
> Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter
> (Liste/Array mit WR IDs) in einer Schleife abfragen kann ?
> Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher
> praktisch.

Moin zusammen
Meine Source hat keine Lizenz, stammt ja ursprünglich auch nicht von mir 
sondern von der ahoy-Seite bei Github.
Ja, im Moment bin ich noch am aufräumen und verbessern.
Eine Version für mehrere WR ist in Arbeit. Die abzufragenden Messwerte 
hinterlege ich in einer Liste, pro Messwert eine Zeile mit
WR, Messwertname, Einheit, Telgramm-ID, Offset, Länge, Funktion. Als 
Funktion kann man einen Divisorwert oder eine selbst definierte Funktion 
nehmen, zb wenn man die Stromstärke haben will mittels P/U.
Da das ganze auch für Arduinos (zB Pro mini) laufen soll, musste ich 
etwas aufräumen. Besonders in der crc.cpp konnte ich über 500 byte 
einsparen, indem ich eine crc-Lib benutzt habe. Aber es läuft ohne 
Speicherwarnung auch auf dem Pro Mini, natürlich nicht mit webinterface, 
aber mit Ausgabe über Serial.
Wenn der Autor von der ursprünglichen NRF24-SendRcv (ahoy) nichts 
dagegen hat dann stelle ich meine Entwicklung ins Git.
Meine Source ist im Moment nur für den HM-600. Für andere WR-Typen wird 
das nicht funktionieren, denn da sind die Requests und Antworten anders 
mit anderen Telegram-IDs und offsets. Wenn mir jmd seine Erkenntnisse 
über seinen WR zuschickt, bringe ich das in meine Source mit ein.
Schöne Ostern

[Martin P. (mpolak77)]

Wenn mir jmd seine Erkenntnisse
> über seinen WR zuschickt, bringe ich das in meine Source mit ein.
> Schöne Ostern

Ich habe weiter oben gepostet, dass HM-700 gleich wie der HM-600 tut und 
wie die Interpretation für HM-350 ist (und HM-400 scheint gleich zu 
sein)

Brauchst du trotzdem meinen Code dazu auch?

[Hubi (Gast)]

Source brauche ich im Moment noch, die nötigen Daten suche ich mir oben 
zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst 
Mehr-WR-Fähigkeit entwickeln will.

[Hubi (Gast)]

Source brauche ich im Moment noch nicht, die nötigen Daten suche ich mir 
oben zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst 
Mehr-WR-Fähigkeit entwickeln will.

[rejoe2 (Gast)]

Oliver F. schrieb:
> yveaux NRF24 sniffer

Hallo, Oliver F.,
könntest du eventuell den Code posten? Wollte auch mal ein serielles 
MySensors-GW umflashen und zum sniffen nutzen, aber leider bekomme ich 
schon den Ausgangs-Sketch von Yveaux nicht via Arduino-IDE compiliert. 
Konkret wird die "wrong number of template arguments" bzgl. des 
CircularBuffer (Zeile 97?) bemängelt...

Wäre toll, wenn du da helfen könntest.

[Ziyat T. (toe_c)]

@Hubi, @Martin G(petersilie)

Hallo zusammen

Mein Setup:
DTU-Pro
MI1500 (nur Port3/4 mit PV's)
WemosD1mini
NRF24L01+ wie https://www.ebay.de/itm/255283312809

Ich verwende Hubi's letzte Version(mit settings.h):
- NRF24L01+ mit 256KBPS funktioniert, siehe init in log Dateien
- MI1500 gibt keine Antwort, siehe NRF24_DTU_OFF.log


Aber wenn ich DTU-Pro einschalte:
  - erhalte ich etwas, die PV/AC/etc. Werte stimmen nicht 
(wahrscheinlich auch, da MI1500 4 Ports hat), siehe NRF24_DTU_ON.log
  - ich sehe neue CMD's, siehe NRF24_CMDXX, CMD 00,5A,55

Grüsse
Ziyat T.

[Hubi (Gast)]

Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine 
eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das 
Telegramm mit command 00 müsstest du mal untersuchen, zu was die 
aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die 
Werte der unbestückten Ports sein!?

[Ziyat T. (toe_c)]

Hubi schrieb:
> Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine
> eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das
> Telegramm mit command 00 müsstest du mal untersuchen, zu was die
> aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die
> Werte der unbestückten Ports sein!?

Habe schon versucht die Daten zu analysieren, wie ich sie anschaue ist 
gleich, bekomme ich keine gescheitere Werte, siehe Anhang

[Ziyat T. (toe_c)]

Hallo
wenn sich jemand interessiert im Anhang
MI1500 > DTU-pro log

[Peter L. (leliep)]

Falls noch nicht bekannt, mein HM-1200 sendet auch 84er-Telegramme. 
Nicht so oft, aber immer wieder.

Panels: 2 + 1, aktuelle Leistung: 800.69W, 4.895kWh letzte 24h, heute 
2.322kWh, total 73.528kWh

[Robert Bleumer (Gast)]

Leider, mein 1500 wird auch noch nicht unterstutzt, aber wenn ich mal 
helfen kann, schick mir mail auf robert (at) bleumer.nl

Kein DTU Pro dabei übrigens.

[Lukas P. (lumapu)]

Hallo zusammen,

ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück 
weitergekommen. Dank des Excel-Screenshots von tbnobody 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") habe ich so 
ziemlich alle Felder der Commands 01, 02, 03 und 84 für den HM1200 
zuordnen können.

Ich habe als Input die Firmware von Hubi verwendet und das serielle Log 
ausgewertet. Heute habe ich den ganzen Tag mitgeloggt und konnte dadurch 
sehr gut die Zuordnung bestimmen. (220418_log_out.xlsx ist das Log von 
heute)
Die Werte stimmen mit meinen durch einen vorgeschalteten Sonoff POW R2 
gemessenen Werte sehr gut überein (vor allem bezogen auf die 
Tagesproduktion und die Gesamtproduktion).

Falls jemand meine Schritte nachvollziehen will, hier so ein grober 
Fahrplan:
- ESP Firmware von Hubi, seriellen Output mitloggen
- Log bei https://regexr.com/ reinladen und mit folgender Regex filtern, 
die ausgegebene Liste dann wieder in ein File kopieren (Input für 
main.cpp)
- main.cpp kompilieren (VS2019 Projekt kann ich auch noch teilen)
- ausgegebenes CSV in LibreOffice / Excel öffnen und verschönern

Regex:

([0-9]+\s[0-9]+\s[0-9A-F]+\s[0-9A-F]+\s.\s+[0-9]+\s[0-9]+\s[0-9]+\s[0-9A-F]+\s[0-1])

[Herbert K. (avr-herbi)]

Lukas P. schrieb:
> Hallo zusammen,
>
> ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück
> weitergekommen. .... Commands 01, 02, 03 und 84 für den HM1200

Auch wenn ich aktuell keinen HM1200 habe, sage ich einfach mal Danke für 
die Arbeit !

[Lukas P. (lumapu)]

Jetzt ist mir aufgefallen, dass die 16bit vor den jeweiligen 
Gesamterträgen 0 sind, daher nehme ich an, dass die Gesamterträge als 
32bit Wert geführt werden. Weitere 8 Byte geklärt.

Byte 1 und 2 vom Command 01 könnte ein AC-Enable sein oder eine Art 
Netz-Sync boolean.

Was mir noch aufgefallen ist: es gibt nur 2 DC Spannungen, kann es sein, 
dass diese für jeweils 2 Eingänge gelten (HM1200 hat 4 Eingänge, aber 
nur 2 MPPT, also hat jeder MPPT eine Spannung).

[Was (Gast)]

wo fange ich an?
Der Thread ist etwas unüberschaubar.
Ich habe NRF, Atmega, Espxxxx und Raspi…

[Herbert K. (avr-herbi)]

analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.81 
PV-DC.P:163.10 PTotal-Ueberlauf-Unbekannt.W:0.00 PTotal.W:65535.00 
PToDay.W:106.00 AC.V:238.10

analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.69 
PV-DC.P:157.80 PTotal-Ueberlauf-Unbekannt.W:1.00 PTotal.W:0.00 
PToDay.W:107.00 AC.V:237.90

HM400 der "Überlauf"  :-)  ist gerade eben passiert  :-)
Also (P-Total) ist 4 Byte  :-) wie vermutet  :-)

Euch Allen einen schönen Tag

[Herbert K. (avr-herbi)]

Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank 
holt, müssten in den Telegrammen ja auch noch Hardware und Software 
Version versteckt sein ?
(wird in der Cloud ja angezeigt)

[lpb (Gast)]

Herbert K. schrieb:
> HM400 der "Überlauf"  :-)  ist gerade eben passiert  :-)
> Also (P-Total) ist 4 Byte  :-) wie vermutet  :-)

Super, dann stimmt die 4 Byte Größe wie im Manual angegeben - dann war 
ich am Anfang doch nicht ganz auf der falschen Spur.
Ich habe einen HM600, da müssen dann die 'Überlauf' Bytes in 2 
Nachrichten verteilt sein, sonst geht das nicht auf.
Ich vermute dann mal die letzten beiden 'null' Bytes (24/25) in Msg 01 
für P1 total, und die beiden Bytes vor P2 Total in Msg 02 (12/13).
Mal sehen, ob/wann das jemand mit einem HM600 bestätigen kann - bei mir 
dauert das wohl noch ...

In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein 
inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen 
Nachricht um 1 erhöht wird (ich sende aktuell alle 15 Sekunden eine 
Anfrage ab).
Da ich mir die Nachrichten der anderen Inverter nicht so genau 
angeschaut habe, gibt es sowas da auch (ich glaube, ich hatte da was 
gelesen - ansteigender Wert)?
Das könnte dann ein Hinweis sein, dass sich dahinter mehr verbirgt.
Evtl. lässt sich ja damit irgendwie der Inhalt der letzten 4 Bytes 
dieser Nachricht entschlüsseln, aber ein Muster (oder Wiederholungen, 
die z.B. auf die noch fehlenden SW/HW Version hindeuten könnten) habe 
ich bislang noch nicht gefunden.

In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder 
abends das Licht schwach ist und keine Einspeisung passiert, ist dieser 
Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) 
ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und 
'1002' gesehen. Leider habe ich keine passenden Codes in den Manuals 
gefunden, aber es schaut plausibel aus.

[Herbert K. (avr-herbi)]

lpb schrieb:
...
> In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder
> abends das Licht schwach ist und keine Einspeisung passiert, ist dieser
> Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null)
> ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und
> '1002' gesehen. ...
Ich biete zusätzlich noch 1003,1004,1008,1038

[Martin G. (petersilie)]

lpb schrieb:
> In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein
> inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen
> Nachricht um 1 erhöht wird

An welcher Position?

[Lukas P. (lumapu)]

Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden, 
einzig die Energieproduktionen sind monoton steigend.

Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir 
eine Gesamtübersicht / Doku der Bytes machen können?

Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander 
die Module ab und wieder angeklemmt habe -> sie stimmt.

[Lukas P. (lumapu)]

Herbert K. schrieb:
> Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank
> holt, müssten in den Telegrammen ja auch noch Hardware und Software
> Version versteckt sein ?
> (wird in der Cloud ja angezeigt)

Ich denke, es gibt weitere Kommandos, die nur am Anfang ausgetauscht 
werden, wenn z.B. die DTU mit dem Wechelrichter Kontakt aufnimmt.
Hat jemand mit einer DTU schon mal während der Einstellung der Begrenzng 
der Nennleistung die Kommandos 'gesnifft'?

[Was (Gast)]

Lukas P. schrieb:
> Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden,
> einzig die Energieproduktionen sind monoton steigend.
>
> Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir
> eine Gesamtübersicht / Doku der Bytes machen können?
>
> Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander
> die Module ab und wieder angeklemmt habe -> sie stimmt.

Ich hätte da Daten, darf aber nicht mitspielen:

wo fange ich an?
Der Thread ist etwas unüberschaubar.
Ich habe NRF, Atmega, Espxxxx und Raspi…

[lpb (Gast)]

Martin G. schrieb:
> lpb schrieb:
>> In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein
>> inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen
>> Nachricht um 1 erhöht wird
>
> An welcher Position?

Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in 
dem angehängtem Auszug der dekodierten Daten).

[Was (Gast)]

Wer erbarmt sich?😪

[isnoAhoy (Gast)]

> wo fange ich an?
> Der Thread ist etwas unüberschaubar.
> Ich habe NRF, Atmega, Espxxxx und Raspi…

NRF24L01+ und ESP8266/ESP32 funktionieren anhand des o.g. Schaltplans 
(Fritzing) und mit der Software NRF24_SendRcv.zip (18,2 KB) von Hubi vom 
13.4.2022 für einen Hoymiles HM-600 recht zuverlässig. Solltest Du einen 
anderen HM-1200, etc. Wechselrichter haben, ist wohl noch etwas 
Detailarbeit nötig.
Auch die Kommandos der DTU (pro) um ggf. den Zero-Export-Restriction 
Modus (z.B. Limitierung der Asugangsleistung auf 600W bzw. 600VA) 
umzustellen sind bisher noch nicht bekannt. Einzelne Bytes der 
Nachrichten sind aktuell auch noch nicht zweifellos geklärt, u.a. 
Hardware-, Software- und Netzprofilversion wie in der Hoymiles Cloud 
ausgegeben sind noch unbekannt. Dazu ggf. die letzten Beiträge von 
lumapu und avr-herbi nochmal lesen.

Wenn ich es richtig aufgefaßt habe stehen aktuell noch einige große 
Themen an:
* DFU (pro) Kommunikation bei der Einrichtung der Hoymiles App (am 
besten auf mehreren / allen Kanälen) mitschneiden.
* genaueres Verständnis für das sog. Channel Hopping, damit hängt evtl. 
auch die laufende Nummer der Nachrichten und der CRC Algorithmus 
zusammen.
* die ModBus Schnittstelle scheint die meisten Datagramme zu 
beschreiben.
   Hierzu sollte man die Dokumentation mit dem bisher erforschten 
nochmals vergleichen und ggf. bestehende Lücken auf unserer Seite 
dokumentieren bzw. untersuchen.
* HM-600, HM-1200, etc. Protokoll genauer untersuchen bzw. länger 
Protokoll Aufzeichnungen analysieren (wg. Überlauf).
* Inverter Status Codes 1000, 1001, 1002, 1003, 1004, 1008, 1038 in der 
0x83 Nachricht interpretieren.
* NRF24_SendRcv aktuell nur für HM-600, daher für andere Wechselrichter 
HM-1200, etc. erweitern.
* NRF24_SendRcv erweitern um mehrere Inverter / Wechselrichter 
nacheinander abzufragen.

[Marcel A. (a-marcel)]

Herbert K. schrieb:
> Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank
> holt, müssten in den Telegrammen ja auch noch Hardware und Software
> Version versteckt sein ?
> (wird in der Cloud ja angezeigt)

Bis auf die Softwareversion sollte alles in der Seriennummer enthalten 
sein. Diese, soweit ich das verstanden habe, gibt man ja beim Einrichten 
der DTU an.

Marcel

[isnoAhoy (Gast)]

> Wer erbarmt sich?😪

Du kannst auch das Ahoy [1] GitHub Repo von Martin G. (Petersilie) 
auschecken, dort befindet sich nun auch die von lumapu um ein ESP 
WiFi-Setup und OTA erweiterte ESP8266 Version, wie auch die bereits im 
Vorfeld von den Ersten hier im Thread benutzte Python Variante des ahoy 
Tools. Dafür brauchst Du dann halt einen Raspberry Pi 2+ das NRF24L01+ 
Modul und die Verkabelung. Was Du verwenden und erreichen möchtest 
entscheidet jede/r selbst.

[1] https://github.com/grindylow/ahoy/

[isnoAhoy (Gast)]

Herbert K. schrieb:
>> In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder
>> abends das Licht schwach ist und keine Einspeisung passiert, ist dieser
>> Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null)
>> ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und
>> '1002' gesehen. ...
> Ich biete zusätzlich noch 1003,1004,1008,1038

In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von 
Registern angegeben,
hängt das eventuell miteinander zusammen ?

4.3.2 Microinverter Data Register List

The following registers provide a microinverter data register list, 
which can be read-only
with the function code 0x03

| Registers | Name             | Decimal | Units | Remark 
|
| --------- | ---------------- | ------- | ----- | 
------------------------------------------------------------ |
| 0x1000    | Data Type        | /       | /     | Default, 0x3C 
|
| 0x1001    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1002    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1003    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1004    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1005    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1006    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1007    | Port Number      | /       | /     | 
|
| 0x1008    | PV Voltage       | 1       | V     | 
|
| 0x1009    | PV Voltage       | 1       | V     | 
|
| 0x100A    | PV Current       | 1/2     | A     | 1 for MI Series, 2 for HM 
Series                             |
| 0x100B    | PV Current       | 1/2     | A     | 1 for MI Series, 2 for HM 
Series                             |
| 0x100C    | Grid Voltage     | 1       | V     | 
|
| 0x100D    | Grid Voltage     | 1       | V     | 
|
| 0x100E    | Grid frequency   | 2       | Hz    | 
|
| 0x100F    | Grid frequency   | 2       | Hz    | 
|
| 0x1010    | PV Power         | 1       | W     | 
|
| 0x1011    | PV Power         | 1       | W     | 
|
| 0x1012    | Today Production | /       | Wh    | 
|
| 0x1013    | Today Production | /       | Wh    | 
|
| 0x1014    | Total Production | /       | Wh    | 
|
| 0x1015    | Total Production | /       | Wh    | 
|
| 0x1016    | Total Production | /       | Wh    | 
|
| 0x1017    | Total Production | /       | Wh    | 
|
| 0x1018    | Temperature      | 1       | °C    | Microinverter internal 
temperature                           |
| 0x1019    | Temperature      | 1       | °C    | Microinverter internal 
temperature                           |
| 0x101A    | Operating Status | /       | /     | 
|
| 0x101B    | Operating Status | /       | /     | 
|
| 0x101C    | Alarm Code       | /       | /     | 
|
| 0x101D    | Alarm Code       | /       | /     | 
|
| 0x101E    | Alarm Count      | /       | /     | 
|
| 0x101F    | Alarm Count      | /       | /     | 
|
| 0x1020    | Link Status      | /       | /     | Communication status with DTU 
|
| 0x1021    | /                | /       | /     | Fixed, 0x07 
|
| 0x1022    | Reserved         | /       | /     | 
|
| 0x1023    | Reserved         | /       | /     | 
|
| 0x1024    | Reserved         | /       | /     | 
|
| 0x1025    | Reserved         | /       | /     | 
|
| 0x1026    | Reserved         | /       | /     | 
|
| 0x1027    | Reserved         | /       | /     | 
|
| 0x1028    | Data Type        | /       | /     | Default, 0x3C 
|
| 0x1029    |                  | /       | /     | 
|

Die Daten können offenbar mit dem entsprechenden 0x03 Kommando 
angefordert werden und aus der entsprechenden 0x03 Antwort entnommen 
werden:

4.2.3 Read Device Data

* Command sending format

| Name             | Length | Value | Remark        |
| ---------------- | ------ | ----- | ------------- |
| Address          | 1      |       | RS485 Address |
| Function Code    | 1      | 0x03  |               |
| Register Address | 2      |       | Big-Endian    |
| Register Count   | 2      |       | Big-Endian    |
| CRC              | 2      |       | CRC16         |

* Command response format (if success)

| Name            | Length | Value | Remark        |
| --------------- | ------ | ----- | ------------- |
| Address         | 1      |       | RS485 Address |
| Function Code   | 1      | 0x03  |               |
| Data Length     | 2      |       |               |
| Data 1          | 2      |       | Big-Endian    |
| Data 2          | 2      |       | Big-Endian    |
| ......          |        |       |               |
| CRC             | 2      |       | CRC16         |

* Command response format (if failed)

| Name            | Length | Value | Remark        |
| --------------- | ------ | ----- | ------------- |
| Address         | 1      |       | RS485 Address |
| Function Code   | 1      | 0x83  |               |
| Wrong Data Code | 1      | 0x01  |               |
| CRC             | 2      |       | CRC16         |

[1] 
https://www.mikrocontroller.net/attachment/552319/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

[isnoAhoy (Gast)]

> Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier
> möchte ich was beitragen. Ein pull-request habe ich erstellt.
>
> Aktueller Stand:
> Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich
> es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station).

Hallo Lukas P., habe mir mal Deinen Code aus dem ahoy github geclont und 
versucht zu deployen.

Folgende Punkte sind mir aufgefallen:

* Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F. 
bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am 
nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die 
Spannung am +3.3V Anschluß des ESP8266 ein.

* das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine 
Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt 
wie die ino Datei.

* ich habe versucht die WiFi und Wechselrichter Daten auf der Setup 
Seite einzutragen. Leider ist das Programm die ganze Zeit schon 
beschäftigt im Hintergrund per nRF24L01+ und vermutlich Dummy 
Adress-Daten an den Hoymiles zu senden und zu empfangen. Dadurch 
verliere ich immer die Verbindung, bevor ich die WiFi und Device Daten 
eingeben kann.
Gibt es eine Möglichkeit das Hauptprogramm (im unkonfigurierten Zustand) 
anzuhalten bzw. eine längere Wartezeit (z.B. 5 Minuten) zwischen den 
Anfragen zu konfigurieren ?

* Alternativ könnte man diese evtl. auch in der defines.h hinterlegen, 
nur habe ich die korrekten define / settings nicht herausgefunden:
#define SSID "meineSSID"
#define PWD "meinPasswort"
#define DEVNAME "ahoy-esp"
#define HOY_ADDR 0x1141 7312 3456

* ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder 
bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73 
01 ?

[Was (Gast)]

Danke @isnoAhoy!

Am Woende werfe ich mal den Lötkolben an.
Mal schauen was ich dem HM1200 entlocken kann.

Ich bin auch an einer Nulleinspeisung interessiert.
Habe noch keinen Plan wie man so etwas erreichen kann.
Ggf. auch ein Projekt hier im Forum unter anderem Thread, oder gibt es 
das gar schon?

Danke für die Zusammenfassung.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> Folgende Punkte sind mir aufgefallen:
>
> * Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F.
> bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am
> nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die
> Spannung am +3.3V Anschluß des ESP8266 ein.

ich sehe aktuell kein Problem. Danke für den Hinweis, ich werde die 
anderen Settings mal ausprobieren. Aktuell kommen die 3.3V aus meinem 
FTDI USB Adpater. Habe auch schon mal extern versorgt, das hat aber 
nichts verbessert.
Was mir aufgefallen ist: Ich bin relativ weit weg vom WR (eine 
Betondecke und 10m durch den Garten). Wenn ich allerdings direkt zum WR 
gehe, bekomme ich keine Pakete mehr. Hier im Keller muss die Antenne 
auch sehr genau liegen.

> * das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine
> Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt
> wie die ino Datei.
>  [...]

Danke für dein Feedback, ich habe eine neue Version eingecheckt, die 
hoffentlich alle deine Probleme beseitigt, hier das commit-log:

- renamed .ino (must be identical to parent folder name)
- build CRC over settings, only if the CRC matches settings are applied
- send command 0x80 (set time was wrong)
- improved crc16 routine
- added statistics for received commands and send statistics (channels 
are not correct for now!)
- receive of commands 0x01, 0x02, 0x03, 0x81 and 0x84 working

[Lukas P. (lumapu)]

Im Anhang mal ein Screenshot der aktullen Verison. Wie im Commit-log 
schon geschrieben, stimmt die Statistik der Kanäle nicht, da diese Info 
nicht synchron erfasst wird, die Statistik der Cmds ist korrekt.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder
> bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73
> 01 ?

Die Seriennummer muss man so angeben, wie sie auf dem WR steht. Nach 
jedem Byte muss ein ":" eingefügt werden, also z.B.

11:61:11:22:33:44

[Hubi (Gast)]

Hallo Lukas P.
ich habe mir mal deinen Code im Git angeschaut, das ist ja super, alles 
sauber in C++.
Mit meiner Programmierung bin ich schon weiter gekommen, auch schon für 
mehrere WR. So ganz gefällt mir das noch nicht, denn ist noch sehr 
RAM-intensiv, da die Konstanten halt alle dort abgelegt sind.
Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen, 
melde dich.

[Ziyat T. (toe_c)]

Hallo
Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?

[Martin G. (petersilie)]

isnoAhoy schrieb:
> In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von
> Registern angegeben,
> hängt das eventuell miteinander zusammen ?

Modbus ist ein eigenes Kommunikationsprotokoll, siehe 
[https://de.wikipedia.org/wiki/Modbus]. Der "Funktionscode 0x03" dort 
bedeutet "Register lesen". Das hat nichts direkt mit unserem CMD=0x03 zu 
tun.

Aber die Infos sind natürlich trotzdem nützlich. Zum Beispiel sehen wir 
anhand der Registerliste, welche Werte die Wechselrichter vermutlich 
liefern können, und was man vermutlich einstellen können sollte.

Und mindestens der 0x80 Befehl ("Uhrzeit setzen") verwendet die gleiche 
CRC16 wie das Modbus Protokoll.

[Martin G. (petersilie)]

lpb schrieb:
>> An welcher Position?
>
> Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in
> dem angehängtem Auszug der dekodierten Daten).

Hallo lpb,

ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in 
meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im 
Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses 
Ergebnis bzw. wie genau fragst Du den WR ab?

[Lukas P. (lumapu)]

Hubi schrieb:
> Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen,
> melde dich.

Danke für dein Lob. Ohne deine Vorarbeit hätte ich das nicht so schnell 
auf die Beine gestellt, danke für die Vorlage =)
Ja ich habe interesse, wie du mich erreichst? - in jedem Git commit 
findet man in den ersten Zeilen die E-Mail des Autors - sofern diese 
richitg angegeben ist:

Einfach ein '.patch' an die URL hängen und schon hast du sie ;-)
https://github.com/grindylow/ahoy/commit/7d2437828830d7825953844d632aed72940d942c

Anbei noch ein Screenshot meiner Darstellung der Werte - ich werde den 
Stand heute noch committen.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in
> das Readme.md auf dem Ahoy Github einchecken.

@petersilie würdest du die Diagramme in Git übernehmen, ich fände das 
super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann 
könnte man bei Fragen immer öfter auf das Repository verweisen.

[Martin G. (petersilie)]

Lukas P. schrieb:
> isnoAhoy schrieb:
>> Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in
>> das Readme.md auf dem Ahoy Github einchecken.
>
> @petersilie würdest du die Diagramme in Git übernehmen, ich fände das
> super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann
> könnte man bei Fragen immer öfter auf das Repository verweisen.

Gute Idee. Hab mal die Diagramme und einen Anfang eines 
Quickstart-Guides hochgeladen:

https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

[lpb (Gast)]

Martin G. schrieb:
> Hallo lpb,
>
> ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in
> meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im
> Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses
> Ergebnis bzw. wie genau fragst Du den WR ab?

Vielen Dank für die Blumen, aber ohne die vielen Hinweise und 
Diskussionen hier hätte ich das sicher nicht hinbekommen.
Im wesentlichen nutze ich das hier geteilte nrf24_sendrcv. Ich habe das 
ganze in der Arduino IDE auf den D1 mini mit einem EPS32 portiert.

Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des 
'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer 
festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine 
Nachricht(en) empfangen habe.
Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal 
3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte.
Je nach der eingestellten 'Wartezeit' habe ich mehr oder weniger oft 
alle 3 Nachrichten von meinem HM600 empfangen. Empirisch ermittelt war 
4ms in meinem Code ein ganz guter Wert.
Ebenfalls habe ich verschiedene Rx Kanäle und Reihenfolgen probiert. 
Dabei habe ich einige nie gesehen und daher wieder verworfen.
Falls das jemand ausprobieren möchte, ich habe das so realisiert:

uint8_t rx_channels[] = {3, 23, 61, 75, 83};
uint8_t rx_chn_num = 5;
uint8_t intvl = 4;
  ...
  // NRF rx/tx handling
  if (millis() >= tickMillis)
  {
    tickMillis += intvl;
    // rx channel switching
    chn_id++;
    if (chn_id >= rx_chn_num)
      chn_id = 0;
    rx_channel = rx_channels[chn_id];
    DISABLE_EINT;
    radio.stopListening();
    radio.setChannel(rx_channel);
    radio.startListening();
    ENABLE_EINT;

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Hallo
> wenn sich jemand interessiert im Anhang
> MI1500 > DTU-pro log

Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC 
Freq. und U_AC) konnte ich schon identifizieren, natürlich alles 
angenommen.
Beim 01er Command (Spalte A, ich weiß nicht ob das ein Command ist) 
sieht es für mich so aus, als gäbe es in Spalte D noch ein Sub-Command.
Wenn Spalte A auf 5A steht bedeutet das wahrscheinlich Fehler oä.

[Lukas P. (lumapu)]

lpb schrieb:
> Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des
> 'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer
> festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine
> Nachricht(en) empfangen habe.
> Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal
> 3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte.

Das ist sehr interessant. Ich habe den Empfang fix auf Kanal 3 stehen 
und gemerkt, dass ich quasi nur Antworten bekommen habe wenn ich auf 
Kanal 61 sende. Ich sende jede Sekunde ein Paket, nach 6 Paketen 
wechsele ich zum nächsten Kanal, aktuell sind das 4 Stück (23, 40, 61 
und 75). Mal beobachten wie es sich die nächsten Tage verhält.

Was ich noch nicht verstehe: Sendest du deine Nachricht mit 0x80-0x84 
commands und bekommst eine 0x83 Nachricht zurück?

Vom HM1200 kann ich folgendes beobachten: Senden von 0x80-0x84 führt zur 
Antwort von 0x01-0x03, 0x81 und 0x84.

[lpb (Gast)]

> Was ich noch nicht verstehe: denSest du deine Nachricht mit 0x80-0x84
> commands und bekommst eine 0x83 Nachricht zurück?

Ich sende jedesmal die 0x80 Zeit setzen Nachricht.
Ich nehme einfach an, dass darauf hin der WR seinen aktuellen Status 
sendet, beim HM600 dann die 0x01, 0x02, und 0x83 Nachrichten.
Mit den anderen Anfragen könnte ich allerdings auch noch mal spielen, 
das habe ich bislang nicht gemacht.

Als nächstes wollte ich noch mal die Antwort-Zeiten und die Kanäle 
auswerten, ob sich da eventuell ein Muster erkennen lässt, denn hin und 
wieder verpasse ich einzelne Antwort-Nachrichten, oder bekomme gar keine 
Antwort auf eine Anfrage. Leider ist es nicht so einfach zu sagen, ob 
das an der SW oder evtl der HF Umgebung liegt.

Die Anzeige in einem Webserver ist übrigens auch sehr schick, ich sende 
meine Daten allerdings an emoncms auf einem Raspberry, das ist dann fast 
so schick wie in der Hoymiles Cloud :)

[Ziyat T. (toe_c)]

Lukas P. schrieb:
> Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC
> Freq. und U_AC) konnte ich schon identifizieren, natürlich alles
> angenommen.

Hallo Lukas
Vielen Dank für deine Bemühungen!
Habe auch die Daten von der V/Freq gefunden.
Allerdings deine Deutung der U_DC, P_DC, AC stimmen leider nicht.

Ich habe im Anhang die neue (meine) Ordnung der Daten, ganz rechts 
siehst du die reale Daten, bei meinen PV's ist die UDC 37-45V.
Ich bin mir sicher dass die Spalte C die MPPT sind:
0xB6/0xB7 > MPPT1 ,2 ports nicht angeschlossen
0xB8/0xB9 > MPPT2 ,2 ports mit PV belegt

ansonsten bin ich leider nicht weiter gekommen, muss mal pausieren ;-)

[Hubi (Gast)]

Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread 
mal gelesen zu haben.
Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter 
der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen 
zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die 
Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88.
Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten:
08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch.

Diese Zahl hinter der 80 scheint mir eine Einstellung für den WR zu 
sein, in welchem Format er senden soll.
Hat jmd schon ähnliche Beobachtungen gemacht?
Vllt ist es auch ein Kennzeichen der DTU, welche sie ist DTU-Prlo oder 
lite.

[Herbert K. (avr-herbi)]

Hubi schrieb:
> Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter
> der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen
> zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die
> Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88.
> Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten:
> 08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch.

Hallo Hubi, wo hast Du das Senden Bitte im Source geändert ?
(Wo die Pakete aufgedröselt werden, weiss ich)
Dann könnte ich das mal mit einem HM-400 und die nä. Tage auch mit 
HM-350 mal testen.

[Hubi (Gast)]

in HM_Packets::GetTimePacket die Zeile
buf[10] = 0x03;

[Herbert K. (avr-herbi)]

Hubi schrieb:

Spannend  :-)
Mit buf[10] = 0x0B;
habe ich beim HM400 Antwort Telegramme 01 und ab und zu 82 bekommen.

Mit buf[10] = 0x03;
bekomme ich beim HM400 die Telegramme 01,02,03,04 als Antwort.

04: aber sehr sehr selten

044060000040C066663FA6CCCD412CEB85AA7F42
044060000040C066663FA6CCCD412CEB85AA366A
044060000040C066663FA6CCCD412CEB85AA366A

01: die Werte sind jetzt statisch und ändern sich nicht mehr

Alles im Allen bisher nur nix wo man DC V,A,W / AC V,A,W / Hz 
wiederfinden kann über analyseWords / analyseLongs

Aber eine Interessante Entdeckung. Vielleicht löst jemand das Rätsel 
noch?

[isnoAhoy (Gast)]

@Lukas P.
Der neue Commit ließ sich übersetzen und nun auch Konfigurieren.
Sowohl die Auswahl einer existierenden WiFi Connection (Liste der 
gescannten WiFi SSIDs) als auch das Speichern des Passworts und des 
Device Names waren am Tablet etwas knifflig.
Es gab keine Ausgabe der Konfiguration (DNS Name / IP) per Serial 
Monitor bzw. Redirect auf die Status Seite (/) und auch nach einem 
Neustart war nicht klar,
ob und wie man den ESP per DNS erreichen kann, bzw. welche DHCP Adresse 
er vom Router bekommen hat.
Meine HM-600 Adresse (sowie die anderen Parameter) wurden aber 
offensichtlich gesetzt, nach einem Hard Reset waren alle noch da.
Aber der Device Name beim Router ESP-429DF0 blieb wie beim ersten Start 
vergeben, eventuell wäre es hier besser den Device Name (ESP-<MAC>) 
einfach anzuzeigen.
Uptime lag am Ende bei 10 Minuten und die Time wurde offensichtlich vom 
NTP Server (o.a.) synchronisiert.
Die /livedata URL ist noch nicht verlinkt und Daten vom HM-600 wurden 
keine empfangen, daher blieb vermutlich auch die /hoymiles Seite leer 
"Every 10 seconds the values are updated".
Ich vermute mal daß die HM-1200 Konfiguration aus Deinem letzten Commit 
die HM-600 Konfiguration von Hubi überschrieben hat ?

@Martin G.
Ja das mit dem ModBus Protokoll hatte ich auch gesehen, aber die Codes 
erschienen mir zu ähnlich zu den Register Adressen.
An anderer Stelle CRC16 und 0x80 scheint es ja auch diverse 
Gemeinsamkeiten zu geben.
Laut dem Abschnitt 4.3.3 Device SN Register List scheint es auch ein 
Register für die Seriennummern der DTU und der WR zu geben.
Ich habe daher mal die DTU Modell und Seriennummern dazu notiert. Das 
scheint ja in der Zukunft evtl. interessant zu werden.
Eventuell könnte man auch den DTU Pro per ModBus ansprechen um die o.g. 
Informationen zu lesen / setzen und dabei das nRF Protokoll mit 
einem/mehreren nRF24L01+ im Promisuous Modus tracen.
So könnten wir das Kommunikationsprotokoll der DTU Pro relativ einfach 
und reproduzierbar analysieren.

Danke auch für die Übernahme der Verbindungsskizze in das GitHub Repo.
Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für 
Diagramme [1] wie ditaa Diagrams through ASCII Art  [2], mermaid-js [3] 
und WaveDrom [4] herum.
Z.B. könnten wir die  hoymiles-format-description.txt einfach umbenennen 
zu hoymiles-format-description.md.
Wenn Du die Diagramme im Markdown rendern möchtest einfach mit folgendem 
einem ditaa Code Tag umgeben.
Ein Export von Markdown zu PDF funktioniert soweit ich weiß aber nur mit 
dem mermaid-js Plugin.

[1] Markdown Diagrams 
https://gist.github.com/blackcater/1701e845a963216541591106c1bb9d3b
[2] ditaa Diagrams through ASCII Art 
https://github.com/stathissideris/ditaa
[3] mermaid-js https://mermaid-js.github.io/mermaid/#/gantt
[4] WaveDrom https://github.com/drom/wavedrom

@Ziyat T.
das weiß ich nicht sicher, laut der gestern von mir aktualisierten 
Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread, 
oder sind das mehrmals die selben (mal Prefix und mal Postfix)?

[1] 1161xxxxxxxx Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
[2] xxxxxxx14456 & xxxxxxx36590 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Eventuell sollten wir die Kürzel der Nutzer aus dem Forum 
dahinterschreiben, damit wir ggf. die Seriennummern besser korrigieren 
können ?
Du kannst auch alles auf einer Seite anzeigen lassen und einfach nach 
1500 suchen, da findest Du dann Thomas B. und Arnaldo G. und Waldemar K.
Zumindest Arnaldo hat auch fünf MI1500. M.E. ist die Bezeichnung MI / HM 
austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter) 
für den Typ Wechselrichter. Ich glaube auf meinem Typenschild / 
Aufkleber am Karton stehen auch beide Bezeichnungen.

[Ziyat T. (toe_c)]

isnoAhoy schrieb:
>
> @Ziyat T.
> das weiß ich nicht sicher, laut der gestern von mir aktualisierten
> Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread,

Hallo isnoAhoy
Danke für die WR-Liste

Ich bin mir ziemlich sicher dass die MI series HW/SW-maessig nicht 
gleich sind, HM 3.gen./MI 2.gen.

MI series:
- untere Limitierung 10%, WR nur als ganzer limitierbar.
- mehrere DTU-ModbusRegister funktionieren nicht, da wahrscheinlich 
nicht im WR vorhanden
HM series:
- untere Limitierung bis 2%, auch port based limitierbar.
- alle Modbus DTU-ModbusRegister funktionieren

Ich bekomme von meinem MI1500 ganz andere antworten (bisher nur, wenn 
ich die DTU-Pro einschalte), bisher konnte ich den MI auch nicht direkt 
ansprechen.

Da ich meiene DTU-Pro über Modbus-RTU selber ansteuere, könnte ich  den 
WR gezielt ansteueren, ich waere bereit sie zu sniffen aber brauche 
HW-maessig hilfe wie ich es machen soll.

[Ziyat T. (toe_c)]

Hallo
Ich habe versucht 2 Tage lang meinen MI1500 zu wecken.
Ich verwende Hubi's SW auf ESP,
habe alle MSGid & CMD Kombination durchgespilet, keine Antwort.

Send... CH40
[15]6370716072228412[81]50  hier 0x15 und 0x81

[0x0-0xFF]6370716072228412[0x0-0xFF]50 Kombinationen

(NRF24 funktioniert, ich sehe WR-Antworten wenn die DTU einschalte)
Hat jemand nen Vorschlag?
Danke

[Hubi (Gast)]

Ist das die letzte Version mit der Routine Serial2RadioID?
Seriennummer auch richtig eingetragen, also
Seriennummer zb 114172607952 dann

#define SerialWR       0x114172607952ULL
uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR);

in der Settings.h

[Ziyat T. (toe_c)]

Hubi schrieb:
> Ist das die letzte Version mit der Routine Serial2RadioID?
> Seriennummer auch richtig eingetragen, also
> Seriennummer zb 114172607952 dann
>

> #define SerialWR       0x114172607952ULL
> uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR);
>

> in der Settings.h

Ja, genau
#define SerialWR      0x106163707160ULL        //
uint64_t WR1_RADIO_ID           = Serial2RadioID (SerialWR);    //
//#define DTU_RADIO_ID  ((uint64_t)0x1234567801ULL)
//10F8---72228412  12842272
#define DTU_RADIO_ID ((uint64_t)0x1284227201ULL)

[Maik R. (bastelbarney)]

Hi isnoAhoy,
Du schriebst im Beitrag #7042229:
> M.E. ist die Bezeichnung MI / HM
> austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter)
> für den Typ Wechselrichter.

Auf der Seite https://www.hoymiles.com/de-eu/microinverter-single-phase 
ziemlich in der Mitte wird zwischen beiden Modellreihen unterschieden:

"MI-Mikro-Wechselrichter
Unsere MI-Mikro-Wechselrichter sind die kompaktesten Modelle in unserem 
Sortiment und ideal für jede Anlage."

vs.

"HM-Mikro-Wechselrichter
Mit einem Gerät der HM-Serie erhalten Sie Blindleistungsregelung und 
eine bessere Datenverbindung dank einer externen Antenne."

-

Ich lese hier schon eine Weile sehr erfreut mit und werde meinen heute 
gelieferten HM-1500 gerne auch sniffen und die Mitschnitte hier 
verfügbar machen, sobald ich die Panels bekommen und aufs Dach gebracht 
habe. Und sofern ich mich durchringe, den Gateway-Stick für 90€ zu 
kaufen - bin da noch unentschieden :-)

Maik

[Herbert K. (avr-herbi)]

Hallo,
ist jemand da dran, die Anzahl der WR zu erweitern ?
Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die 
Serielle (war ja im Prinzip schon fast drin, aber auskommentiert).
Hab nun heute Nachschub bekommen HM-350. Dafür fliegen andere Hersteller 
raus, die nicht so tun, wie ich es erwartet habe. Wenn ich anfange im 
Code herumzuwurschteln, wird jeder "C" Programmierer die Hände über den 
Kopf zusammenschlagen vermute ich.
Eine Idee dazu: Solange wir nicht wissen, wie man aus den S/N oder den 
Telegrammen auf das Modell inkl. HW Vers. / SW Vers. kommt, wären 
Tabellen sicher nicht schlecht:
1. Tab: Alle bisher bekannten Typen von WR., Anzahl MPPT Tracker, Anzahl 
DC-Inputs
2. Tab: Länder Kennungen (gibt scheinbar auch je nach Vorschriften in 
den Ländern verschiedene Funktionen / Verhaltensweisen. EU und 
Österreich für den Anfang  :-)
3. Tab: Tabelle mit S/N, Modell (aus Tab 1), HW Vers., SW Vers., Land
Ist nur mal so eine Idee ....

Ergänzung: Eben mal einen alten WR rausgeworfen (der auch schon 
abgeschaltet hatte), S/N von einem 400 auf eine neue S/N vom 350 
geändert. :-)  Funktioniert sofort  :-)  P-Total = 0.0  :-)  und der 
350er speisst sogar noch ein. Nun kann ich ohne schlaflose Nacht träumen 
:-)

[Hubi (Gast)]

Herbert K. schrieb:
> ist jemand da dran, die Anzahl der WR zu erweitern ?
> Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die
> Serielle (war ja im Prinzip schon fast drin, aber auskommentiert).

Ich habe da schon ein Konzept entwickelt (funzt auch für minsdestens 2 
WR, auch mit Arduino, obwohl wenig Speicher) und Lukas P. will das (oder 
ähnlich) in seine ESP-Version auf der ahoy-Seite einbauen.
Also, etwas Geduld, und das wird schon was tolles.

[Petra-Kathi (Gast)]

Hallo zusammen,

als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5 
anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden) 
und würde ihm gerne ein wenig auf die Finger gucken. Ich habe die 
bisherigen 3 Seiten weitestgehend durchgelesen und dabei zu verstehen 
versucht, über was ihr schreibt, habe dabei aber ziemliche 
Verständnisprobleme.

Ich habe einen Raspi 3, einen alten Arduino Mega und einen ESP32 und auf 
allen schon ein paar Sachen in Richtung Midi + BTLE und ein wenig 
Anwendungsprogrammierung (Zusammenführen von Sensorsignalen und daraus 
rechnerisch Meta-Informationen erzeugen) gemacht. Das Jonglieren mit / 
Bitfieseln von irgendwelchen sonstigen Protokollen / ModBus ist mir 
allerdings noch unbekannt/fremd.

Mit den Voraussetzungen: Wo kann ich mich einigermaßen linear in die 
aktuelle Problematik einlesen? Wie kann ich euch ggf. z.B. durch 
Datensammeln unterstützen?

Viele Grüße aus Aachen,
Petra

[Maik R. (bastelbarney)]

Petra-Kathi schrieb:
> Wo kann ich mich einigermaßen linear in die aktuelle Problematik einlesen?
> Wie kann ich euch ggf. z.B. durch Datensammeln unterstützen?

https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
und
https://github.com/Yveaux/NRF24_Sniffer

Sind für mich die Einstiege. Ein nRF24 Modul (5€) ist auf eBay bestellt, 
ein mini-DUT für 88€ auch.

HTH,
Maik

[Ziyat T. (toe_c)]

@Lukas P.(lumapu)
@Hubi

Hallo
Ich habe heute die 
https://github.com/grindylow/ahoy/tree/main/tools/esp8266 geladen und 
laufen lassen. Ich finde die SW sauber!

Mit Hubi's SW konnte ich, wenn ich die DTUpro einschaltete, die DTUpro 
msg's 00/01 empfangen.(siehe 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")

Mit der ahoy SW kann ich nichts empfangen, fand ich merkwürdig.

Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte 
ich:
mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
Serial.println("sent packet: #" + String(mSendCnt));
dumpBuf(mSendBuf, size);


DTU und WR Adressen sind richtig:
CH: 23 sent packet: #15
1563707160722284128352
CH: 23 sent packet: #16
1563707160722284128253
CH: 23 sent packet: #17
1563707160722284128455
CH: 23 sent packet: #18
15637071607222841280b06263d9e6000500002ad398
CH: 40 sent packet: #19
1563707160722284128150

[Petra-Kathi (Gast)]

Hallo Maik,

danke für deine Einstiegshilfe!

> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Hierüber bin ich noch auf die Langstory 
https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt 
gestoßen und habe mir diese erst mal durchgelesen.

Was ich daraus und aus deinem zitierten
> https://github.com/Yveaux/NRF24_Sniffer
noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features 
des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den 
Beiden dieses Sniffer-Modul ebenfalls noch erforderlich?

Tschüssi,
Petra

[SUNPOWER (Gast)]

Petra-Kathi schrieb:
> noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features
> des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den
> Beiden dieses Sniffer-Modul ebenfalls noch erforderlich?

ja; DU BENÖTIGST EINEN NRF

[Peter L. (leliep)]

SUNPOWER schrieb:
> Petra-Kathi schrieb:
>> noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features
>> des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den
>> Beiden dieses Sniffer-Modul ebenfalls noch erforderlich?
>
> ja; DU BENÖTIGST EINEN NRF

Wichtig: einen mit “Plus” (nRF24L01+)

[IsnoAhoy (Gast)]

@Lukas P. (lumapu)
Danke für die neuen Versionen auf Deinem github repo ich habe sowohl die 
von Dir mit HM-1200 als auch die von in grindylow gemergte Version 
versucht. Ich bekomme leider keine Antworten mehr vom HM-600. Was/wo 
sollte ich untersuchen. Wie gesagt mit Hubis Version vom 13.4. hat es 
funktioniert ?

@Mail & @Ziyat,
ja da habt ihr wohl Recht. Ob sich noch mehr geändert hat von 
2.Generation MI zu 3.Gen HM müsste man evtl durch Fotos anhand der FCCID 
oder eigenes Begutachten des Mainboards in Erfahrung bringen. Eventuell 
gibt es ja auch eine Verbesserung von nRF24L01 zu nRF24L01+ o.a. was 
eine andere Datenrate erfordern würde ?
Ich hatte auch schon vermutet dass die DTU pro evtl. einen nRF51/2 MCU 
verbaut hat da sich damit scheinbar mehr Wechselrichter abfragen lassen.
@Ziyat willst Du Deine mal aufschrauben und uns Bilder schicken ?

[Lukas P. (lumapu)]

@IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git 
geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat 
mir hier sehr guten Input gegeben, wir versuchen das ganze so 
Leichtgewichtig wie möglich aufzusetzen.

Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die 
alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie 
ist eine gute Basis für sowas.

Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine 
C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und 
dynamisch ist, dass sie auch auf z.B. einem proMini läuft und 
gleichzeitig mehrere Wechselrichter unterstützt.

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte
> ich:
> mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
> Serial.println("sent packet: #" + String(mSendCnt));
> dumpBuf(mSendBuf, size);

Damit solltest du nur die gesendeten Pakete sehen, die empfangenen 
kannst du in dieser Zeile anzeigen lassen: 
https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97

Petra-Kathi schrieb:
> als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5
> anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden)

Ich habe vor mehr als 4 Module an meinem HM1200 zu betreiben, testweise 
habe ich immer mal wieder 5 dran. Zwei sind parallel mit Dioden an einem 
Anschluss, der Screenshot spricht für sich. (Channel 3)

[Ziyat T. (toe_c)]

@Lukas P.
> schrieb:
> Damit solltest du nur die gesendeten Pakete sehen, die empfangenen
> kannst du in dieser Zeile anzeigen lassen:
> 
https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97
>

Ich habe die Version ohne MQTT vor 4 Tagen, ich denke, ich habe die 
richtige Zeile auskommentiert:

void app::loop(void) {
    Main::loop();
    if(!mBufCtrl->empty()) {
        uint8_t len, rptCnt;
        NRF24_packet_t *p = mBufCtrl->getBack();
//toe
        mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
//toe



Ich werde mal die Innereien der DTU-Pro mal anschauen.

[Petra-Kathi (Gast)]

Peter L. schrieb:
> Wichtig: einen mit “Plus” (nRF24L01+)

Danke für den Hinweis. Dingens ist bereits bestellt.

Tschüssi,
Petra

[isnoAhoy (Gast)]

Hallo Lukas P.
danke für die Bestätigung, daß es aktuell noch nicht mit dem HM-600 
geht.
Ich hatte das schon vermutet, da es bisher nur eine hm1200Decode.h gibt.
Die Punkte bzgl. der Software hatte ich auch eher als ein Review 
verstanden,
falls Du / andere das irgendwie noch aufhübschen wollt.
Bzgl. Speicherverbrauch und "leichtgewichtig" ist mir aufgefallen,
daß die html/h/*.h Dateien zwar in einer Zeile untergebracht sind,
aber immer noch sehr viele Leerzeichen für die Einrückungen enthalten.
Evtl. könnte man das mit FileConv.exe oder sed unter Linux noch etwas 
anders gestalten ?
Ich nehme an da die {VARIABLE} Ausdrücke ersetzt werden sollen,
kann man die HTML Seiten auch nicht im Flash Memory des ESP speichern ?

[Lukas P. (lumapu)]

Hallo isnoAhoy,

ja ich fände es super das ganze noch aufzuhübschen. Das ist das erste 
Mal, dass ich was in dieser Richtung veröffentlich habe - ich habe 
diesen ESP (app und main Klasse) schon in diversen Projekten verwendet 
und es hat sich immer gezeigt, dass man es schnell für ein neues Projekt 
verwenden kann. Bisher habe ich mich geweigert Tasmota irgendwo zu 
installieren - ich mach das selbst ;-), z.B für den Sonoff-POW-R2 und 
RGB-LED Streifen

Das Fileconv.exe habe ich mir aus der Not gebaut und es kürzt der 
einfachheit halber alle Whitespaces auf ein Space ein. Ich habe mich 
nicht näher mit der Thematik auseinandergesetzt und bin hier offen für 
Input. Schön ist halt aktuell nur ein Binary zu haben und es ist alles 
drin.

Die geschweiften Klammern sind die Bereiche, die ich im Code dann 
ersetze, richtig z.B.

html.replace("{VERSION}", mVersion);

[Peter L. (leliep)]

Lukas P. schrieb:
> @IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git
> geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat
> mir hier sehr guten Input gegeben, wir versuchen das ganze so
> Leichtgewichtig wie möglich aufzusetzen.
>
> Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die
> alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie
> ist eine gute Basis für sowas.
>
> Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine
> C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und
> dynamisch ist, dass sie auch auf z.B. einem proMini läuft und
> gleichzeitig mehrere Wechselrichter unterstützt.

Deinen Code teste ich gleich morgen, wenn es wieder hell ist...

Da ist ein Fehlerchen: 
https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/mqtt.h#L54

[Lukas P. (lumapu)]

Peter L. schrieb:
> Da ist ein Fehlerchen:

ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke

[isnoAhoy (Gast)]

Hallo Lukas P.,

Prinzipiell ist es bei ESP8266 und ESP32 vorteilhaft größere Strings im 
PROGMEM [2] (bis zu 4 MB Flash Memory) abzulegen.
Das ist zwar nicht ganz so schnell und flexibel wie das normale RAM / 
ROM aber dafür gibt es eben viel Platz.

Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:

static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"

Ich habe mal nachgesehen, hier ist ein Beispiel von Sebastian Glahn wie 
man string.replace() und FPSTR() für das WebServer Modul verwenden kann 
[2].

String body = FPSTR(HTTP_BODY);
body.replace("{{variable}}", configuration.variable);
page += body;

[1] https://arduino-esp8266.readthedocs.io/en/latest/PROGMEM.html
[2] 
https://blog.tldnr.org/2017/10/25/how-to-deliver-larger-web-pages-with-an-esp8266/

[Martin G. (petersilie)]

isnoAhoy schrieb:
> Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für
> Diagramme [1] wie ditaa Diagrams through ASCII Art  [2], mermaid-js [3]
> und WaveDrom [4] herum.
> Z.B. könnten wir die  hoymiles-format-description.txt einfach umbenennen
> zu hoymiles-format-description.md.

Danke für Deine Arbeit. Die Nachfragen nach einem "zusammenhängenden" 
Dokument häufen sich ja (macht auch Sinn).

Ich frage mich, ob wir so etwas vielleicht mit Hilfe von readthedocs.io 
aufbauen können?

[Peter L. (leliep)]

Lukas P. schrieb:
> Peter L. schrieb:
>> Da ist ein Fehlerchen:
>
> ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke

Sowas kommt vor, kenne ich aus eigener Erfahrung ;-)
Nach Korrektur funktioniert es mit meinem MQTT-Broker perfekt!

Auch die Daten des HM-1200 mit nur drei Panels sehen gut aus; vielen 
Dank für die gute Arbeit!

[Marcus (Gast)]

Ich habe meine NRF-Module nun erhalten.

Ich habe mich die ganze Zeit gewundert, warum 
[[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen 
Empfang brachte, mit Hubis Code jedoch alles funktioniert.
Verkabelung ist nach diesem Schema: 
[[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]]

Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:

//-------------------------------------
// PINOUT
//-------------------------------------
#define RF24_IRQ_PIN        (D3)
#define RF24_CE_PIN         (D4)
#define RF24_CS_PIN         (D8)

Ist das so gewollt (GIT Verkabelung vs. Code)?

Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten 
(also keine AC Spannung/Energie/Frequenz)
Das ist die Statistik nach einigen Minuten:

CMDs:
0x01: 18
0x02: 0
0x03: 0
0x81: 55
0x84: 0
other: 13

CHANNELs:
23: 0
40: 9
61: 44
75: 33

@Herbert K.
Welche Erweiterungen hast Du für den 400er denn vorgenommen?

[Marcus (Gast)]

Lukas P. schrieb:
> Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die
> alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie
> ist eine gute Basis für sowas.

Eine Integration in Tasmota wäre super - würde mich auch daran mit einem 
POC versuchen, sobald ich einen halbwegs lauffähigen Code mit meinem 
HM-400 hinbekomme.

[Herbert K. (avr-herbi)]

Marcus schrieb:
> Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten
> (also keine AC Spannung/Energie/Frequenz)
> Das ist die Statistik nach einigen Minuten:
>

CMDs:
> 0x01: 18
> 0x02: 0
> 0x03: 0
> 0x81: 55
> 0x84: 0
> other: 13
> 
> CHANNELs:
> 23: 0
> 40: 9
> 61: 44
> 75: 33

> @Herbert K.
> Welche Erweiterungen hast Du für den 400er denn vorgenommen?

Ich bekomme nur "01", "81" (keine Ahnung wozu die gut sind) und ab und 
zu - sehr selten - "82" Antworten für 350/400 die sinnig sind nach den 
bisherigen Analysen.
02,03,04,84 hab ich nicht mit Hubis Vorarbeit (alter Code).
In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur 
und Unbekanntes

[Ziyat T. (toe_c)]

Marcus schrieb:

> Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:
> [c]//-------------------------------------
> // PINOUT
> //-------------------------------------
> #define RF24_IRQ_PIN        (D3)
> #define RF24_CE_PIN         (D4)


Habe auch erst heute gemerkt ;-)

[Mich@ (Gast)]

Hallo Leute,
Ich verfolge die Entwicklung der selbstbau DTU schon eine Weile. Großes 
Lob an die Macher der Software. Nun wollte ich auch mal meine beiden 
Wechselrichter belauschen. Die Software ist auf dem ESP das Webinterface 
läuft aber leider bekomme ich keine Verbindung zum Funkmodul. Ich denke 
es liegt wie oben beschreiben an den falschen Pins in der Firmware. Wenn 
ich die Pins in der defines.h ändere kann ich die Firmware nicht mehr 
auf den ESP laden da es Fehlermeldungen gibt. Ist es möglich das jemand 
eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP 
gebügelt werden muss?

Vielen Dank

[Marcus (Gast)]

Herbert K. schrieb:
> In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur

Aha, dann werde ich mir das mal ansehen - kannst Du Deine 
"Entschlüsselung" hier mitteilen? Unter 
[[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]] 
ist es noch nicht zu finden.

Ergänzend folgende Erfahrungen mit dem HM-400 und diesen Modulen 
[[https://www.amazon.de/dp/B06XJN417D]]:

Noch mal etwas Statistik (ESP8266-Code)

CMDs:
0x01: 490
0x02: 0
0x03: 0
0x81: 0
0x84: 0
other: 227

CHANNELs:
23: 2
40: 494
61: 186
75: 3

Zur Reichweite - das Modul ist hier ca. 30-40m über 2 Wände zum WR 
entfernt. Also ich finde das sehr gut.

Was mich noch interessieren würde - es gibt ja immer diese P1 und P2 
Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen 
dann nicht 2 bei einem HM-1200?
Und warum habe ich bei meinem HM-400 (1 Panel) einen Wert bei P2 von 0 
bei der DC-Spannung, aber unplausible Werte bei Strom und Leistung? Die 
Werte bei P1 sind plausibel.

[isnoAhoy (Gast)]

Hallo Marcus,

> Ich habe mich die ganze Zeit gewundert, warum
> [[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen
> Empfang brachte, mit Hubis Code jedoch alles funktioniert.
> Verkabelung ist nach diesem Schema:
> [[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]]

> Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:
> //-------------------------------------
> // PINOUT
> //-------------------------------------
> #define RF24_IRQ_PIN        (D3)
> #define RF24_CE_PIN         (D4)
> #define RF24_CS_PIN         (D8)

> Ist das so gewollt (GIT Verkabelung vs. Code)?

Danke für das Auffinden des Fehlers, ich habe mich ja auch schon 
gewundert.
Die Diagramme hatte ich für Hubis Source Code gemacht und Lukas hatte 
derweil
den  Source Code mit den WebSeiten angepaßt und hochgeladen.
Auf die Idee die RF Pins zu überprüfen bin ich leider nicht gekommen.

Ach ja die aktuelle github Version scheint nur HM1200 zu unterstützen.
Der Decoder für HM600 und HM400 etc. scheint noch zu fehlen.

@Lukas P., wollen wir die Anpassung im Code machen oder soll ich neue 
Diagramme generieren ?

[Lukas P. (lumapu)]

Hallo,

ich werde die Pins konfigurierbar machen und den default im Source auf 
die Diagramme anpassen. Dann muss man im besten Fall keine Änderungen am 
Code machen. Mein Code passt aktuell zu meiner Hardware.

Den HM600 unterstützt meine Firmware schon fast, ich habe es in einen 
dev Branch auf meinem github Account und werde es sobald ich es für gut 
befinde ins Hauptrepository mergen. Gefühlt bin ich fast schon soweit.

Marcus schrieb:
> Was mich noch interessieren würde - es gibt ja immer diese P1 und P2
> Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen
> dann nicht 2 bei einem HM-1200?

Wir haben das alles selbst ermittelt, du kannst gerne Änderungen 
vorschlagen bzw. diese ermitteln. Im jeweiligen Code gibt es eigentlich 
immer eine Möglichkteit sich die Rohen Daten ausgeben zu lassen.

Mich@ schrieb:
> Ist es möglich das jemand
> eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP
> gebügelt werden muss?

könnte man doch in Github über Releases machen, allerdings denke ich, 
dass wir noch viel zu früh im Projekt stehen um es Release zu nennen.

Marcus schrieb:
> würde mich auch daran mit einem
> POC versuchen

was ist ein POC?

[Marcel A. (a-marcel)]

Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern 
das es für esp8266 und esp32 geht.

> Marcus schrieb:
>> würde mich auch daran mit einem
>> POC versuchen
>
> was ist ein POC?
Proof of concept

Marcel

[Lukas P. (lumapu)]

Marcel A. schrieb:
> Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern
> das es für esp8266 und esp32 geht.

finde ich super! Verwende am besten als Basis meinen aktuellen 
Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen 
veröffentlichten neuen Stand in main-Branch.

[Silvio R. (silre)]

Hallo zusammen,
ich finde das ein super interessantes Projekt.
Eine Frage wird der HM-700 auch unterstützt werden?

[Marcus (Gast)]

Zur Auswertung/Datenanalyse:

Ich habe mich nochmal durch den Thread gewühlt und folgende Theorie für 
meinen HM-400 und damit wohl "Single"-Wechselrichter - das kann ich an 
einen HM-300, wenn ich vor Ort bin, mal prüfen.

Single-WR senden keine 02er (cmd / Byte 9) Nachrichten, diese senden 
vermutlich nur WR mit >= 2 Panels. Bei WR mit nur einem Panel stecken 
die (bisher erkannten) Daten in folgenden Nachrichten-Bytes (vieles IMHO 
schon bekannt, aber es hier jedenfalls "verlorengegangen": 
[[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]]).

cmd 01 =>
12/13: DC-Spannung, Divisor 10
14/15: DC-Strom, Divisor 100
16/17: DC-Leistung, Divisor 10
18/19: unbekannt, bei mir immer 0
hier ist IMHO bei WR mit >= 2 Panels die DC-Spannung des 2. Panels enthalten
20/21: Gesamtleistung kWh, Divisor 1000 - (mir) unklar ob DC/AR Wert
hier ist IMHO bei WR mit >= 2 Panels der DC-Strom des 2. Panels enthalten
22/23: tägliche Leistung Wh, Divisor 1? - (mir) unklar ob DC/AC Wert
hier ist IMHO bei WR mit >= 2 Panels die DC-Leistung des 2. Panels enthalten
24/25: Spannung, Divisor 100

cmd 82 =>
10/11: Frequenz, Divisor 10
20/21: Temperatur, Divisor 10

Einen GIT-Account habe ich. Könnte o.g. Format-Beschreibung ergänzen. 
Diese müsste nach meiner Vermutung dann aber nach WR-Bauart (Anzahl 
Panels) unterscheiden.
Für einen HM-400 sind somit erstmal die wesentlichsten Daten bekannt. 
Das mit den Leistungswerten (Gesamt/Tag) will ich selbst noch mal bei 
mir verifizieren.

[Martin P. (mpolak77)]

Hallo Markus,

ich fände es auch gut, das Wissen wo Zentral zu sammeln.
Zum Thema HM-400/350 habe ich am 9.4 gepostet:
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")

Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut)

01:
2bytes unbekannt "1"
2bytes dc_volt  / 10
2bytes dc_amps  / 100
2bytes dc_power / 10
4bytes Total_w
2bytes Daily_w
2bytes ac_volt / 10

82:
2bytes ac_freq / 100
2bytes ac_power / 10
2byte  unbekannt "0"
2bytes ac_current / 100
2byte  unbekannt  "1000" vielleicht /10 Power Factor in %?
2bytes temp / 10
2bytes unbekannt ansteigend
2bytes random

Die Total Werte scheinen immer 4byte Werte zu sein.
Das muss wohl bei HM-600/700 auch so sein .... allerdings geht sich das 
dort nicht so einfach aus

[Marcel A. (a-marcel)]

Lukas P. schrieb:
> Marcel A. schrieb:
>> Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern
>> das es für esp8266 und esp32 geht.
>
> finde ich super! Verwende am besten als Basis meinen aktuellen
> Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen
> veröffentlichten neuen Stand in main-Branch.

Ich hatte mir bisher nur das Repo https://github.com/grindylow/ahoy 
angeschaut und da gibt es keinen Dev Branch. Welchen Code meinst du ?

[Lukas P. (lumapu)]

Da ich nicht der Eigentümer des Hauptrepositories bin habe ich einen 
Fork in meinem Account. Ich verlinke es nicht, da das Hauptrepository 
die Referenz für alles bleiben soll. Suche einfach nach dem Fork (auf 
der rechten Seite unter "About") von "lumapu" und dort im "dev" Branch.

[Marcus (Gast)]

Martin P. schrieb:
> ich fände es auch gut, das Wissen wo Zentral zu sammeln.

Habe das ergänzt und einen Pullrequest (PR) im git ausgelöst.
Zu:

4bytes Total_w
2bytes Daily_w

1. ist das eigentlich die Leistung DC oder AC?
2. Total_w sind doch auch nur 2 Bytes, oder?
Siehe hier (PR) unter cmd 01: 
[[https://github.com/grindylow/ahoy/pull/7/commits/dfa7975fedaa3993bd3655aa52bdaa83614dbac4]]

[Martin P. (mpolak77)]

Marcus schrieb:
> 1. ist das eigentlich die Leistung DC oder AC?

Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher, 
dass es DC ist: der HM400 hat daily/total nur einmal .... der 2-port 
HM600 hat diese Werte je 2x (wie die DC Daten)

> 2. Total_w sind doch auch nur 2 Bytes, oder?
Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil 
die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter 
oben hat es Herbert K. schon gezeigt, dass es so ist.

[Marcus (Gast)]

Martin P. schrieb:
>Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher,
>dass es DC ist:
Wenn es aber die Leistungswerte für DC sind - gibt es die Gesamtwerte 
für AC gar nicht? Pro Panel mag das ja interessant sein, aber die Summe 
ist eben m.E. nur näherungsweise gleich der Summe AC seitig (beim 
Wandeln entstehen ja auch noch "Verluste") - oder wird das ggf. mit 
einem Faktor abgebildet, der weniger Bytes benötigt, als nochmal 2+4 
Bytes für AC zu benötigen (Spekulation).
Die momentane Leistung für AC ist ja inzw. bekannt - fehlt irgendwie 
Ptotal und Pdaily für AC.

> Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil
> die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter
> oben hat es Herbert K. schon gezeigt, dass es so ist.

Ahhh - das hatte ich übersehen - hab mich schon immer über die ständigen 
Nuller gewundert in den vorderen 2 Bytes - ich bin noch nicht über 65535 
Wh ;-). Muss das in meiner Beschreibung noch korrigieren. Für den HM-400 
habe ich jetzt alles sauber aufgeschrieben und versuche es in das GIT 
einzuchecken.

[Lukas P. (lumapu)]

Hallo zusammen,

es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist 
die 0.2.4
Sie bassiert auf dem Konzept von Hubi, Vielen Dank nochmal. Wir haben 
weitere Ideen, die dann in die nächste Version einfließen werden.

Das sollte möglich sein:
- mehrere Wechselrichter, aktuell sind per define 3 voreingestellt
- verschiedene Wechselrichter, aktuell ist zwischen HM600 und HM1200 die 
Wahl
- Pinout kann konfiguriert werden, voreingestellt ist das des Wemos 
D1mini
- die Konvertierung der HMTL Seiten passiert jetzt mit python und sie 
werden im PROGMEM abgelegt
- der code wurde soweit verändert, dass prinzipiell auch eine 'einfache' 
Portierung auf den proMini (328p) denkbar ist
- ein MQTT client wurde eingebaut um die Werte woanders zu visualisieren 
(z.B. ioBroker)

Über Feedback und Tests würde ich mich freuen, viel Spaß mit der neuen 
Firmware!

Im Anhang habe ich mal meinen Build gehängt, damit man auch ohne 
Kompilieren auf die neue Version updaten kann - mal sehen ob das klappt.

[Heinz R. (heijz)]

Hallo Lukas,

Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur 
den unten gezeigten Output


Der D1- Mini lief schon mal mit einem viel weiter oben im Thread 
gezeigten Programm

Ich habe ihn zum Test auch mal mit einem blank-File geflasht - leider 
auch erfolglos

Viele Grüße


 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00057330
~ld

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Soft WDT reset

>>>stack>>>

ctx: cont
sp: 3ffffb40 end: 3fffffc0 offset: 01a0
3ffffce0:  00000000 3ffe901c 3ffeeff0 40204b01
3ffffcf0:  00000000 00000000 00000000 00000000
3ffffd00:  00000000 00000000 00000000 00000000
3ffffd10:  00000000 00000000 00000000 00000000
3ffffd20:  00000000 00000000 00000000 00000000
3ffffd30:  00000000 00000000 00000000 00000000
3ffffd40:  00000000 00000000 00000000 00000000
3ffffd50:  00000000 00000000 00000000 00000000
3ffffd60:  00000000 00000000 00000000 00000000
3ffffd70:  00000000 00000000 00000000 00000000
3ffffd80:  00000000 00000000 00000000 00000000
3ffffd90:  00000000 00000000 00000000 00000000
3ffffda0:  00000000 00000000 00000000 00000000
3ffffdb0:  00000000 00000000 00000000 00000000
3ffffdc0:  00000000 00000000 00000000 00000000
3ffffdd0:  00000000 00000000 00000000 00000000
3ffffde0:  00000000 00000000 00000000 00000000
3ffffdf0:  00000000 00000000 00000000 00000000
3ffffe00:  00000000 00000000 00000000 00000000
3ffffe10:  00000000 00000000 00000000 00000000
3ffffe20:  00000000 00000000 00000000 00000000
3ffffe30:  00000000 00000000 3ffe0000 40212768
3ffffe40:  00000000 3ffe901c 3ffeeff0 402080cb
3ffffe50:  3fff0f84 feefeffe 402045cc 40212848
3ffffe60:  40207694 00000000 3ffeeff0 00000000
3ffffe70:  40206f9c 00000000 3ffeeff0 feefeffe
3ffffe80:  feefeffe feefeffe feefeffe feefeffe
3ffffe90:  3fff0054 3fff0054 0000000f feefeffe
3ffffea0:  feefeffe feefeffe feefeffe 3ffef324
3ffffeb0:  3ffeeff0 00000000 3ffeeff0 402033ba
3ffffec0:  feefeffe feefeffe feefeffe feefeffe
3ffffed0:  feefeffe feefeffe feefeffe feefeffe
3ffffee0:  feefeffe feefeffe feefeffe feefeffe
3ffffef0:  feefeffe feefeffe feefeffe feefeffe
3fffff00:  feefeffe feefeffe feefeffe feefeffe
3fffff10:  feefeffe feefeffe feefeffe feefeffe
3fffff20:  feefeffe feefeffe feefeffe feefeffe
3fffff30:  feefeffe feefeffe feefeffe feefeffe
3fffff40:  feefeffe feefeffe feefeffe feefeffe
3fffff50:  feefeffe feefeffe feefeffe feefeffe
3fffff60:  feefeffe feefeffe feefeffe feefeffe
3fffff70:  feefeffe feefeffe feefeffe feefeffe
3fffff80:  feefeffe feefeffe feefeffe 3ffef324
3fffff90:  3fffdad0 00000000 3ffeeff0 4020458b
3fffffa0:  feefeffe feefeffe 3ffef310 4021038c
3fffffb0:  feefeffe feefeffe 3ffe85d8 40100e65
<<<stack<<<

[Marcus (Gast)]

Lukas P. schrieb:
> es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist
> die 0.2.4

Würde ich gerne auch testen, habe aber nur einen HM-400. Da ich heute eh 
im Thema stecke, hier die Tabelle aller bisher bekannten Werte um den 
400er ggf. leicht zu ergänzen:

//-------------------------------------
// HM400 (vermutlich auch HM-350 und HM-300)
//-------------------------------------
const byteAssign_t hm400assignment[] = {
    { FLD_UDC, UNIT_V,  CH1, CMD01, 14, 2, 10  },
    { FLD_IDC, UNIT_A,  CH1, CMD01, 16, 2, 100 },
    { FLD_PDC, UNIT_W,  CH1, CMD01, 18, 2, 10  },
    { FLD_YT,  UNIT_KWH,CH2, CMD01, 20, 4, 1000 },
    { FLD_YD,  UNIT_KWH,CH2, CMD01, 24, 2, 1000 },
    { FLD_UAC, UNIT_V,  CH0, CMD01, 26, 2, 10  },
    { FLD_F,   UNIT_HZ, CH0, CMD82, 12, 2, 100 },
    { FLD_PAC, UNIT_W,  CH0, CMD82, 14, 2, 10  },    
    { FLD_IAC, UNIT_A,  CH0, CMD82, 18, 2, 100 },
    { FLD_T,   UNIT_C,  CH0, CMD82, 22, 2, 10  }
};

Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du 
aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf 
Deine komme.
Beispielnachricht:

95 7310xxyy 7310xxyy 010001 0198 004001060000FA7B00190922F8C75E 1

Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0 
anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC 
Spannung des 1. Moduls. Ggf. muss das noch angepasst werden.

[Ziyat T. (toe_c)]

Lukas P. schrieb:
> Hallo zusammen,
>
> es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist
> die 0.2.4
Danke für die Arbeit!

Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR 
als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird? 
(WR Library?)
Wollte drauf hinweisen, dass das MI-Series Datenformat völlig 
verschieden ist (CMD,MID,Ports etc.)

Bisherige Erkentnisse vom MI1500, siehe Anhang

[Lukas P. (lumapu)]

Marcus schrieb:
> Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du
> aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf
> Deine komme.
> Beispielnachricht:95 7310xxyy 7310xxyy 010001 0198
> 004001060000FA7B00190922F8C75E 1
> Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0
> anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC
> Spannung des 1. Moduls. Ggf. muss das noch angepasst werden.

Deine Definition habe ich mal eingebaut und commited. Dabei habe ich 
noch geringfügige Änderungen gemacht. Aufgefallen ist mir, dass für den 
HM1200 alle Idizes ungerade sind, deine sind alle gerade.
Meine Zählweise ist so:
Byte 0 = cmd
Byte 1 .. x Daten

Ich wollte das durch diesen Kommentar (über den Definitionen) 
ausdrücken, evtl. muss man es umformulieren.

/**
 *  indices are built for the buffer starting with cmd-id in first byte
 *  (complete payload in buffer)
 * */

Die Kanäle habe ich wie folgt aufgebaut:
CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten
CH1-CH4: je nach Wechselrichter die Anschlüsse für Module

[Lukas P. (lumapu)]

Heinz R. schrieb:
> Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur
> den unten gezeigten Output

Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der 
Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären.

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR
> als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird?
> (WR Library?)

Klar wir sind für alles offen, wir versuchen jetzt mal das schon 
bekannte in einer Firmware zusammenzufassen. Wenn du Input / Ideen hast 
kannst du sie gerne jederzeit beitragen. Ich würde sagen: Je mehr und 
je vollständiger die WR unterstützt werden umso besser!

[Heinz R. (heijz)]

Lukas P. schrieb:
> Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der
> Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären.

funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 
flashst?

[Marcus (Gast)]

Lukas P. schrieb:

Zur Zählweise - hier erkennst Du es denk ich ganz deutlich (ich warte 
noch auf einen PR in das offizielle Repo-Doku): 
[[https://github.com/dad401/ahoy/blob/main/doc/HM-400%20data.xlsx]]

> Die Kanäle habe ich wie folgt aufgebaut:
> CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten
> CH1-CH4: je nach Wechselrichter die Anschlüsse für Module

Ja, ich habe es mir inzwischen so gedacht - hatte mir vorher Channels = 
cmd01 etc. bzw. Radio-Channels vorgestellt. Demnach hat der HM-400 CH0 
(AC, Freq, Spannung, Temp) und CH1 den Rest vom Panel.

Habe den 400er auch in Deinen Code eingebaut/-bastelt, kann nur wegen 
Dunkelheit nicht mehr testen. Kommt morgen...
Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch 
das CMD82 (hminverters.h)?

enum {CMD01 = 0x01, CMD02, CMD03, CMD83 = 0x83, CMD84};

Der Code ist eine gute Grundlage für Tasmota - bin da zwar eher Amateur, 
aber man lernt daran und einen adaptierten SDM230-Treiber 
(Wechselstromzähler) wurde auch als PR schon angenommen :-) - Bin 
gespannt ob das klappt. Einzig die Ressourcen sind da arg knapp und die 
Anzahl der WR sollte man da auch beschränken. Aber Web und MQTT kommt 
von Haus aus mit.

[Mich@ (Gast)]

Hallo Lukas,

Ich kann auch bestätigen das die neue Firmware nicht auf dem Wemos D1 
Mini läuft. Weder das bin file (mit Tadtomizer und mit ESP-Easy flasher 
getestet) sowie auch die Version von Github mit Arduino IDE neu 
Kompiliert und geflasht. Bei beiden Varianten das gleiche Ergebnis wie 
Heiz bereits geschrieben hat.

[Mike (Gast)]

Ziyat T. schrieb:
>
> Bisherige Erkentnisse vom MI1500, siehe Anhang

Ich bin der Meinung, das die Werte in der letzten Spalte das 
Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der 
aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt 
(Nur in der Webansicht).

[Lukas P. (lumapu)]

Sehr schade, worin liegt der Unterschied zwischen meinem ESP-07 und dem 
Wemos D1mini? Ich glaube der ESP-07 hat 1MB Flash.
Ich habe bisher keinen Wemos.

Marcus schrieb:
> Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch
> das CMD82 (hminverters.h)?

wird nachgereicht, du hast Recht

[isnoAhoy (Gast)]

Hallo Lukas,

ich habe mal Deinen dev branch ausgecheckt und übersetzt.

Dabei habe ich folgende Änderungen für Linux hinzugefügt:

tools/fileConv.sh:

#!/bin/bash
echo String $3 = \"$(cat $1 | tr '\n' ' ' | sed 's/"/\\"/g;s/\s\{4\}/\t/g')\"\; > $2

html/conv.sh:

#!/bin/bash
../tools/fileConv.sh index.html h/index_html.h index_html
../tools/fileConv.sh setup.html h/setup_html.h setup_html
../tools/fileConv.sh hoymiles.html h/hoymiles_html.h hoymiles_html
../tools/fileConv.sh style.css h/style_css.h style_css

platform.txt:

# add a prebuild hook to generate minified h files from html templates
recipe.hooks.prebuild.1.pattern={build.path}/html/conv.sh
recipe.hooks.prebuild.2.pattern={build.path}\html\conv.bat

Wobei die prebuild hooks in der platform.txt offenbar noch nicht 
greifen. Vielleicht kennt sich ja jemand damit aus, wie man das HTML/CSS 
minify der templates im html Verzeichnis richtig anstoßen kann.

Auch die folgende Speicheroptimierung habe ich noch nicht in den o.g. 
Generator eingebaut.

> Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:

static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"
String body = FPSTR(HTTP_BODY);
body.replace("{{variable}}", configuration.variable);
page += body;

Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das 
halt im Dev Branch =^D

Dafür sind die ganzen versprochenen Anpassungen schon da !
* WiFi mit SSID und Password
* Device Name: ESP-AHOY
* bis zu vier Inverter 0-3 (wahlweise HM600 / HM1200) mit Adresse im 
114173123456 Format plus ein sprechender Name für jeden
* Abfrage Intervall der Wechselrichter: 1000 ms
* Pin Out Definition CS: D8 (GPIO15), CE: D4 (GPIO2) und IRQ: D3 (GPIO0) 
im Default und wählbar.
* MQTT Settings mit Broker / Server IP, Username & Password, Topic 
(/inverter) sowie Interval (10000 seconds)

Besonders gefällt mir das flexible Mapping der Bytes in den Nachrichten 
auf die enstprechenden Felder (DC U/I/P und AC U/I/P/Freq, etc.) der 
Wechselrichter in der hmInverters.h.
Ich muß mir das mal genauer ansehen, ich meine es gab auch Felder die 
u.a. auf zwei Nachrichten 0x01 Buffer Byte 15/16 und 0x02 Buffer Byte 
1/2 aufgeteilt waren ?
Das habe ich gestern bei meinen Versuchen eine hm600Decode.h 
zusammenzubasteln nicht gebacken bekommen.
Die bei meinem Hoymiles immer wieder auftretenden 0x83 Nachrichten 
werden aktuell unter other summiert. Evtl. wäre es da hilfreich diese 
Nachrichten sowie die 0x82 bei anderen WR gesondert zu zählen ?

[Mich@ (Gast)]

Hallo Lukas,

Der D1 Mini hat 4mb fashspeicher…
Die Vorgänger Version in dem nur der HM1200 unterstützt wurde lief ohne 
Probleme.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das
> halt im Dev Branch =^D

Bin ich froh, dass es bei dir klappt. Jetzt wäre es noch toll wenn du 
den heutigen main Branch verwenden würdest.
Damit die Wifi Settings nicht ständig weg sind, wenn man die Liste der 
zu speichernden Parameter erweitert, habe ich jetzt einen weiteren CRC 
eingeführt, der nur über die Wifi Settings geht.

Dein conv.sh ist leider fast überflüssig, aber wir können es parallel 
ablegen. Ich habe heute auf python umgestellt, dadurch sind wir 
plattformunabhängig.

Heinz R. schrieb:
> leeren ESP8266
> flashst?

Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle 
mich von OTA Update zu Update =)
Das erinnert mit daran in der Konfiguraiton einen Erase Button 
einzuführen =)

[Ziyat T. (toe_c)]

Mike schrieb:
> Ziyat T. schrieb:
>>
>> Bisherige Erkentnisse vom MI1500, siehe Anhang
>
> Ich bin der Meinung, das die Werte in der letzten Spalte das
> Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der
> aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt
> (Nur in der Webansicht).

Leider nicht,
z.Bsp.
Zeile 3,Spalte 2, B7(port2) ist nicht belegt, PW=0, Spalte AX 1.18, geht 
nicht auf
Zeile 2,Spalte 2, B8(port2) ist belegt, PW=75.4, Spalte AX 0.01 geht 
nicht auf

[Heinz R. (heijz)]

Lukas P. schrieb:
> Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle
> mich von OTA Update zu Update =)
> Das erinnert mit daran in der Konfiguraiton einen Erase Button
> einzuführen =)

Es gibt z.B. bei ESPEasy Blank-Files - habe Dir mal eines angehängt

[Lukas P. (lumapu)]

Jetzt fällt mir noch was ein in hmRadio.h:83 ist noch immer 
'RF24_PA_MAX' definiert, bei mir funktioniert es, evtl. bricht beim 
ersten Sendeversuch die Spannung ein. Ich habe an den 3.3V einen dicken 
Elco, man sieht aber trotzdem, dass die LEDs kurz dunkler werden.

@Heinz
Dein blank.bin sieht aus wie ein frisch gelöschter Speicher, alles 0xFF 
=). Vielen Dank.

[Bert 0. (maschinist)]

Mit ESP-12e:
Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis 
zum Löschen des EEPROMs, dann schlägt der WDT zu.

Gruß... Bert

[Lukas P. (lumapu)]

Bert 0. schrieb:
> Mit ESP-12e:
> Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis
> zum Löschen des EEPROMs, dann schlägt der WDT zu.
>
> Gruß... Bert

Super, danke für den Hinweis, die Fehler sind dann eindeutig in der 
eep.h und zwar in Zeile 40 und 81
Die For loops werden mit einem 8-bit zähler niemals die 16bit length 
zählen können -> Endlosschleifen

Commit ist gleich unterwegs ;-)

Kann bitte einer nochmal kurz die Sonne einschalten zum Testen? :-P

[Bert 0. (maschinist)]

Jop, mit dem letzten Commit startet die Applikation wieder korrekt, Fix 
reviewed OK!
;-)

Gruß... Bert

[Thomas B. (tbnobody)]

Ich kann btw. auch bestätigen, dass die Zuordnung auch für den HM-1500 
sinn macht: 
https://github.com/grindylow/ahoy/blob/bf8c1628973eb1dc53b2604b6a7bc1561174f004/tools/esp8266/hmInverters.h#L100

Hab die Zuordnung mit einem meiner Dumps getestet... sieht alles 
plausibel aus

[Mich@ (Gast)]

Die neue Version läuft auf dem Wemos D1!
Besten Dank.

[Heinz R. (heijz)]

Mich@ schrieb:
> Die neue Version läuft auf dem Wemos D1!
> Besten Dank.

Gibt es die evtl. auch als fertig kompiliertes bin?

[Lukas P. (lumapu)]

Ja im Anhang ist die neuste Verison
- hat jetzt eine Erase Application data Option
- Cmds 0x82 und 0x83 tauchen in Statistik auf

[Robert S. (Gast)]

Ich springe auch mal auf den Zug auf ;-)

Erstmal ***VIELEN DANK*** an alle Beteiligten!!!!
Ich bin noch an den Vorbereitungen, mein HM1200 ist noch nicht 
geliefert,
und ich habe auch noch kein NRF, daher derzeit nur beschränkte 
Möglichkeiten.

Die aktuelle 0.2.6 läuft aber schon mal auf einem Wemos D1 mini (clone) 
:-)
- WIFI-Connection ist ok
- Webseite funktioniert
- MQTT ist inkl. user/pass eingetragen wird aber als "not connected"
  angezeigt. Im MQTT-Sniffer sehe ich aber das Topic und den 
FirmwareRelease.
  Sonst nichts, es gibt aber ja auch noch keine Daten.

Meine Fragen:
- Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber 
in (s)
  Stimmt das?
- Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein 
Satzzeichen,
  ist das ok (erlaubt)?

viele Grüße
Robert

[Marcel A. (a-marcel)]

Hallo,

ich bin leider kein C++ Programmierer und habe jetzt einen Status 
erreicht, wo ich nicht weiter kann. Ich wollte den Code auf ESP32 
anpassen und hab auch viele Sachen angepasst, aber jetzt verlangt es 
langsam bessere C Knowledge.

Ich würd mich freuen, wenn jemand da helfen kann ! Ich pack mal das 
error rein, welches ich bekomme wenn ich kompiliere.

Ich nutze auch PlatformIo und habe da die Ordner Struktur angepasst.

Zu finden sind die Änderungen in dem Fork in meinem Account: 
https://github.com/a-marcel/ahoy

Ich würde mich freuen, wenn es auch für ESP32 geht, weil der ja mehr 
Speicher hat es einfacher sein sollte.

[Lukas P. (lumapu)]

Hallo Marcel,

finde ich super! Mal ein paar Dinge, die offensichtlich sind. Er findet 
die Datei "eep.cpp" nicht und er kommt nicht mit den 'Tickern' zurecht. 
Evtl. benötigt er eine Library / Include dafür.

Evtl. tut man sich leichter, wenn man den Code erst mal für den ESP8266 
in PlatformIO kompiliert.

Robert S. schrieb:
> Meine Fragen:
> - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber
> in (s)
>   Stimmt das?
> - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein
> Satzzeichen,
>   ist das ok (erlaubt)?

- Inverval wird korrigiert, ist auch in ms
- Das Passwort wird einfach als String (char-array) gespeichert, daher 
ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen 
begrenzt und der User auf 16 Zeichen.
- der Status des MQTT Brokers war invertiert -> korrigiert

[Robert S. (Gast)]

Lukas P. schrieb:
> - Inverval wird korrigiert, ist auch in ms
> - Das Passwort wird einfach als String (char-array) gespeichert, daher
> ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen
> begrenzt und der User auf 16 Zeichen.
> - der Status des MQTT Brokers war invertiert -> korrigiert

Genial, funktioniert!
Vielen Dank für den superschnellen Fix!
Robert

[Marcus (Gast)]

Heinz R. schrieb:
> funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266
> flashst?

Auch hier kommt der Watchdog (Wemos D1 mini). Auch ein

esptool.py erase_flash

 hilft nicht.

[isnoAhoy (Gast)]

Hallo Lukas P.,

danke für die vielen Commits und Fixes heute abend, nur das mit der 
Sonne hat nicht mehr gereicht =^D
Ich schaue mir morgen bei Tag nochmal die HM-600 Werte an, da hast Du ja 
zuletzt noch etwas gefixt.

Habe gerade nochmal die 0.2.7 geflashed, nach einem mutigen ERASE 
SETTINGS (not WiFi) kam auch folgender Fehler nicht mehr:
00:25:38.848 -> add inverter: oymiles A, SN: 114173123456, type: 0
00:25:38.848 -> no assignment for type found!add inverter: , SN: 
480000000000, type: 3
Irgendwie hat er im EEProm wohl daneben gegriffen und das "H" des ersten 
WR Namens als SN für einen weiteren Wechselrichter interpretiert.
Danke für die Funktion zum beibehalten der SSID und des WiFi Passworts 
das ist sehr praktisch und hilfreich!

Auch die PA_MIN, PA_LOW, PA_HIGH, PA_MAX Einstellung funktioniert jetzt 
laut Debug Ausgabe:
00:29:55.769 -> add inverter: Hoymiles HM-600, SN: 114173123456, type: 0
00:29:55.802 -> RF24 Amp Pwr: RF24_PA_MAX

Wie gesagt Device Name könnte noch mit ESP-<WIFIMAC> vorbelegt sein.

[isnoAhoy (Gast)]

Hallo Heinz R.,

kannst Du mal zum Flashen den Serial Monitor der Arduino IDE schließen.
Ich meine das ist eine häufige Fehlerquelle wenn er die Firmware 
übertragen will und dabei vorzeitig abbricht.
Vielleicht hilft das ja auch in Deinem Fall.

[isnoAhoy (Gast)]

Hallo Heinz R.,

jetzt habe ich mal den weiter oben genannten Stack Trace von Dir 
versucht zu analysieren.

Schau Dir doch mal bitte folgende Seite an:
https://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html
Dort wird die Vorgehensweise bei solchen Exceptions Problemen 
beschrieben.
Den ESP Exception Decoder habe ich nach der Anleitung ausgepackt und 
installiert
https://github.com/me-no-dev/EspExceptionDecoder#installation

Leider habe ich nicht den zugehörigen Source Code bzw. das ELF Binary um 
daraus Sinn zu machen bzw. Deinen alten Stack Trace zu analysieren. Mir 
fehlt auch der Exception Code um das Problem prinzipiell eingrenzen.

Ich hatte übrigens gestern abend auch einen Stacktrace gesehen.
Nach einigen Restarts geht es jetzt aber sauber, kann es also nicht 
einfach reproduzieren.

Hast Du evtl. einige Clients die auf den ESP per WiFi zugreifen wollen 
oder wird viel per Serial geloggt ?
I.d.R. treten solche WDT Exceptions auf, wenn der ESP seine WiFi 
Schnittstelle nicht parallel zum Programm bedienen/abarbeiten kann.
Vielleicht kann man es ja an der richtigen Stelle mit einem yield() 
beheben ?

Was für Einstellungen hast Du denn für Deinen ESP8266 im Tools Menü 
gewählt ?
Eventuell liegt es ja an etwas einfachem wie der Frequenz, Debug 
Optionen, o.a.

[Lukas P. (lumapu)]

Guten Morgen,

ich weiß nicht, ob ich es schon genannt hatte: die Seriennumer muss 
jetzt genauso wie sie auf dem WR steht eingetragen werden, ohne ":".

Im Anhang noch die Version 0.2.7 und im zip das .elf zum debuggen von 
Stack-Traces.

Mit meinem HM1200 geht die Firmware bei Tageslicht =)

[isnoAhoy (Gast)]

Guten Morgen Lukas P.,

also ich habe (nach wie vor) seltsame Werte für meinen zweiten Kanal am 
HM-600 (bisher unbelegt daher vermutlich free-floating):
CHANNEL 1 230.40 V U_DC 2.27 A I_DC 804.10 W P_DC 50467.00 Wh YieldDay
CHANNEL 2 1557.50 V U_DC 393.21 A I_DC 3932.10 W P_DC 10711.00 Wh 
YieldDay

Die Yield Total und Week sowie AC Werte / Temperatur werden aktuell noch 
nicht angezeigt bzw. deren u.g. Werte erscheinen mir fraglich.
Kann man die rohen Datenpakete wieder ausgeben lassen, das war m.W. 
dumpBuf o.a. ?

Hier mal die Werte aus dem Serial Monitor:
08:42:04.674 -> hm600/ch1/U_DC: 230.400 V
08:42:04.674 -> hm600/ch1/I_DC: 2.300 A
08:42:04.674 -> hm600/ch1/P_DC: 190.600 W
08:42:04.674 -> hm600/ch2/U_DC: 1368.500
08:42:04.674 -> hm600/ch2/I_DC: 393.210 A
08:42:04.707 -> hm600/ch2/P_DC: 3932.100
08:42:04.707 -> hm600/ch0/YieldWeek: 1024.000
08:42:04.707 -> hm600/ch0/YieldTotal: 94.000 Wh
08:42:04.707 -> hm600/ch1/YieldDay: 32133.000
08:42:04.707 -> hm600/ch2/YieldDay: 10985.000
08:42:04.707 -> hm600/ch0/U_AC: 3932.100
08:42:04.707 -> hm600/ch0/Freq: 393.210 H
08:42:04.707 -> hm600/ch0/I_AC: 3932.100
08:42:04.707 -> hm600/ch0/Temp: 2218.900

Wenn dies eine CSV Ausgabe in einer Zeile wäre, dann könnte das der 
Serial Plotter in der Arduino IDE darstellen:
1U_DC1,1I_DC1,1P_DC1,1U_DC2,1I_DC2,1P_DC2,1YW,1YT,1YD1,1YD2,1U_AC,1Freq, 
1I_AC,1Temp: 
230.400,2.300,190.600,1368.500,393.210,3932.100,1024.000,94.000,32133.00 
0,10985.000,3932.100,393.210,3932.100,2218.900
Am Besten könnte man noch die Spalten auswählen, die per Serial Monitor 
als "CSV" oder im bisherige "MQTT" Format ausgegeben werden =^D

Die Channel Statistik in app.h/.cpp habe ich wieder aktiviert und er 
schickt bei mir alles auf Kanal 61.
Hast Du das Channel Hopping adaptiv angepaßt, d.h. daß es erst bei 
Fehlern (ACK) den Kanal wechselt ?

[Lukas P. (lumapu)]

Habe hin und wieder Exceptions gesehen, daher die 0.2.8

@isnoAhoy: das channel hopping ist aus (hmRadio.h), bringt bei mir 
keinen Vorteil
Ich würde eher die RAW oder Payload Daten plotten lassen und das dann 
per Excel auswerten

[isnoAhoy (Gast)]

Hallo Lukas P.

habe die dumpBuf Aufrufe in hmRadio.h und app.cpp gefunden und wieder 
aktiviert.
Das wäre als Debug Option im Setup sicher auch noch praktisch!

Dazu musste ich die Methode in hmRadio.h vor den private: Bereich 
verschieben,
da sie sonst nicht aus app.ccp aufgerufen werden konnte: declared 
private!

Folgender einfacher Zusatz in dumpBuf() gibt übrigens auch HEX mit 
führender Null aus,
dann klappt es m.E. leichter mit dem Excel Sheet zum dekodieren.

if (buf[i] < 10) Serial.print("0");

[Ziyat T. (toe_c)]

An de NRF Spezialisten,

Ich sehe diese RAWDaten vom MI1500 neben den "Regulaeren", was könnten 
sie sein?

Kann immer noch den MI1500 nicht ansprechen, Daten bekomme ich nur, wenn 
die DTU-Pro eingeschaltet ist.

[Hubi (Gast)]

Hallo  Ziyat

soviel ich noch von weiter oben weiß benutzt du meine SW.
Dass nur Daten kommen wenn DTU an ist bedeutet für mich, dass die DTU 
wohl dem WR einen Anstoß gibt. Weiter oben habe ich auch beschrieben, 
dass beim Senden des Zeit-setzen-Pakets mit einem Wert <> 0B hinter dem 
0x80 ganz neue Antworten kommen. Also vllt braucht dein MI1500 kein 0B 
sondern was anderes.
Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert 
buf[10] von 00 bis FF durchlaufen lassen. etwa so:

static uint8_t cid = 0;

int32_t HM_Packets::GetTimePacket(uint8_t *buf, uint32_t wrAdr, uint32_t 
dtuAdr) {
  prepareBuffer(buf);

  buf[0] = 0x15;
  copyToBufferBE(&buf[1], wrAdr);
  copyToBufferBE(&buf[5], dtuAdr);
  buf[9] = 0x80;

        buf[10] = cid++;   // statt 0x0B
  buf[11] = 0x00;

  copyToBuffer(&buf[12], unixTimeStamp);
.....
Hast du auch schon die einzelnen Sendestärken durchprobiert?

[Marcus (Gast)]

Hi Lukas,

heute ein erster Test mit dem HM-400 und der nun lauffähigen Version. 
Die Werte sind hier auch merkwürdig:

[c]8:05:08.357 -> HM-400/ch1/I_DC: 105.600 A
18:05:08.357 -> HM-400/ch1/P_DC: 4785.400
18:05:08.390 -> HM-400/ch1/YieldTotal: 1056938.3
18:05:08.390 -> HM-400/ch1/YieldDay: 39.321 Wh
18:05:08.390 -> HM-400/ch0/U_AC: 3932.100
18:05:08.390 -> HM-400/ch0/Freq: 473.600 H
18:05:08.390 -> HM-400/ch0/P_AC: 158.300 W
18:05:08.390 -> HM-400/ch0/I_AC: 319.610 A
18:05:08.390 -> HM-400/ch0/Temp: 3932.100[c/]

Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich schau 
mir das mal an...

Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe 
ich da etwas?

Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus 
der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung 
ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob 
die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen 
HM-400 und HM-300 testen.

[Mich@ (Gast)]

Hallo Lukas,

Die neue Version läuft gut auf dem Wemos. Vielen Dank!

Ist es möglich das in den MQTT Einstellungen der Port über das 
webinterface eingestellt werden kann?

[Marcus (Gast)]

Marcus schrieb:
> Ich vermute hier werden die falschen Datenblöcke extrahiert.

Ich bin in C nicht so fit, aber wird hier wirklich der richtige Wert 
extrahiert?

Als Beispiel ein CMD82 Paket:
&p->packet[0] = 00DE957310xxyy7310xxyy82138600350000000203E8009E000AF1

In app.c übergibst Du das Paket ab Position 11:

mSys->addValue(iv, i, &p->packet[11]);

Damit beginnt es ab dem CMD 82:
&p->packet[11] = 82138600350000000203E8009E000AF1

Nun zum addValue Aufruf, welcher hier auf die HM-400 Werte zurück 
greift:

{ FLD_F,   UNIT_HZ,  CH0, CMD82, 12, 2, 100  }

void addValue(inverter_t *p, uint8_t pos, uint8_t buf[]) {
    uint8_t ptr  = p->assign[pos].start; // das müsste ja die 12 sein
    uint8_t end  = ptr + p->assign[pos].num; // 12 plus die Länge von 2
    uint16_t div = p->assign[pos].div; => der Divisorwert 100

    uint32_t val = 0;
        do {
          val <<= 8;  // val = val << 8
          val |= buf[ptr]; // val = val OR buf[12];  aber da buf[] ja die Adresse von packet[11] übergeben bekommt, entspricht dann buf[12] nicht &p->packet[11]+12 Bytes (uint8) weiter?
        } while(++ptr != end);

=> Value hat damit die Werte aus den Positionen packet[23] und 
packet[24] (2 Byte), es muss aber die Werte packet[14] und packet[15] 
haben (das dritte Byte nach dem CMD ist der Start). D.h. start beginnt 
bei 3 (packet[11] + 3), Länge ist mit 2 korrekt.

Oder ich liege völlig falsch?!

[Heinz R. (heijz)]

Hallo Lukas,

habe die neue Version zumindest mal geflasht bekommen und komme auf die 
Weboberfläche
(Ich habe direkt das bin geflasht)

Leider erhalte ich aber keine Daten vom WR
(Das Setup lief so schon mal mit einer SW von weiter oben)

Unten die Ausgabe des seriellen Schnittstelle

Ich habe versucht die RF Power von Max niedriger zu stellen - es springt 
nach dem Speichern leider immer wieder auf Max?

Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 
erkannt werden?

Kleiner Tip noch für zukünftige Versionen:  Gib über die serielle 
Schnittstelle auch die IP-Adresse mit aus, spart langes suchen?

Viele Grüße

load 0x4010f000, len 3460, room 16

tail 4

chksum 0xcc

load 0x3fff20b8, len 40, room 4

tail 4

chksum 0xc9

csum 0xc9

v00057520

~ld

wait for network
.
add inverter: , SN: 116474903203, type: 1

RF24 Amp Pwr: RF24_PA_MAX

Radio Config:

SPI Frequency    = 10 Mhz

Channel      = 3 (~ 2403 MHz)

RF Data Rate    = 250 KBPS

RF Power Amplifier  = PA_MAX

RF Low Noise Amplifier  = Enabled

CRC Length    = Disabled

Address Length    = 5 bytes

Static Payload Length  = 32 bytes

Auto Retry Delay  = 250 microseconds

Auto Retry Attempts  = 0 maximum

Packets lost on current channel  = 0

Retry attempts made for last transmission  = 15

Multicast    = Disabled

Custom ACK Payload  = Disabled

Dynamic Payloads  = Disabled

Auto Acknowledgment  = Disabled

Primary Mode    = RX

TX address    = 0xdeadbeef01

pipe 0 (closed) bound  = 0xdeadbeef01

pipe 1 ( open ) bound  = 0x1234567801

pipe 2 (closed) bound  = 0xc3

pipe 3 (closed) bound  = 0xc4

pipe 4 (closed) bound  = 0xc5

pipe 5 (closed) bound  = 0xc6

[Lukas P. (lumapu)]

Marcus schrieb:
> Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe
> ich da etwas?
>
> Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus
> der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung
> ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob
> die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen
> HM-400 und HM-300 testen.

Ja Channel 0 wird noch nicht visualisiert, man kann aber durch ein 
define auch hier einfach die Liste der Werte ausgeben lassen.

Das mit der SN habe ich mit anfangs auch gedacht, aber ich finde das 
noch nicht endgültig geklärt - jetzt ist es implementiert und würde ich 
vorerst so lassen. Sind nur 8Bit + alles drin rum ;-)


Mich@ schrieb:
> Ist es möglich das in den MQTT Einstellungen der Port über das
> webinterface eingestellt werden kann?

ja das ist möglich, werde ich demnächst einbauen.


Heinz R. schrieb:

> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt
> nach dem Speichern leider immer wieder auf Max?

ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger 
alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden 
kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert.

> Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01
> erkannt werden?

Habe zufällig so eine Funktion in der Beschreibung der RF24 lib gesehen. 
Kann ich mal testweise einbauen.

> Kleiner Tip noch für zukünftige Versionen:  Gib über die serielle
> Schnittstelle auch die IP-Adresse mit aus, spart langes suchen?

Ja die Rufe werden lauter - wird eingebaut

[Heinz R. (heijz)]

Lukas P. schrieb:
>> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt
>> nach dem Speichern leider immer wieder auf Max?
>
> ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger
> alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden
> kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert.

Hallo Lukas,

auch nach einem Reboot oder gar Reset steht RF Power wieder auf High?

Ich versuche gerade den Fehler einzugrenzen - evtl. doch 
Kommunikationsprobleme mit dem NRF24L?

[Lukas P. (lumapu)]

Das kann dann nur an der Speicherroutine liegen. Ich prüfe es bei mir 
nochmal. Das hat mir dem externen Bauteil nichts zu tun.

[Marcel A. (a-marcel)]

Hallo,

ich probiere noch immer den Code auf ESP32 zum laufen zu bekommen. Ich 
würde da Hilfe von einem, der besser CPP coden kann, gebrauchen.

Mehrere Ticker in der Form von:

mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this));

compilieren mit folgendem Fehler:

src/app.cpp:97:75: error: no matching function for call to 'Ticker::attach_ms(uint16_t&, std::_Bind_helper<false, void (app::*)(), app*>::type)'
         mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this));

Auf Stackoverflow habe ich genau diesen Fehler gefunden, wo auch eine 
Lösung präsentiert wurde. Leider kann ich diese nicht auf den o.g. Code 
anwenden.

https://stackoverflow.com/questions/60985496/arduino-esp8266-esp32-ticker-callback-class-member-function

Vielleicht hat ja ein CPP Pro hier eine Antwort für mich.

Vielen Dank
Marcel

[lpb (Gast)]

Mal wieder ein paar (Wenigstens für mich) neue Erkenntnisse von meinem 
HM600, die aber das vermutlich auch das Protokoll im allgemeinen 
betreffen müssten, und ich glaube, das habe ich hier so noch nicht 
gelesen.

Ich habe versucht, die Zuverlässigkeit des Empfangs der 
Nachrichtenpakete zu verbessern. Einen letztlich guten Hinweis dazu habe 
ich in dem DTU log aus 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" gefunden.

Ganz allgemein, je nach Anfrage sendet der Inverter verschiedene 
Nachrichten als Antwort.
Meine 'Standard' Anfrage basiert auf der GetTimePacket Nachricht, die 
auch in dem DTU log enthalten ist.
Darauf hin kommen die Antworten 0x01, 0x02, und 0x83 zurück. Für die 
Antworten spielt es offensichtlich keine Rolle, ob das Byte 19 0 oder 5 
ist (die Anfragen der DTU logs haben 0, daher habe ich das mal versucht 
- wie gesagt ohne wirklichen Unterschied).

Beim Anschauen der DTU logs habe ich auch eine Anfrage gesehen, die im 
Byte 10 statt 0x0B eine 0x11 hat.
Wenn ich das an den HM600 sende, bekomme ich (nach anpassen des Rx 
channel scans) zuverlässig die Antworten 0x01, 0x02, ... 0x0B, 0x8C.

Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* 
Nachrichten das letzte Antwortpaket markieren. Das diese oft nicht so 
oft empfangen werden könnte Dara liegen, dass alle Nachrichten auf einem 
Kanal erwartet werden. Das ist aber nicht der Fall - dazu später mehr.

Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das 
Anfordern eines nicht erhaltenen Pakets.
Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket 
anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'.

Das habe ich heute so erfolgreich getestet:

19:12:16.870 -> sending data request...
19:12:16.973 -> [75] 024A2F0000505F00B400BE08C8138500C76618A1 
19:12:16.973 -> AC_Power: 19.9W, AC_Voltage: 224.8V, Frequency: 49.97Hz
19:12:16.973 -> Day_Production: 370Wh (180 + 190)
19:12:16.973 -> Total_Production: 39.6kWh (18991 + 20575)
19:12:17.007 -> [75] 830000000903E800840B5E8BB6188E89 
19:12:17.007 -> Level(?): 0
19:12:17.007 -> Status: 1000
19:12:17.007 -> AC_Current: 0.09A
19:12:17.007 -> Temperature: 13.2°C
19:12:17.308 -> 
19:12:17.308 -> sending re-transmit request 01...
19:12:17.375 -> [75] 010001014B001F006701480020006A0000A46F02 
19:12:17.375 -> PV1-V: 33.1V, PV1-C: 0.31A, PV1-P: 10.3W
19:12:17.375 -> PV2-V: 32.8V, PV2-C: 0.32A, PV2-P: 10.6W

Wie man sehen kann, fehlt die erste Antwort. Diese frage ich dann noch 
einmal dediziert an, und habe dann alle Pakete (Anfrage ist immer auf 
Kanal 40, hier alle Antworten auf Kanal 75).

Das erklärt dann eventuell auch, warum AutoAck nicht verwendet wird; has 
hat mich bei der Suche nach einem Schema für den Kanalwechsel immer 
wieder etwas verwirrt.

Ich dachte eigentlich, dass das Fehlen von Nachrichten an meinem 
'simplen' Kanal-Scannen liegt, aber in DTU log kann man diese erneute 
Anfrage ebenfalls schön sehen. Könnte also ein Hinweis darauf sein, dass 
es keine feste Synchronisation der Kanalwechsel gibt, und daher 
Paketverluste 'eingeplant' sind.

Durch die 'vielen' Antworten auf die '11er' Anfrage habe ich dann auch 
gesehen, dass ich meine channel List anpassen musste.
Mit

rx_channels[] = {3, 23, 40, 61, 75, 83};

 und dem Re-transmit request bekomme ich bei mir jetzt ganz gut alle 15 
Sekunden ein komplettes Datenpaket zusammen. Meine Logik ist noch nicht 
ganz ausgereift, so dass ich im Moment nur ein fehlendes Paket neu 
anfordere, aber es gibt auch mal keine Antwort, oder nur eine.

Heute ist die Sonne wieder zu früh untergegangen, aber es sieht so aus, 
dass die Kanäle in einem festen Schema von oben nach unten gewechselt 
werden (da ich nicht weiß, was in den Nachrichten ist, habe ich die mal 
abgekürzt):

19:13:32.105 -> sending data request...
19:13:32.139 -> [03] 010... 
19:13:32.174 -> [75] 020... 
19:13:32.242 -> [75] 030... 
19:13:32.312 -> [61] 040... 
19:13:32.346 -> [61] 050...
19:13:32.379 -> [61] 060... 
19:13:32.446 -> [40] 070... 
19:13:32.482 -> [40] 080... 
19:13:32.550 -> [40] 090... 
19:13:32.586 -> [23] 0A0... 
19:13:32.656 -> [23] 0B0... 
19:13:32.694 -> [03] 8C0...

Wie man an den unterschiedlichen Abständen sehen kann, fehlt noch eine 
'korrekte' Synchronisation (im Moment mache ich das Timing basierend auf 
meinem Senden), aber es ist erstaunlich, wie gut das im Vergleich zu 
vorher zu funktionieren scheint.

[Lukas P. (lumapu)]

Version 0.2.9 ist da!

Changelog:
- added: IP Adresse wird auf Serieller Console ausgegeben, wenn 
erfolgreich mit WLAN verbunden
- fix: RF24 Konfiguration des Power Amplifiers
- added: RF24 Verbindung wird geprüft; prüft nur, ob SPI erreichbar, 
wenn kein Power an RF24 Modul ist, bleibt der ganze ESP hängen (ohne 
Serielle Ausgabe)
- added: MQTT port Konfiguration
- fix: offsets für HM400 und HM600 Wechselrichter, diese sollten jetzt 
korrekte Werte anzeigen. Bitte um Feedback
- added: Warnung, wenn die Konfiguration geändert wurde, ohne neu zu 
booten auf der index.html

Viel Spaß damit =)

[Lukas P. (lumapu)]

lpb schrieb:
> Ich habe versucht, die Zuverlässigkeit des Empfangs der
> Nachrichtenpakete zu verbessern.

Hallo lpb,

genial, dass du weiter auf diesem Gebiet forschst! Ich finde das super, 
dass sich so die Kompetenzen der einzelnen ergänzen.
Wenn man statisch auf Kanal 40 das 'Zeit-setzen' schickt und nur auf 
Kanal 3 horcht, bekommt man sehr unzuverlässig Pakete rein.

Verstehe ich das richtig, man sendet in Byte 10 eine 0x11 statt 0x0b und 
bekommmt dadurch viele neue Cmds in den Antworten.

das erinnert bisschen an das was @Hubi schon mal kurz angesprochen 
hatte:

Hubi (Gast) schrieb:
> Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal 
gelesen zu haben.

Auf eine Anfrage hin kommen dann viele Antworten und zuletzt ein 0x83? 
Wie bekommt man die Zuordnung von Kanal und CMD in der Antwort? Ich muss 
ja dann vorher wissen wo die nächste Antwort kommt.

Bin gespannt wie es hier weitergeht.

[Marcus (Gast)]

Die Werte für den HM-400 stimmen nun:

10:17:40.209 -> HM-400/ch1/U_DC: 41.200 V
10:17:40.209 -> HM-400/ch1/I_DC: 5.570 A
10:17:40.209 -> HM-400/ch1/P_DC: 229.400 W
10:17:40.209 -> HM-400/ch1/YieldTotal: 67.629 kW
10:17:40.209 -> HM-400/ch1/YieldDay: 0.315 Wh
10:17:40.209 -> HM-400/ch0/U_AC: 235.400 V
10:17:40.209 -> HM-400/ch0/Freq: 50.040 Hz
10:17:40.242 -> HM-400/ch0/P_AC: 218.200 W
10:17:40.242 -> HM-400/ch0/I_AC: 0.930 A
10:17:40.242 -> HM-400/ch0/Temp: 28.800 °

Ein paar Kleinigkeiten waren zu korrigieren (siehe app.cpp und 
hmInverters.h in
https://github.com/dad401/ahoy/tree/main/tools/esp8266)
- das h von kWh und das C von °C wird abgeschnitten => meine Änderungen 
scheinen da aber doch nicht zu helfen, bitte mal prüfen
- YieldDay korrigiert - es wird nun wie bei HM-600 Wattstunden angezeigt
(möchte nicht ständig im Thread das übermitteln - ich kann aber leider 
auch keinen zweiten Fork auf Lukas-Fork erstellen, daher PR auf das 
Haupt-Repo)

P.S. ggü. Hubis NRF24 Receiver empfängt die aktuelle Version aber 
irgendwie schlechter. Es dauert mehrere Minuten bis etwas ankommt - 
früher kamen Pakete sofort nach dem Start?!

[Lukas P. (lumapu)]

Hallo Marcus,
den PR hast du garnicht durchgeführt oder? Lt. dieser Anleitung solltest 
du den auch meinem Repo zuweisen können:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

Yield total sollte doch in kWh sein oder, daher war der Teiler 1000. In 
Wh ist es sehr bald eine unnötig große Zahl.

Bzgl. der Empfang: versuche mal in hmRadio.h den Channel-Hop (define) 
wieder zu aktivieren, evlt. geht es dann wieder besser.

[Marcus (Gast)]

Habe noch keinen PR gemacht, weil die Änderungen in der app.cpp nicht 
funktionieren. Ich teste das mal, ob ich Dein Repo hier verbinden kann - 
bin da zu unerfahren mit GIT da ich nur gelegentlich damit zu habe.

Yield total stimmt. Aber das h wird hinten bei der Ausgabe 
abgeschnitten.
Yield daily wird derzeit beim 400er in kWh ausgegeben, aber als Einheit 
ist Wh angezeigt - das habe ich korrigiert. Wenn Du aber eh 3 
Nachkommastellen ausgibst, könnte man YD auch generell auf kWh setzen. 
Ist aber alles Geschmackssache - Hauptsache einheitlich :-)

Ich probiere das mal mit dem Channelhopping. War das früher aktiv? Mit 
der ersten Version nach Behebung des Watchdog-Crashes ging es m.E. sehr 
gut. Jetzt dauert es 10min bis erste Pakete empfangen werden.

[Lukas P. (lumapu)]

Bei mir liegt es stark an der Ausrichtung der Antenne, sie muss bei mir 
mit der abstrahlenden Seite Richtung WR zeigen. Das ist bei mir noch 
sehr empfindlich, daher finde ich es super, dass sich hier auch welche 
um besseren Empfang kümmern.

[martin (Gast)]

lpb schrieb:
> Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8*
> Nachrichten das letzte Antwortpaket markieren

Hallo lpb,
diese Vermutung hatte ich auch schon, nachdem ich meine Messungen an der 
seriellen Schnittstelle hier gepostet hatte (siehe auch Bild):
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Aber die Erkenntnis mit dem Retransmit eines speziellen Pakets ist 
natürlich sehr nützlich.

Ich hatte hier im Thread schon mal darauf hingewiesen, dass es einen 
Unterschied in der Antwort des Wechselrichters macht, welche Anfrage 
vorausging. Das dürfte vielleicht die ein oder anderen "seltsamen" Werte 
bei manchen hier erklären. Die 0x80 0x11 Anfrage liefert andere 
Antwortpakete als die 0x80 0x0B Anfrage, obwohl sie den gleichen Index 
haben (siehe Bild).

Leider habe ich auch keine Ahnung, wie man das empfangene Paket 
plausibilisieren könnte. Evtl. lohnt es sich, das Channel Hopping 
systematischer zu untersuchen, um die komplette Antwortsequenz in einer 
gewissen Zeit zu erhalten.

Bald sind meine Module auf dem Dach montiert, dann kann ich auch wieder 
hier mitmischen...

[martin (Gast)]

martin schrieb:
> Evtl. lohnt es sich, das Channel Hopping
> systematischer zu untersuchen, um die komplette Antwortsequenz in einer
> gewissen Zeit zu erhalten.

Vielleicht ist die Messung von B.G. ja schon ein entscheidender Hinweis:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Es scheint eine Systematik in den Kanalwechseln zu geben, nämlich "von 
oben nach unten":
Kommt Paket 1 auf Kanal 40, dann wird auf 23 weitergehorcht. Kommt dort 
02,83 ist es Antwort auf 0x80 0x0B, kommt 02,03,04 wird auf Kanal 3 
weitergehorcht, bis 85 kommt. Dann ist es die Antwort auf 0x80 0x11 (?)

[Ziyat T. (toe_c)]

Hubi schrieb:
> Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert
> buf[10] von 00 bis FF durchlaufen lassen. etwa so:

Hallo Hubi
Danke für den Vorschlag, hatte auch mal so durchlaufen lassen wie du 
vorgeschlagen hast, ohne Erfolg.
Bisher habe ich alle Kombinationen MID/CMD/CID durchprobiert.
Ich denke die MI-Series braucht was ganz anderes, denn die Antworten 
sind auch ganz anders, bei den MI-Antworten gibts keine regelmaessige

SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc..

Ich muss die DTU-Pro sniffen aber, vorerst bin ich mit meinen 
Möglichkeiten am Ende.

Ehrlich gesagt ich kann es auch fast nicht glauben, dass die Chinesen 
für die HM'S vollig etwas anderes erfunden haben..

Andere Signalstaerken hab nicht probiert, es steht auf PA_MAX, hab einen 
NRF mit Antenne und WR ist etwa 7m weit, ich denke, was ich sende kommt 
an.

[martin (Gast)]

Ziyat T. schrieb:
> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc..

Achtung, das waren die seriellen Daten INNERHALB der DTU!
7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht 
zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den 
Adressen.

[Ziyat T. (toe_c)]

martin schrieb:
> Ziyat T. schrieb:
>> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc..
>
> Achtung, das waren die seriellen Daten INNERHALB der DTU!
> 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht
> zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den
> Adressen.

Sorry, richtig!

[Marcus (Gast)]

Ich habe Hubis Code ebenfalls mal eingecheckt. Hoffe es verwirrt nicht, 
denn es gibt noch einen weiteren Code unter "Nano" - der ist m.E. aber 
etwas anderes?!

[Mich@ (Gast)]

Hallo Leute,

Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der 
Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles 
perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er 
nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht 
mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein 
stärkeres Netzteil habe ich bereits getestet…

Ansonsten läuft die neue Version gut. Die Daten meines HM350 sehen 
plausibel aus. Auch die Abfrage per MQTT läuft.

[Lukas P. (lumapu)]

Ich habe gleiches beobachtet, habe einfach den USB Stecker vom Laptop in 
ein USB-Netzteil gesteckt und auch Abstürze gesehen, auch ca. 15-20 
Minuten geschätzt. Noch habe ich keine Idee woran es liegen könnte. MQTT 
war bei mir auch an.
Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann 
können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.

[Marcel A. (a-marcel)]

Hallo,

sagt mal, gibt es irgendeine Möglichkeit die Core Funktionen in eine 
Library auszugliedern?

Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch 
auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder 
andere NTP/WiFi implementierungen.

Das wäre wirklich von Vorteil ggf. für mehrere Personen.

Vielen Dank für all eure Arbeit

Marcel

[Lukas P. (lumapu)]

Hallo Marcel,

das ist doch im Prinzip jetzt schon so. Ich habe alles so angelegt, 
damit es möglichst unabhängig vom ESP8266 ist.
Im wesentlichen sind hierfür die Dateien 'hmSystem.h', 'hmRadio.h', 
'hmInverters.h' und 'CircularBuffer.h' notwendig. Evtl. ist noch das 
eine oder andere #define aus 'defines.h' nötig.

Die 'Library' wird dann ungefähr so aufgerufen (kopiert aus app.h):

typedef CircularBuffer<packet_t, PACKET_BUFFER_SIZE> BufferType;
typedef HmRadio<RF24_CE_PIN, RF24_CS_PIN, RF24_IRQ_PIN, BufferType> RadioType;
typedef HmSystem<RadioType, BufferType, MAX_NUM_INVERTERS, float> HmSystemType;

HmSystemType sys;

aus deiner .ino setup() musst du noch diese Routine aufrufen

sys.setup();

jetzt kannst du mit dem Objekt sys alles anstellen, z.B. einen Inverter 
hinzufügen:

sys.addInverter("HM_XY", 116100000000, 0);

danach muss man sich noch überlegen, was man alles in der loop() machen 
will, hierfür einfach in der app.cpp schauen.

[Marcel A. (a-marcel)]

Okay super. Schaue ich mir mal an. Danke.
Marcel

[Robert S. (Gast)]

Mich@ schrieb:
> Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der
> Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles
> perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er
> nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht
> mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein
> stärkeres Netzteil habe ich bereits getestet…

Ich habe hier einen Wemos D1 clone mit der 2.9er im Testbetrieb an einer 
Powerbank. Er läuft jetzt seit mehr als 3h 30min, das Webinterface ist 
erreichbar, die Zeit und Uptime zählen hoch.
Unterschied, er läuft ohne NRF-Board (wird erst geliefert) und bekommt 
daher auch keine Daten. Vielleicht hilft das ja bei der Fehlersuche.

SG
Robert

[isnoAhoy (Gast)]

Hallo Marcel,

schau Dir doch mal die folgenden beiden ebenfalls passenden SE&SO 
Artikel an:

[1] 
https://arduino.stackexchange.com/questions/76138/error-in-defining-ticker-in-esp32-library
[2] 
https://stackoverflow.com/questions/53091205/how-to-use-non-static-member-functions-as-callback-in-c

Ich habe versucht an der Stelle etwas Neues zu lernen, offenbar muß ich 
dazu auch noch Einiges mehr [TM] verstehen...
Das Beispiel im ersten u.a. Link fand ich dazu für mich etwas klarer, da 
es eine ESP8266 Vorlage und ein ESP32 Ergebnis gibt.

Die beiden Funktionen sendTicker und mqttTicker muss man m.E. in der 
app.h als public deklarieren.

static void appSendTicker_helper(app* appl) {
   //needs to be public!
   appl->sendTicker();
}

static void appMqttTicker_helper(app* appl) {
   //needs to be public!
   appl->mqttTicker();
}

...
    mSendTicker->attach_ms(interval, &appSendTicker_helper, this);
...
        mMqttTicker->attach_ms(interval, &appMqttTicker_helper, this);

Analog dazu sollte es auch in der main.cpp/.h möglich sein

Interessant fand ich, daß der Umbau für den ESP32 dann auch unter 
ESP8266 funktionieren soll.

Es sind also offenbar keine extra #if defined (ARDUINO_ARCH_ESP8266) 
#elif defined(ESP32) Blöcke für die Ticker notwendig.

Für die Bibliotheken die unter ESP8266 i.d.R. auch dies als Präfix haben 
und die ESP32 Varianten ohne dieses Präfix hast Du m.W. ja schon die 
entsprechenden konditionalen include's eingepflegt.

[Herbert K. (avr-herbi)]

Guten Morgen !
Ist schon jemand dahinter gekommen, was für eine Bedeutung die "81" er 
Telegramme vom HM350 / HM400 haben ?
005E ... 14 79 CF
005C ... 14 7F 25
0058 ... 14 72 F1

00 1234567801 005E 0B 3  95 [WR] [WR] 811479CF 1

00 1234567801 005C 0B 2  95 [WR] [WR] 81147F25 1

00 1234567801 0058 0B 0  95 [WR] [WR] 811472F1 1


00 1234567801 005E 0B 3  95 [WR] [WR] 811479CF 1

00 1234567801 005C 0B 2  95 [WR] [WR] 81147F25 1

00 1234567801 0058 0B 0  95 [WR] [WR] 811472F1 1

[Lars B. (docbmuc)]

Hi Lukas und alle dies es interessiert,

erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr 
gut lesbar.

Nach ersten Tests auf einem klassischen Arduino bin ich nun auf ein 
ESP8266 Modul umgestiegen.
Man braucht für den Code wirklich aktuelle Tools zum compileren, da wohl 
erst vor gar nicht langer Zeit die String-Conversion von uint64_t 
eingebaut wurde. Bei schickte das die Umsetzung der Seriennummern in 
eine Byte-Wurscht auf die Bretter... ;-)
Danach übersetzte das Ganze aber klaglos und lief auch auf Anhieb.

Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich 
musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom 
"Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC 
Leistung. Also habe ich Zeile
{ FLD_IAC, UNIT_A,   CH0, CMD02, 15, 2, 10   },
gegen
{ FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
getauscht. - Jetzt passt es.

Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
{ FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  },


=> Kann das bitte mal jemand mit einem HM600 checken, ob das beim HM600 
auch so ist? - Sonst müsste man die HM600/700 Werte defines 
separieren...

Die Visualisierung habe ich für mich noch auf die Schnelle um die 
AC-Werte erweitert. - Siehe Screenshot. :-)

Ein Issue habe ich noch:
=> Ich habe ab und zu (gemittelt alle 10-20 Minuten) Stacktraces, also 
Abstürze mit Exception 0. Meist im Zusammenhang mit der ISR für den 
externen Interrupt und gleichzeitigem Bedienen des WLAN-TX.
=> Das Modul startet dann korrekt neu, bekommt aber keine IP-Adresse 
zugewiesen (IP unset). Ein Reset behebt das aber (temporär).

Ich beobachte das weiter und prüfe heute noch, ob es ein HW-Thema 
(Spannungseinbrüche o.ä.) ist oder eher nicht.

Cheers,
Lars

[Hubi (Gast)]

Hallo zusammen
Im Anhang meine neueste Version, da ich gesehen habe, dass doch einige 
diese ausprobieren.
Kommentare dazu:
- Projekt jetzt umgenannt in HoyDtuSim (Hoymiles DTU Simulation)
-Läuft auf Arduino (bei mir auf Pro Mini) und ESP (Wemos D1 mini), je 
nachdem wie man kompiliert
- Channel hopping für senden und Empfangen (poor man's ...) ist 
eingebaut und bringt konstante Antworten; obige Erkenntnisse über Kanäle 
abwärts sind noch nicht eingebaut
- da manchmal ein Abbruch der RF-Verbindung vorkam (auch schon oben 
erwähnt)  wird jetzt nach ca 50 Sekunden ohne Empfang das RF-Modul neu 
initialisiert und es geht problemlos weiter
- Definitionen für HM-600 und HM-1200 sind implementiert, andere können 
anhand der beiden Beispiele sicher leicht impl. werden
- Anpassungen sind in der Settings.h zu machen

Marcus hat in das lumapu-Repo meine Version vom 13.04. eingecheckt. Wäre 
nett wenn er dies durch diese hier ersetzen würde.
Wenn ich Zugang zu diesem Branch hätte und wenn ich wüßte wie das geht 
würde ich das auch selbst machen. Aber ich kann neue Versionen auch an 
Lukas P. (lumapu) per Mail schicken.

@Herbert: Die 81er habe ich auch dauernd, besonders 8114. Fehlermeldung?

[Sorbit (Gast)]

Beim compilieren mit der aktuelle IDE und aktuellen Bibliotheken kommt 
folgende Fehlermeldung:

app.cpp:58:95: error: call of overloaded 'String(uint64_t&, int)' is 
ambiguous

Liegt das an der fehlenden Seriennummer die ich noch nicht eingetragen 
habe, weil ich nicht weiß wo?

Sorry für die Anfängerfragen.

Danke

[Hubi (Gast)]

Hallo Sorbit
für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das 
aber keinen Fehler werfen.
 Wenn du die Serial ausgeben willst, kannst du das so machen

  sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned long)(serial&0xFFFFFFFFULL));

[Marcus (Gast)]

Marcel A. schrieb:
> Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch
> auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder
> andere NTP/WiFi implementierungen.

Ich bastel gerade an einer Testversion für Tasmota - muss mir aber immer 
recht viel zusammensuchen, da ich nicht so tief drin stecke im 
Programmieren wie z.B. Lukas. Die Integration kompiliert inzwischen - 
einiges musste ich anpassen, konnte aber viele der Dateien von Lukas 
weiterverwenden. Ob es auch läuft konnte ich noch nicht testen.
Kann das gerne in mein GIT einstellen 
([[https://github.com/dad401/Tasmota]] Tasmota-Fork) - ist aber sicher 
noch nicht so toll der Code. Learning by Doing auch was GIT betrifft.

@all:

Wie plausibel haltet ihr die Werte für P_AC und Power total/daily => 
sind das die Werte, welcher ein Wechselstromzähler messen sollte oder 
könnte das ggf. doch (tlw.) Werte für DC sein? Wenn das passt, dann kann 
man damit auch z.B. einen SonOff besser kalibrieren. Dieser weicht 
derzeit nur wenige kWh von der Tagesproduktion ab.

[Marcus (Gast)]

Lukas P. schrieb:
> Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann
> können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.

Ich glaube Du musst da "Discussions" in den "Settings" anwählen - in 
Deinem GIT habe ich irgendwie (ohne PR) keine Möglichkeit gefunden zum 
Austausch.

[Marcus (Gast)]

Hubi schrieb:
> Wäre
> nett wenn er dies durch diese hier ersetzen würde.

Ist bei mir drin und PR für das Hauptrepo angefordert.
Mit einen GIT Account könntest Du das auch selbst. Ich kann Dir die 
Schritte, wenn Du den Account hast gerne sagen (so wie ich es 
mache/gelesen habe). Am besten aber dann hier [[Du bräuchtest einen git 
Account]] sonst sprengen wir die Server von mikrokontroller.net ;-)

[Marcus (Gast)]

Marcus schrieb:
> Am besten aber dann hier [[Du bräuchtest einen git
> Account]]

[[https://github.com/dad401/ahoy/discussions]]

[Hubi (Gast)]

So, ich habe mir einen Git account zugelegt und meine SW dort mal 
reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation.
Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt 
geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, 
bitte gerne.

[Marcus (Gast)]

Hubi schrieb:
> So, ich habe mir einen Git account zugelegt und meine SW dort mal
> reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation.
> Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt
> geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will,
> bitte gerne.

Das ist nun die Frage - belassen wir alles im Haupt-Repo 
[[https://github.com/grindylow/ahoy]] oder führt jeder Entwickler sein 
eigenes? Ich kann diese Frage nicht beantworten.

Man könnte es ja so machen:
Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software 
lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas).

Aber das müsst ihr wissen. Mir wird nur etwas schwindlig wenn man immer 
alles zwischen den Forks synct ;)
Für mich wäre es einfacher wenn ich als Nutzer Hubis-Repo und Lukas-Repo 
bei mir forken kann und dort Änderungen per PR einbringen kann. Derzeit 
ist das irgendwie über zwei Ecken. <just my 2 cents>

Marcus

[Lukas P. (lumapu)]

Hallo Marcus,

wir sollten bei dem Hauptrepository bleiben, aber evtl. kannst du mich 
als 'Colloborator' hinzufügen, dann kann ich direkt die Pull-Request 
managen - denke ich (ich hab leider auch keine Github Erfahrung)

Repository -> Settings -> Colloborators

[Hubi (Gast)]

Hallo Lukas
Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie 
bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann 
meine weitere Entwicklung per Mail zukommen lassen. Bin auch der 
Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und 
wird dann unübersichtlich. Bin da offen. Deine wirklich sehr gute OOP 
Entwicklung wäre schon wert unterstützt zu werden.

[Sorbit (Gast)]

Hubi schrieb:
> Hallo Sorbit
> für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das
> aber keinen Fehler werfen.
>  Wenn du die Serial ausgeben willst, kannst du das so machen1
> sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned
> long)(serial&0xFFFFFFFFULL));

Hallo Ahoi, Hubi, oder wer auch immer dahinter steckt😄

Im Git Repository steht doch geschrieben, das der Code für Arduino mit 
ESP8266 als Taget gedacht ist.
Dann sollte der Compiler doch sauber durchlaufen.
Ich verstehe den Zusammenhang nicht.
Kann mir jemand auf die Sprünge helfen?

Danke

[Martin G. (petersilie)]

Ich lade gerne "Collaborators" in das AHOY Repository ein.

Schreibt doch hier im Thread kurz Eure Github-Namen und Euren 
Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als 
Collaborators hinzu.

Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich 
hier im Forum in der Minderheit!), aber ich stimme Marcus und den 
anderen zu, dass es insbesondere für Nutzer hilfreich ist, wenn die 
Entwicklung nicht an zu vielen unterschiedlichen Forks läuft.

Gruß

Martin (petersilie) / https://github.com/grindylow/ahoy


ps.
Habe gerade mal das Haupt-README mit direkten Verweisen auf die 
Unterprojekte aktualisiert. Für die Übersicht wäre es super, wenn jeder 
Autor für "sein" Tool ein kleines README hinzufügen könnte. Dann finden 
sich auch Fremde schnell zurecht. Als Beispiel/Vorlage kann z.B. 
https://github.com/grindylow/ahoy/tree/main/tools/rpi dienen.

[Petra R. (petra-kathi)]

Hallo Martin,

> Mein Interesse ist immer noch eher auf der Raspi-Version

Schön! Ich halte zumindest davon auch noch am meisten, was das effektive 
Entwickeln angeht, wenn auch der Ressourceneinsatz etwa bei einem ESP32 
deutlichst kleiner ausfällt, wenn er dann einmal als Webserver läuft.

Übrigens habe ich heute meinen NRF24_Sniffer zugeschickt bekommen und 
werde wohl in den nächsten Tagen das Dingens mal aktivieren. Wenn's dann 
klappt, hoffe ich, was zum HM-1500 beitragen zu können. Wobei ich hoffe, 
weitestgehend die Auslesung des HM-1200 übernehmen zu können.   ;-)

Tschüssi,
Petra

[Hubi (Gast)]

Hallo Sorbit
mit der Arduino IDE und Einstellung Lolin(Wemos) D1 R2 & mini lässt sich 
zB ein

Serial.println(String(serialNr,HEX))

ohne Fehler kompilieren. Ich benutze die IDE 1.8.13, nicht die neueste.

[Heinz R. (heijz)]

Martin G. schrieb:
> Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich
> hier im Forum in der Minderheit!),

welche Vorteile versprichst Du Dir davon?
Denke man sollte es möglichst einfach halten - und möglichst einfach ist 
halt der ESP8266

[andreas5232 (Gast)]

Nachdem ich bisher nur stiller Mitleser war, hier mein erster Beitrag. 
Sehr cool, was ihr hier schon gemeinsam geschafft habt! :-)

Heinz R. schrieb:
> welche Vorteile versprichst Du Dir davon?
> Denke man sollte es möglichst einfach halten - und möglichst einfach ist
> halt der ESP8266

Der ESP ist sicherlich ein guter Start, universell und aus meiner Sicht 
eine schöne Plattform. Ich persönlich würde es auf Dauer aber auch 
bevorzugen, wenn das System auf einem bestehenden Raspberry 
untergebracht werden könnte und ich keine zusätzliche Hardware dafür 
laufen lassen muss.

Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display 
zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell 
ablesbar zu machen.

[Martin G. (petersilie)]

Heinz R. schrieb:
> welche Vorteile versprichst Du Dir davon?
> Denke man sollte es möglichst einfach halten - und möglichst einfach ist
> halt der ESP8266

Der ESP8266/ESP32 ist sicher eine tolle Sache. Ich habe persönlich nicht 
primär das Nachbauen einer "DTU" im Kopf, sondern die Integration der 
Hoymiles-Wechselrichter in ein größeres Ökosystem.

Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man 
durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den 
Wechselrichtern einfach noch mitmachen lassen. Webinterface/Archivierung 
etc ist dann nicht Aufgabe der Hoymiles-Anbindung, sondern des 
übergeordneten Systems. Vielleicht ein bisschen wie die 
"DTU-Pro"-Anbindung via Modbus (wobei die DTU-Pro ja wohl auch ein 
Webinterface etc etc bietet).

Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier 
eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit 
NRF24 als auch mit Wifi auf 2.4 GHz.

Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" 
experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf.

Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. 
Das sind alles absolut gute Wege, und jede Alternative trägt ein 
bisschen zum Erkenntnisgewinn bei. Ich finde es prima, wie wir alle 
unsere Erfahrungen mit dem Protokoll zusammensammeln!

[Petra R. (petra-kathi)]

> Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display
> zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell
> ablesbar zu machen.

Jenau, man schaue z.B. unter 
https://tutorials-raspberrypi.de/esp8266-grafikdisplay-ssd1306-oled-bilder-text-anzeigen/

Wobei ich eher zum esp32 tendiere, weil der wohl bei minimalem Aufpreis 
etwas besser ausgestattet ist?

Tschüssi,
Petra

[Petra R. (petra-kathi)]

> Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier
> eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit
> NRF24 als auch mit Wifi auf 2.4 GHz.

Scho'recht, allerdings ist die Frage, wie stark die Hoymiles-Abfragerei 
das WLAN belastet. Ich möchte auch mal hinterfragen, ob es einen Sinn 
macht, sekündlich Werte abzufragen? Ich denke, wenn man alle 30 s 
einen Wertesatz holt, wird sich die Statistik nur sehr unwesentlich 
verschlechtern.

> Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv"
> experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf.

Das auf jeden Fall - das ist auch bei mir der Antrieb, damit anzufangen, 
um ...

> Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen.

... später, wenn alles so weit ausexperimentiert ist und nur noch 
gelegentlich mal nach dem Zustand geschaut wird, so was als 
Standardanzeige zu etablieren.

Zumindest fände ich es nett, hier eine Low-Power-Alternative zur 
Verfügung zu haben.  ;-)

Tschüssi,
Petra

[Marcus (Gast)]

Lukas P. schrieb:
> aber evtl. kannst du mich
> als 'Colloborator' hinzufügen

Das wäre dann aber petersilie - das Hauptrepo ist seins, hat er aber 
darunter bereits geschrieben:

Martin G schrieb:
> Ich lade gerne "Collaborators" in das AHOY Repository ein.
> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren
> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als
> Collaborators hinzu.

Mein GIT: [[https://github.com/dad401]]

Fokus: Nutzertests mit HM-400 (und HM-300), ggf. 
Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste 
Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht 
commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren 
Programmierkenntnissen beteiligt.

Martin G schrieb:
> Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man
> durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den
> Wechselrichtern einfach noch mitmachen lassen.

Ich finde es gut, dass es auch diese Alternative gibt, denn auch ich 
würde mir ggf. ein zusätzliches Gerät sparen. Ich habe inzw. alles 
kompiliert/konfiguriert, aber bekomme es noch nicht zum Laufen. Benötige 
ich da zwingend den MQTT-Server? Ich muss das nochmal genauer prüfen.
Einzig nachteilig (IMHO) ist leider das "Gefummel" (kompilieren statt 
einfach per apt installieren) mit den Bibliotheken. Solang das alles 
fehlerfrei klappt ist gut, aber wer weiß was mit dem nächsten RPi-Update 
passiert.

Petra R. schrieb:
> Ich möchte auch mal hinterfragen, ob es einen Sinn
> macht, sekündlich Werte abzufragen?

Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools 
berücksichtigt werden. Ich denke dies ist immer noch des ersten 
funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer 
stabil kommen. Ggf. macht man das Abfrageinterval einstellbar. Meine 
RRD-Datenbank befülle ich (von einem SonOff Pow R2) jede Minute. Wenn 
also stabil bei einer Abfrage eine Antwort kommt, dann reichen sicher 
30s Intervall aus.

[Ziyat T. (toe_c)]

Marcus schrieb:
> Hubi schrieb:

> Man könnte es ja so machen:
> Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software
> lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas).
>
Diesen Weg sollten wir gehen, denn es gibt noch viele ungelöste Dinge!
IMHO, es sollten unbedingt alle Infos Zentral sein.

Ich habe das Gefühl, dass bisher "nur" ein Paar WR Daten (und diese nur 
von HM's!) sichtbar sind, und schon wird hier über HW-Plattform 
diskutiert;-)

[Marcus (Gast)]

Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die 
Dokumente.

Hier eine weitere HM-300 Seriennummer:
11216281xxyy

Also ich leg mich fest, die HM-3xx und HM-400er beginnen mit immer 1121 
;)

[st_b (Gast)]

Vorweg: Super Arbeit - vielen Dank!

Die ESP8266 Version funktioniert mit einem HM-800 (114174...) 
Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc 
erwähnten Installation der Library "PubSubClient"):

    { FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
    { FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  }

In der kurzen Testphase kam es zu Hängern - ich vermute einen 
Zusammenhang mit geöffnetem Webinterface.

lg

[Lukas P. (lumapu)]

st_b schrieb:
> Die ESP8266 Version funktioniert mit einem HM-800 (114174...)
> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc
> erwähnten Installation der Library "PubSubClient"):

Hallo st_b ,
auf welcher Definition basiert deine Änderung, auf der vom HM600?
Doku werde ich nachziehen, danke für den Hinweis.

[Lukas P. (lumapu)]

Hubi schrieb:
> Hallo Lukas
> Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie
> bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann
> meine weitere Entwicklung per Mail zukommen lassen. Bin auch der
> Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und
> wird dann unübersichtlich. Bin da offen.

Hallo Hubi,
das liegt bei dir, ich finde es nicht falsch wenn du einen Git Account 
hast und direkt Änderungen per pull request einfließen lässt. Per Mail 
geht auch, dann checke ich es ein.

Deine wirklich sehr gute OOP
> Entwicklung wäre schon wert unterstützt zu werden.


Vielen Dank für die Blumen ;-)

[Lukas P. (lumapu)]

Lars B. schrieb:
> erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr
> gut lesbar.

Das ist mein Ziel: so wenig wie möglich kommentieren, lieber sprechen 
Code schreiben. Ist nicht immer ganz einfach, aber so bleibt das gesamte 
auch über Monate wartbar.

> Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich
> musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom
> "Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC
> Leistung. Also habe ich Zeile
> { FLD_IAC, UNIT_A,   CH0, CMD02, 15, 2, 10   },
> gegen
> { FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
> getauscht. - Jetzt passt es.
>
> Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
> { FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  },

Ich kann leider nicht nachvollziehen, ob diese Änderungen bereits per PR 
in das repo gekommen sind, falls nicht bitte noch anlegen.

> Die Visualisierung habe ich für mich noch auf die Schnelle um die
> AC-Werte erweitert. - Siehe Screenshot. :-)

Auch hier freue ich mich über einen PR in Git.

[st_b (Gast)]

Lukas P. schrieb:
> st_b schrieb:
>> Die ESP8266 Version funktioniert mit einem HM-800 (114174...)
>> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc
>> erwähnten Installation der Library "PubSubClient"):
>
> Hallo st_b ,
> auf welcher Definition basiert deine Änderung, auf der vom HM600?
> Doku werde ich nachziehen, danke für den Hinweis.

Ich habe die Definition des HM-600 angepasst. Vollständigkeitshalber sei 
erwähnt, dass die Werte ursprünglich von Lars B. stammen)

const byteAssign_t hm800assignment[] = {
    { FLD_UDC, UNIT_V,   CH1, CMD01,  3, 2, 10   },
    { FLD_IDC, UNIT_A,   CH1, CMD01,  5, 2, 100  },
    { FLD_PDC, UNIT_W,   CH1, CMD01,  7, 2, 10   },
    { FLD_UDC, UNIT_V,   CH2, CMD01,  9, 2, 10   },
    { FLD_IDC, UNIT_A,   CH2, CMD01, 11, 2, 100  },
    { FLD_PDC, UNIT_W,   CH2, CMD01, 13, 2, 10   },
    { FLD_YW,  UNIT_WH,  CH0, CMD02,  1, 2, 1    },
    { FLD_YT,  UNIT_KWH, CH0, CMD02,  3, 4, 1000 },
    { FLD_YD,  UNIT_WH,  CH1, CMD02,  7, 2, 1    },
    { FLD_YD,  UNIT_WH,  CH2, CMD02,  9, 2, 1    },
    { FLD_UAC, UNIT_V,   CH0, CMD02, 11, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH0, CMD02, 13, 2, 100  },
    { FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
    { FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  },
    { FLD_T,   UNIT_C,   CH0, CMD83,  7, 2, 10   }
};
#define HM800_LIST_LEN     (sizeof(hm800assignment) / sizeof(byteAssign_t))

[isnoAhoy (Gast)]

Hallo Marcus,

> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.

ich habe die Statistik der Seriennummern noch einmal sauber aufgeräumt 
und nach Seriennummer sortiert.
Wenn Ihr wollt, könnt Ihr die gerne einchecken, ich habe die auch nur 
weitergeführt.

Ich habe jetzt auch die Usernamen aus dem Forum ergänzt um zu sehen, von 
wem evtl. noch eine führende Ziffer zu bekommen wäre:

Arnaldo G. (arnaldo_g), martin (Gast), Oliver F. (of22), heijz, Carsten 
B. (carstenb) könntet Ihr eventuell hier im Forum oder direkt in der 
Tabelle Eure führenden Ziffern bzw. die Serien-/Modellnummer Eures 
Wechselrichters / DTU Modells ergänzen ?

Auch die ForistInnen mit einem MI- Wechselrichter der älteren Bauart 
müssten ggf. Ihre Seriennummern beisteuern, da hiervon außer dem TSUN 
TSOL-M800 von Daniel M. (Gast) noch keine hier bekanntgegeben wurde.

[isnoAhoy (Gast)]

Hier eine auf die ersten vier Stellen gekürzte Liste aus dem Excel,
das ich letzte Woche aktualisiert habe:

Name      | Serien
--------- | ------
MI-250    | 1020
MI-300    | 1021
MI-?      | 1022
MI-500    | 1040
TSOL-M800 | 1041
MI-1000   | 1060
MI-1200   | 1061
MI-1500   | 1061
MI-?      | 1062
HM-300    | 1121
HM-350    | 1121
HM-400    | 1121
HM-600    | 1141
HM-700    | 1141
HM-800    | 1141
HM-1200   | 1161
HM-1500   | 1161
DTU-G100  | 10D2
DTU-W100  | 10D3
DTU-Pro   | 10F7
DTU-Pro   | 10F8

Wie man sehen kann sind die Seriennummern nicht ganz eindeutig.
Aber es sollte von der Zahl der Anschlüsse bzw. MPPT die im 
Wechselrichter verbaut sind
eigentlich hinkommen, daß alle mit der selben Seriennummer zumindest 
einen ähnlichen
inneren Aufbau haben sollten.
Lediglich die maximale Leistung der Kanäle scheint sie noch zu 
unterscheiden.
Ich habe auch mal die Seriennummern der DTUs und unseres Exoten TSUN 
"TSOL-M800" aufgenommen.

[Martin G. (petersilie)]

Marcus schrieb:
>> Ich lade gerne "Collaborators" in das AHOY Repository ein.
>> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren
>> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als
>> Collaborators hinzu.
>
> Mein GIT: [[https://github.com/dad401]]
>
> Fokus: Nutzertests mit HM-400 (und HM-300), ggf.
> Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste
> Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht
> commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren
> Programmierkenntnissen beteiligt.

Einladung ist erfolgt!

> Man könnte es ja so machen:
> Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software
> lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas).

Das könnten wir auch gerne so halten. Ich habe leider ein bisschen den 
Überblick verloren, wer an welchem Teilprojekt in welcher Repo am 
aktivsten ist.

Gerne kann ich in der Haupt-Repo im README auf die jeweiligen anderen 
Repos verweisen, und dann im Laufe der Zeit auch die (dann veralteten) 
Unterverzeichnisse entfernen. Am besten würde ich dann auch die 
jeweiligen Autoren mit auflisten, oder?

Persönlich fände ich es gut, wenn wir die Doku 
(https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) 
im Hauptrepo (https://github.com/grindylow/ahoy) pflegen würden. Die 
können wir dann gerne auch versuchen, auszubauen und evtl. auf 
readthedocs.io o.ä. zu hosten. Mir fehlt nur gerade ein bisschen die 
Zeit - aber über die nächsten Wochen wird sich schon wieder Zeit 
finden...

[Martin G. (petersilie)]

isnoAhoy schrieb:
>> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.

Habe die aktuelle von @isnoAhoy zusammengestellte Liste jetzt zumindest 
mal dem Repo hinzugefügt: 
https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx

Ja, die Erkenntnisse daraus sollte ich (?) dann mal in die Haupt-Doku 
(https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) 
einfließen lassen...

[Martin G. (petersilie)]

Marcus schrieb:
> Petra R. schrieb:
>> Ich möchte auch mal hinterfragen, ob es einen Sinn
>> macht, sekündlich Werte abzufragen?
>
> Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools
> berücksichtigt werden. Ich denke dies ist immer noch des ersten
> funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer
> stabil kommen.

In manchen Programmen war/ist auch immernoch das "AutoACK" 
eingeschaltet. Das geht in die selbe Richtung: da wir schlüssig 
nachgewiesen haben, dass die WR kein AutoACK machen, bedeutet das 
faktisch, dass unsere Programme das jeweilige Paket mehrfach (ich meine 
15-fach) hintereinander aussenden. Das führt vermutlich zu 
"verlässlicherer" Kommunikation, flutet aber natürlich "unnötigerweise" 
das 2.4 GHz Band. Die bisherigen Erfahrungen zeigen, dass das eine DTU 
auf jeden Fall nicht ganz so "extrem" macht, und trotzdem "verlässlich" 
kommuniziert.

Langer Rede kurzer Sinn: später muss

* das AutoACK ausgeschaltet und
* das Poll-Intervall auf einen "sinnvollen" Wert (15s, 30s, evtl. noch 
langsamer)

...eingestellt werden.

[Robert Bleumer (Gast)]

HM1500 funktioniert hier auch mit ESP8266 und NFR24L01+ und die letzte

Seriennummer meine 1500 fangt auch mit 1161 an.

Steht upload nach PvOutput.org noch auf's Programm?

[Thomas B. (tbnobody)]

Hallo zusammen,

Jan (HM-600) und ich (HM-1500) haben gerade den ESP8266 und Python Code, 
die Byte Assignments usw. für beide Wechselrichter angeschaut.

Dadurch sind wir auf folgende Erkenntnisse / Theorien gekommen:
* Beim HM-600 macht der Weekly Counter keinen Sinn (bei Jan ist dieser 
höher als der vermeintliche Total)
* Der HM-1500 hat Total Spalten für jeden seiner 4 Eingänge
* Wenn der HM-600 der gleichen Struktur folgt, müsste dieser 2 Total 
Werte haben.
* Diese beiden Werte müssten jedoch 4 Byte haben
* Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 
keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht
* Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1)

Folgende Überlegungen:
Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen 
Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet.

Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert 
übergelaufen?
Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null 
sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4


Unabhängig davon haben wir einen Pull Request für AC I und P mit einem 
HM-600 erstellt:
https://github.com/grindylow/ahoy/pull/21

[Marcel A. (a-marcel)]

Guten morgen,

der Code von ahoy läuft jetzt auf meinem ESP32. Vielen Dank dafür. Ich 
habe einen HM400 und mir mal die Daten angeschaut und dazu mal eine 
Frage.

Es scheint ja ch0 und ch1 zu geben ? Ich gehe mal davon aus, das diese 
channel die MPPT Channels sind - stimmt das ? Wenn ja, dann wäre das für 
den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem 
Anschluss hat.

Was war denn der Plan hinter diesen Channel ? Ich kann es für den HM400 
ändern, sobald ich weiß wie das Konzept ist.

HM_400/ch1/U_DC: 38.000
HM_400/ch1/I_DC: 3.260
HM_400/ch1/P_DC: 123.700
HM_400/ch1/YieldTotal: 39.363
HM_400/ch1/YieldDay: 183.000
HM_400/ch0/U_AC: 229.400
HM_400/ch0/Freq: 50.030
HM_400/ch0/P_AC: 120.600
HM_400/ch0/I_AC: 0.530
HM_400/ch0/Temp: 30.100

Danke Marcel

[Marcel A. (a-marcel)]

Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das 
Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz 
abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra 
Steckdose brauchen würde.

Marcel

[Thomas B. (tbnobody)]

Hallo Marcel,

> Was war denn der Plan hinter diesen Channel ?

Channel 0 stellt Parameter dar die keinem direkten Input auf der DC 
Seite zugeordnet werden können (also z.B. AC Strom der AC Spannung). Da 
es beim HM-400 nur einen Eingang gibt, gibt es neben dem CH0 auch nur 
einen weiteren Kanal (CH1) welcher die DC Seite darstellt.

> Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das 
Einspeisen?
Nachdem es diesen Wert sowohl für den HM-600 (und kompatible) sowie für 
den HM-1500 (und kompatible wie HM-1200) gibt, würde ich vermuten das 
dieser auch für die Einkanal Geräte existiert. Es wurde wohl nur noch 
nicht herausgefunden welcher Wert dem entspricht.

[Sorbit (Gast)]

Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen 
ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?

Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert.
Meine Skills reichen nicht aus um die Fehler selbst zu beheben.

Wo stelle ich HM1200 und die Seriennummer ein?

[isnoAhoy (Gast)]

> Es scheint ja ch0 und ch1 zu geben ?
Richtig, CH0 dürfte allegemeiner Natur sein, sowas wie AC Seite des 
Wechselrichters und evtl. Temperatur.

> Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das?
Nicht ganz CH1..4 sind die MPPT Channel.

> Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT 
mit nur einem Anschluss hat.

In der Hoymiles Dokumentation bzw. der App zur Hoymiles DTU-Lite-S heißt 
CH0 auch "Output grid port" und die anderen Kanäle CH1 .. CH4 "Input 
port1..4".

Ich habe gestern noch ein wenig in den offiziellen Dokus gelesen und 
dabei habe ich noch eine Menge DTU und WR Seriennummern gefunden. Ich 
werde diese die Tage evtl. mal noch im Seriennummern XLSX nachtragen.

[isnoAhoy (Gast)]

Hallo Thomas B. und Jan,

> * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2
> keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht
> * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1)
Ich glaube die Vermutung hatten wir auch schon weiter oben auf Seite 4. 
Aber ich habe gerade keine Referenz. Vielleicht war das auch nur ein 
Gedanke als es sich herausgestellt hat, daß die Yield Total Werte in kWh 
ja vier Byte belegen.

> Folgende Überlegungen:
> Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen
> Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet.

Das wäre in der Tat sinnvoll, da die einzelnen Telegramme ja über den 
Rahmen jeweils mit einem CRC8 und ggf. CRC_M/16 (Modbus) gecheckt werden 
können. Vielleicht gibt es am Ende (0x8x Telegramm) ja auch noch eine 
weitere Prüfsumme ?

> Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert
übergelaufen?

Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die 
dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn 
diese Telegramme wie bisher immer einzeln verarbeitet werden.
@Lukas P. bei den HM-1000/1200/1500 habt ihr ja alle vier Byte in einem 
Telegramm. Für die HM-600/700/800 bräuchten wir in der Tat so einen 
Übertrag oder eine Kombination aller Teilinformationen der Telegramme um 
die ganze Nachricht zu parsen.

> Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null
> sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4

Wie gesagt das hatte ich auch angenommen, weiß jetzt aber nicht ob 
wirklich jemand seinen HM-600/700/800 schon zum "Überlauf" in das erste 
Telegramm gebracht hat. Dauert ja logischerweise auch doppelt so lange 
wie bei den größeren HM-1000/1200/1500 =^D
Meiner wartet noch auf die Montage der Solarpanele bevor er richtig 
einspeißen darf.

[isnoAhoy (Gast)]

> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?
>
> Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert.
> Meine Skills reichen nicht aus um die Fehler selbst zu beheben.
>
> Wo stelle ich HM1200 und die Seriennummer ein?

Hallo Sorbit, schau mal auf der Anleitung nach:
https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den 
ESP8266 zu kompilieren. Prüfe mal folgendes:
* Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support 
herunterladen)
* die beiden RF24 und TimeLib Bibliotheken im Library Manager 
installieren.
@Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der 
ESP8266 Boards Umgebung ?

Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem 
o.g. Github aufmachen, damit wir die Dokumentation erweitern und die 
Schritte die Dir fehlen nachreichen ?

https://github.com/grindylow/ahoy/issues

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> brauchen wir auch die Ticker Bibliothek oder ist die Teil der
> ESP8266 Boards Umgebung ?

Ich denke nicht, da diese direkt von der ESP8266 Bibliothek mitgeliefert 
wird. (Hier wird sich in naher Zukunft auch noch was ändern, ich 
diskutiere hier gerade mit stefan123t auf Github.)

Sorbit schrieb:
> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?

Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier 
angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP 
auf die /setup Seite gehen und dort alles konfigurieren.

Marcel A. schrieb:
> Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das
> Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz
> abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra
> Steckdose brauchen würde.

Das Yield Total ist doch genau das Feld. In der neuen Version sind auch 
Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, 
dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 
habe ich mal 4 beispielhafte Berechnungen definiert)

[Thomas B. (tbnobody)]

isnoAhoy schrieb:
> Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die
> dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn
> diese Telegramme wie bisher immer einzeln verarbeitet werden.

Die Schwierigkeit wäre dann auch noch, wenn es wenn es zu Paketverlusten 
beim Überlauf kommt. Also wenn man z.B. beim HM-600 bleibt und der Total 
Wert wirklich über zwei Telegramme verteilt ist könnte es ja zu 
folgendem Szenario kommen:

* Anfrage senden
* Antwort Paket ID 1 geht verloren
* Antwort Paket ID 2 kommt durch und der Total Wert steht bei 0xFF 
0xFF...
* Paket ID 1 wird erneut angefordert
* Jetzt gab es den überlauf, die letzten beiden Bytes in Paket 1 sind 
0x00 und 0x01.
* Sollte man jetzt beide Pakete einfach zusammensetzen hätte man ja 0x00 
0x01 0xFF 0xFF
* In Wirklichkeit sollte es aber 0x00 0x01 0x00 0x00 sein
* Man müsste also auch Paket 2 neu anfordern

[Marcel A. (a-marcel)]

Hallo,

Lukas P. schrieb:
> Das Yield Total ist doch genau das Feld. In der neuen Version sind auch
> Berechnungen möglich, die werden auch in der hmDefines.h eingetragen,
> dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200
> habe ich mal 4 beispielhafte Berechnungen definiert)

Da würde ich nicht mitgehen. Das was ich gemessen habe, entspricht nicht 
dem Yield Total. Es weicht 1% ab. Ich würde sagen, das YieldTotal eben 
die Gesamtenergie der SolarPanele ist. Laut Datenblatt haben die 
Hoymiles auch einen Wirkungsgrad in dem Bereich - 99%.

Rechnen bringt mir leider nicht viel, da ich einen totalen Wert (immer 
steigend) brauch (auch nach einem Neustart). Was man simulieren könnte, 
wäre das ich 1% vom Yield Total abziehe und diesen Wert dann als AC 
Energy Total nutze.

Anbei ein Screenshot wo man den Unterschied zwischen AC und DC sieht.

Marcel

[IsnoAhoy (Gast)]

Hallo Thomas B.,
ja das ist noch ein zusätzliches Grund. Ich dachte nur daran was es für 
Werte mit den niederwertigen Daten aus Paket 2 ohne die höherwertigen 
Daten aus Paket 1 ergibt, bzw. wie man diese zwischenspeichert bis das 
zweite Paket auch da ist.
In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, 
[0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn 
alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind.

@Lukas P. da könnte der Link zur State-Machine vielleicht nochmal 
hilfreich sein:
https://hackaday.com/2015/09/04/embed-with-elliot-practical-state-machines/

[Lukas P. (lumapu)]

IsnoAhoy schrieb:
> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …,
> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn
> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind.

Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben 
hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. 
geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) 
oder einen Gesamt-CRC.

Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu 
anderen Messeinrichtungen? Ich messe mit einem selbst programmierten 
Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung.
Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh 
gemessen hat. Das enspricht einer Abweichung von ca. 4%.
Wenn ich die aktuelle Leistung vergleiche, dann sind beide Messungen bis 
100W nahezu identisch, bei 1000W habe ich schon eine Abweichung von 
knapp 100W.

Danke für den State-Machine Link - sehr schön beschrieben. Ungefähr bei 
der hälfte habe ich schon an Funktionpointer gedacht ;-)

@ESP8266: neue Version 0.3.3 liegt im Git. Umstellung von Ticker zu 
millis(), Visualisierung zeigt jetzt alle bekannten Werte.

[Peter L. (leliep)]

Lukas P. schrieb:
> Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu
> anderen Messeinrichtungen? Ich messe mit einem selbst programmierten
> Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung.
> Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh
> gemessen hat. Das enspricht einer Abweichung von ca. 4%.

Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut 
AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% 
Abweichung.

[Marcel A. (a-marcel)]

Hallo Lukas,

> Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu
> anderen Messeinrichtungen?

Also ich messe mit einem ESP und einem PZEM-004T mit Stromklemme. Ich 
hatte die Werte damals mit einer Fritz! Steckdose verglichen und die 
stimmten immer sehr genau.

Jetzt, wo wir die Werte vom Hoymiles haben, sehe ich, dass die ziemlich 
die gleichen sind, wie gemessen. Ich werde die aber mal demnächst genau 
übereinander legen. Hab seit heute alle Daten in HomeAssistant.

Das einzige was ich sagen kann ist, das die Totalsumme 1% abweicht. Da 
vermute ich aber, dass dieses nicht die AC Leistung ist sondern DC.

Marcel

[Mich@ (Gast)]

Hallo Leute,

Vielen dank für die neue Version.
Die 0.3.2 läuft stabil mit dem Wemos.
MQTT läuft auch reibungslos. Einen Wunsch hätte ich noch, wenn die 
Verbindung zum Wechselrichter nach Sonnenuntergang abreißt bleiben die 
letzten Werte noch im Webinterface und in MQTT stehen. Ist es möglich 
die Werte nach Sonnenuntergang wenn zb. 10 Minuten lang keine Werte 
kommen auf 0 zu setzen? Außer natürlich die Ertragswerte…

Vielen Dank

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> IsnoAhoy schrieb:
>> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …,
>> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn
>> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind.
>
> Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben
> hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl.
> geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge)
> oder einen Gesamt-CRC.

Das ist richtig. Hilft nicht gegen nicht empfangene Pakete. Andere 
Baustelle. Soweit verschlechtert das sogar die Empfangsrate, ist aber 
für den HM-600 zwingend notwendig, weil z.B. der DC kWh total von String 
1 sehr sicher genau fragmentiert ist.

Vorab, die fragmentierten Werte aus verschiedenen Requests zusammen zu 
stückeln ist nicht möglich, weil bei einer Werteänderung über das 
Fragment hinaus zu unterschiedlichen Zeiten sehr falsche Werte heraus 
kommen. Also kein Cache einzelner Fragmente (cmd'd) möglich! Man kann 
allerdings versuchen trotzdem irgendwie Werte zu retten, die nicht über 
mehrere Fragmente verteilt sind. Währe aber sehr viel Aufwand.

Die Fragmente werden darüber henaus auch nicht in der richtigen 
Reihenfolge empfangen.

Ich werde die Tage noch ein PR für ein Rewrite der 
Python-Implementierung einreichen. Ich bin gerade dabei das in Klassen 
und ein Hoymiles Modul zu zerlegen, so kann man dann damit besser 
Tinkern oder z.B. auch mal ein Logfile mit Rohdaten durch pipen.

Und soweit ich das sehe ich das letzte byte in den 0x8n-Responses die 
crc8 über die zusammengesetzte Payload. Jedenfalls stimmt das verdächtig 
zuverlässig.
Also der Ansatz mit den cmd's und channeln ist damit mal begraben, würde 
ich sagen.

Das wars jetzt mit dem Wochenende. Ist eh vorbei :)

Gruß,
Jan

[Marcus (Gast)]

Martin G. schrieb:
> In manchen Programmen war/ist auch immernoch das "AutoACK"
> eingeschaltet.

Auf der Suche nach Gründen, warum der ESP8266 oft hängt bzw. einen 
Watchdog-Reset auslöst habe ich auch folgendes interessante Detail 
gefunden:
 [[https://github.com/nRF24/RF24/issues/244#issuecomment-357210585]]

AutoACK sollte demnach am besten aus sein. Es gibt wohl (gefälschte) 
NRF-Chips, welche damit Probleme machen.
Allerdings ist AutoACK bereits bei den hier verwendeten Tools (esp8266, 
NRF24_SendRecv) aus.

> Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu
> anderen Messeinrichtungen?

Bei meinem HM-400 sind YieldTotal/YieldDay recht nah an meinem SonOff 
Pow R2 (ebenfalls mit 60W, oder waren es 100W Glühlampe?, kalibriert.) 
Der HM-Wert ist leicht höher. Hier sollte man aber am besten einen 
kalibrierten Wechselstromzähler als Vergleich nehmen. Die Kalibrierung 
der SonOff könnte da nicht so gut sein.

Es scheint also weiter unklar, ob YT und YD beim 400er nun AC oder DC 
Werte sind. Mit Blick auf die 600er/1200er müssten es ja auch DC-Werte 
(Modulwerte) sein. Entweder die Typen sind da komplett unterschiedlich 
zu bewerten oder es fehlt generell der AC Wert für YT/Yx.

Idee: Anhand der DC Werte für P kann man ja YT/YD für einen bestimmten 
Zeitraum selbst berechnen und dies mit dem ausgelesenen Werten YT/YD 
vergleichen.
Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher 
sein, da der WR in die Begrenzung geht und damit bei AC weniger 
"herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in 
dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für 
das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert 
anliegt, da Begrenzung).
Ich rechne das mal für den 400er YD/YT Wert nach.

[Nomen est Omen (Gast)]

Lukas P. schrieb:
> Sorbit schrieb:
>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?
>
> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier
> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP
> auf die /setup Seite gehen und dort alles konfigurieren.

Das ist supernett, danke!

Ich probier es ASAP aus.

BG

[Sorbit (Gast)]

Nomen est Omen schrieb:
> Lukas P. schrieb:
>> Sorbit schrieb:
>>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
>>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?
>>
>> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier
>> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP
>> auf die /setup Seite gehen und dort alles konfigurieren.
>
> Das ist supernett, danke!
>
> Ich probier es ASAP aus.
>
> BG

Sorry für den faschen Namen, ich bin an einem anderen Rechner in einer 
anderen "Welt"...

Richtig wäre Sorbit, gewesen.
Der Ersteller des Threads, der sich wundert was er hier "angestellt" 
hat.
Toll welcher Enthusiasmus sich hier verbreitet hat!

Hut ab

[Andreas E. (andreas5232)]

Peter L. schrieb:
> Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut
> AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2%
> Abweichung.

Ich habe hier einen Sonoff Dual R3, um den Ertrag meines HM-600 zu 
messen. Kalibriert habe ich damals mit einer 60W Glühbirne. Bei mir sind 
es heute bisher 1,318 kWh (Sonoff) und 1,426 kWh (AHOY 0.3.3). Bei den 
gemessenen Watt liegt der Sonoff aktuell (keine Voll-Last) jeweils ca. 
10-20 Watt unter dem per AHOY gemessenen Wert.

Marcus schrieb:
> Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher
> sein, da der WR in die Begrenzung geht und damit bei AC weniger
> "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in
> dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für
> das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert
> anliegt, da Begrenzung).

Falls uns das hilft: Ich habe auch Zugriff auf eine zweite Anlage mit
HM-600 und zwei "großen" Modulen, die bei guter Sonne regelmäßig in die 
Begrenzung des Wechselrichters laufen. Evtl. können wir durch die 
Beobachtungen ja das AC/DC Rätsel lösen.

[Hubi (Gast)]

Meine Anlage besteht aus HM-600 und 2 Module mit je 370 Wp, also 740 Wp. 
Der höchste gemessene Wert für die aktuelle Leistung war 612 W. Wenn das 
DC sein sollte müsste es schon mehr sein, m.E.
Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal 
kurzzeitig (wie hier) drüber sein?

[Carsten B. (carstenb)]

Hubi schrieb:
> Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal
> kurzzeitig (wie hier) drüber sein?

Hallo,

ich habe 700Wp an meinem HM600 und auf meinem shelly habe ich AC-seitig 
schon etwas über 600W gesehen. Meist so um die 620W.

Lieder habe ich grade keine DC-Daten, da ich nicht mitlogge. Ich habe 
leider etwas den Anschluss zum Projekt verloren. Was ist denn der 
sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich 
da.


Carsten

[isnoAhoy (Gast)]

> Ich habe  leider etwas den Anschluss zum Projekt verloren. Was ist denn der
> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich
> da.

Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten 
zu empfangen.
Den kannst Du entweder mit
* Deinem D1mini (ESP8266/ESP32) und der ahoy Software unter 
tools/esp8266 (v0.3.2/3) von Lukas P.oder
* einem Raspberry Pi und der ahoy Software unter tools/pi von Martin G. 
betreiben.

Anleitung zur Verdrahtung des ESP findet sich unter
https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

@Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine 
config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte 
Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben 
könnte. Dann müsste man sich nicht immer erst mit dem Access Point 
verbinden und könnte diese Settings hart verdrahten. Zumindest in der 
Entwicklungsphase würde mir das eine Menge Tipparbeit im WebInterface 
ersparen. Ich habe nämlich jetzt mehrfach den kompletten Flash erased, 
da ich hier Probleme bei der Umstellung des Speicher-Layouts der 
Konfigurationsdaten vermutet habe. Auch scheint er den Access Point 
aufzumachen, wenn er das lokale WiFi Netzwerk (wegen Empfang) nicht 
erreichen kann. Gibt es auch einen Fallback, daß er immer mal wieder 
versucht das Netzwerk zu erreichen ?

[Herbert K. (avr-herbi)]

isnoAhoy schrieb:
> @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine
> config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte
> Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben
...
Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im 
EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update 
(Fehlerbehebung) sich nicht ändern.
Ganz am Anfang dann die Länge von so einem Block.
Darüber dann eine CRC bilden.
Beim Neustart, dann die Länge aus dem EEPROM lesen. CRC abchecken und 
wenn so weit ok, dann mit den Werten starten ?
Am Ende von so einem Block würde ich das so gestalten, das sich die 
Anzahl der WR ändern kann, evt. auch einzelne CRC s  über WR Blöcke. 
Wenn sich dann jemand einen zusätzlichen WR kauft und einhängen will, 
kann alles so bleiben und er muss nur die SN / Typ des neuen WR 
eingeben. Dann wird der entsprechende Block am Ende drangehängt, mit 
einer CRC versehen und man kann weiter Software Updates machen ohne 
irgendwas einzugeben.
Ist nur mal so eine Ideeeeeee  :-)

[Petra R. (petra-kathi)]

Hallo zusammen,

nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern 
mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der 
ahoy.conf für einen HM-1500
(...
[inverter]
serial = 116173415022
)

... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo 
pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 
ahoy.py" leider den Anschiss ...

ModuleNotFoundError: No module named 'RF24'

Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit 
...

ModuleNotFoundError: No module named 'cross.crossunixccompiler'

... hängen. Ich habe darauf hin mit

"sudo pip3 install cross" das umfassende Modul nachinstalliert, das ja 
dieses 'crossunixccompiler' enthalten sollte. Das ist auch ohne 
Fehlermeldung durchgelaufen. Es bleibt aber das Problem mit dem RF24, 
weil nach wie vor die Compilation von RF24 nicht durchläuft:

Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.
ERROR: Could not find a version that satisfies the requirement RF24
ERROR: No matching distribution found for RF24

Eine Suche nach "crossunixccompiler" war leider erfolglos, so dass ich 
da aktuell nicht weiter komme.

Der Vollständigkeit halber: uname -a liefert:
Linux raspberrypi 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 
armv7l GNU/Linux

Bliebe die Frage: Wo ist der Haken?


Ergänzungs-Verständnisfrage zum Ahoy-Paket:
Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles 
wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann?

Tschüssi,
Petra

[Lukas P. (lumapu)]

Vielen Dank für die zahlreichen Infos zu euren Vergeleichsmessungen. 
Jetzt habe ich einfach mal den Multiplikator meiner Kalibrierung 
(Sonoff) wieder auf 1.00 gestellt und habe jetzt identische Werte mit 
dem WR. Bei Gelegenheit werde ich nochmal mit einer Fritz! Steckdose 
gegenchecken.

isnoAhoy schrieb:
> Gibt es auch einen Fallback, daß er immer mal wieder
> versucht das Netzwerk zu erreichen ?

Das prüfe ich nochmal, sowas hatte ich mal im Sinn weiß aber nicht ob's 
hier implementiert ist. Finde ich auf jeden Fall sinnvoll.

Herbert K. schrieb:
> Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im
> EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update
> (Fehlerbehebung) sich nicht ändern.
> Ganz am Anfang dann die Länge von so einem Block.
> Darüber dann eine CRC bilden.

Danke fürs Feedback. Ja hier ist noch Handlungsbedarf, ich weiß nicht 
mehr wie oft ich die Daten schon neu eingegeben habe. Ich werde es 
nochmal durchdenken und evtl. auch gleich umsetzen. Meiner Meinung sind 
nach der Aufteilung von WiFi und Sonstigen Settings (haben jeweils einen 
unabhängigen CRC) in getrennte Bereiche keine WiFi-Daten mehr verloren 
gegangen. (Klar da war noch der Issue mit der Passwortlänge, diese wurde 
auf 63 Zeichen angehoben)

[Martin G. (petersilie)]

Petra R. schrieb:
> Hallo zusammen,
>
> nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern
> mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der
> ahoy.conf für einen HM-1500
> (...
> [inverter]
> serial = 116173415022
> )
>
> ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo
> pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3
> ahoy.py" leider den Anschiss ...
>
> ModuleNotFoundError: No module named 'RF24'
>
> Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit
> ...

Hallo Petra,

die Installation des RF24-Moduls ist leider etwas komplizierter. Ich 
habe versucht, das in 
https://github.com/grindylow/ahoy/tree/main/tools/rpi einigermaßen zu 
beschreiben.

Im Prinzip sollte es reichen, der Anleitung für Python 3 auf

* https://nrf24.github.io/RF24/md_docs_python_wrapper.html

...zu folgen.

Wobei ich auf meinen beiden Raspis zuvor jeweils auch

* https://nrf24.github.io/RF24/md_docs_linux_install.html

...gemacht habe. Bin mir aber nicht mehr ganz sicher, ob das wirklich 
notwendig ist.

Einfach nur mit "pip" geht bei dieser Bibliothek wohl (noch) nicht.


> Ergänzungs-Verständnisfrage zum Ahoy-Paket:
> Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles
> wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann?

Ja leider richtig. Das entstand, als wir noch der Annahme waren, dass 
die WR AutoACK aktiviert hätten. Schön wär's gewesen :-(. So findet es 
nur andere NRF24-Empfänger, die AutoACK aktiviert haben. Leider quasi 
nutzlos.

-- petersilie

[Martin G. (petersilie)]

Ich habe jetzt wider Erwartens doch noch meine DTU-lite bekommen, und 
würde mal versuchen, sie in Betrieb zu nehmen.

Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem 
Einrichtungsvorgang "zuhören"? Kanal 40?

-- petersilie

[Herbert K. (avr-herbi)]

Martin G. schrieb:
...
> Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem
> Einrichtungsvorgang "zuhören"? Kanal 40?
...
> -- petersilie

Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen  :-)
MOSI, MISO, usw.
https://www.az-delivery.de/products/saleae-logic-analyzer
Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom 
LA klar kommst, dann die PINs im DTU-Lite :-)  so ist das gemeint von 
mir.
Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als 
Hex anzeigen. Bin mir aber nicht mehr 100% sicher.
Muss ja beim 1. Schuss am DTU-Lite zu 100% funktionieren - wir wissen ja 
nicht, was sich der alles merkt.  :-)
Den LA gibts natürlich auch bei anderen Anbietern.

[martin (Gast)]

Herbert K. schrieb:
> Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen  :-)
> MOSI, MISO, usw.

Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner 
DTU festgestellt hatte:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E 
handelt, der einen eigenen Controller drin hat.

[Olaf A. (Gast)]

Erstmal für Seriennummernsammlung vorweg.

HM-800  11417420xxyy
HM-1500 11616320xxyy
MI-1200 10616090xxyy

Ich bin diesem Thread schon lange gefolgt, wollte mich aber erst melden, 
wenn ich Daten von meinen beiden Wechselrichtern empfangen konnte.

Hatte mir das NRF24LE01+ mit externer Antenne gekauft und einige D1 mini 
V3, hatte jedoch nie Empfang. Kaufte verschiedene NRF24LE01+ und testete 
alle möglichen Kombinationen durch. Erst als ich D3 und D4 auf D1 und D2 
umverdrahtete, mit der entsprechenden Setup-Änderung, konnte ich 
problemlos alles empfangen.

Vielleicht kann sich einer von euch einen Reim darauf machen, warum D3, 
D4 bei mir nicht funktionieren.
-- olaf

[Carsten B. (carstenb)]

isnoAhoy schrieb:
>> Ich habe  leider etwas den Anschluss zum Projekt verloren. Was ist denn der
>> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich
>> da.
>
> Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten
> zu empfangen.

Hallo,

danke für den Input. Mit einem Arduino nano hatte ich hier ja Anfangs 
schon Daten mitgeloggt... Dann schau ich mal, ob ich es heute Abend 
vielleicht auf dem ESP zum laufen bekomme.

Carsten

[Herbert K. (avr-herbi)]

martin schrieb:
> Herbert K. schrieb:
...
> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
> handelt, der einen eigenen Controller drin hat.
...
Entschuldigung !  Daran hatte ich nicht mehr gedacht.

[isnoAhoy (Gast)]

Hallo martin & Herbert,

> > Herbert K. schrieb:
> ...
> > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
> > handelt, der einen eigenen Controller drin hat.
> ...
> Entschuldigung !  Daran hatte ich nicht mehr gedacht.

Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für 
RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal 
anbei.

Eventuell könnte man auch mit dem openocd Debugger am SWD Port den 
GD32F303 anhalten und Flash Programm, etc. genauer analysieren. Es gibt 
m.W. eine eigene target/gd32f30x.cfg mit der es m.E. nach bei mir 
funktioniert hat den GD in einem MH-Z19C Sensor anzusprechen.

https://github.com/gd32-rs/gd32-openocd/blob/master/target/gd32f30x.cfg

Bei einer schnellen Suche nach "openocd gd32" kamen gerade noch die 
folgenden beiden evtl. interessanten Links heraus:

https://registry.platformio.org/tools/communitygd32cores/tool-openocd-gd32
https://github.com/stlink-org/stlink/issues/769

Wobei ich in meinem Fall keinen Erfolg mit dem bestehenden 
target/st-linkv2.cfg hatte.

[B. G. (golf2010)]

Martin G. schrieb:
> Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem
> Einrichtungsvorgang "zuhören"? Kanal 40?

Ideal wäre halt eine breitbandige Aufzeichnugsmöglichkeit mit einem 
HackRF oder ähnlichem besseren SDR, da ja mehrere Frequenzen in Frage 
kommen. Ich hab meine Aufzeichnungen mit einem BladeRF gemacht, der 
macht dann ca 60 Mhz Bandbreite. Vorhanden ist bei mir u.a. der LimeSDR 
, BladeRF, HackRF.

Oder evtl reicht auch ein NRF24L01-Sniffer, der zuverlässig die in Frage 
kommenden Frequenzen abscannen kann. Durch die Sende-Wiederholungen 
gibts da  normal keine Zeitprobleme.

[Sorbit (Gast)]

isnoAhoy schrieb:
> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
>
> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den
> ESP8266 zu kompilieren. Prüfe mal folgendes:
> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support
> herunterladen)
> * die beiden RF24 und TimeLib Bibliotheken im Library Manager
> installieren.
> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der
> ESP8266 Boards Umgebung ?
>
> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem
> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die
> Schritte die Dir fehlen nachreichen ?

@ Lukas, @isnoahoy,

der Geier weiß warum; Erfolg;-)
Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen 
und nun läuft der Compiler fehlerfrei durch!!!

DANKE!!!

[Sorbit (Gast)]

Sorbit schrieb:
> isnoAhoy schrieb:
>> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
>>
>> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den
>> ESP8266 zu kompilieren. Prüfe mal folgendes:
>> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support
>> herunterladen)
>> * die beiden RF24 und TimeLib Bibliotheken im Library Manager
>> installieren.
>> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der
>> ESP8266 Boards Umgebung ?
>>
>> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem
>> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die
>> Schritte die Dir fehlen nachreichen ?
>
> @ Lukas, @isnoahoy,
>
> der Geier weiß warum; Erfolg;-)
> Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen
> und nun läuft der Compiler fehlerfrei durch!!!
>
> DANKE!!!

Ich habe den NRF noch nicht angeschlossen (verdammt wo liegt der rum?)
Mit dem AP kann ich mich verbinden, anpingen, Webseite bleibt aber leer.

Ich denke das ist "normal" so wenn der NRF noch nicht dranhängt?
Danke,


ich suche weiter...

[Petra R. (petra-kathi)]

Sodele,

ich habe jetzt das ahoy.py auf einem Raspi 3B mit einem HM-1500 zur 
Kommunikation bekommen und sehe erste Returns:

2022-05-03T07:20:30.553251Z MSG src=73415022, dst=73415022, cmd=1:
{"ts_unixtime": 1651555230.553251, "isodate": 
"2022-05-03T07:20:30.553251", "rawdata": "95 73 41 50 22 73 41 50 22 01 
00 01 01 4e 00 1a 00 14 00 56 00 42 00 00 08 0b c3", "crc8_valid": true, 
"mid": 149, "response_time_ns": 18257366, "ch_rx": 3, "ch_tx": 40, 
"src": "73415022", "name": "dcdata", "dst": "73415022", "cmd": 1, 
"u1_V": 33.4, "i1_A": 0.26, "p1_W": 2.0, "u2_V": 8.6, "i2_A": 0.66, 
"p2_W": 0.0, "p_W": 2.0, "unknown1": 1, "unknown2": 2059}
2022-05-03 09:20:30.601844 Received 27 bytes on channel 3 pipe 1: 95 73 
41 50 22 73 41 50 22 02 00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c 
e3
2022-05-03T07:20:30.602257Z MSG src=73415022, dst=73415022, cmd=2:
{"ts_unixtime": 1651555230.602257, "isodate": 
"2022-05-03T07:20:30.602257", "rawdata": "95 73 41 50 22 73 41 50 22 02 
00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c e3", "crc8_valid": true, 
"mid": 149, "response_time_ns": 67262961, "ch_rx": 3, "ch_tx": 40, 
"src": "73415022", "name": "acdata", "dst": "73415022", "cmd": 2, "u_V": 
2.3, "f_Hz": 0.21, "p_W": 7.6, "wtot1_Wh": 0, "wtot2_Wh": 12, 
"wday1_Wh": 9, "wday2_Wh": 334, "uk2": 2939}

So ganz glauben tu' ich den Werten allerdings noch nicht.  :-)
Nicht mal u1_V und i1_A: Auch wenn die Sonne gerade nicht prall auf das 
180 W_p Modul scheint, sollten da doch etwas mehr als 0,26 A bzw. 2 W 
kommen, oder?

Fragt sich jetzt, wie ich den Interpretations-Gurus unter euch 
bestmöglich in die Seite treten kann?

Noch eine Beobachtung, den Raspi betreffend: Wenn ich den (aus 
Stöpsel-Faulheit) nur per WLAN anspreche, scheint der des Öfteren hängen 
zu bleiben. Nach Anschluss per LAN-Kabel scheint dies nicht mehr 
aufzutreten. Kann es sein, dass dessen WLAN und der nRF24 sich 
gegenseitig beim Funken ins Gehege kommen?

Tschüssi,
Petra

[Andreas E. (andreas5232)]

Robert Bleumer schrieb:
> Steht upload nach PvOutput.org noch auf's Programm?

Ich denke aktuell liegt das Hauptaugenmerk noch auf dem korrekten 
auslesen der Daten. Aber später gibt es bestimmt die Möglichkeit, eine 
Anbindung zu PvOutput.org einzubauen.

Die Doku dazu sieht relativ ausführlich aus, sodass es denke ich gut 
machbar wäre. https://pvoutput.org/help/index.html

[Petra R. (petra-kathi)]

Hallo Martin,

danke schön für deine Erklärungen! Mittlerweile läuft's ja, wie man an 
meinem letzten Post sehen kann.  thumbs_up

> Im Prinzip sollte es reichen, der Anleitung für Python 3 auf
>
> * https://nrf24.github.io/RF24/md_docs_python_wrapper.html
>
> ...zu folgen.

Das habe ich gemacht, bin aber auf einige Ungereimtheiten in der Abfolge 
gestoßen. Dies nur als Warnung für Nachfolgende, die es nach dieser 
Anleitung wortwörtlich probieren.

Letztlich muss ich übrigens das ahoy.py auch mit sudo aufrufen, sonst 
will es nicht.

Irgendwie scheine ich mich aber insgesamt wohl durchgewurschtelt zu 
haben.  ;-)

Viele Grüße,
Petra

[Herbert K. (avr-herbi)]

Guten Morgen !
Wie und wann und unter welchen Umständen die Kanäle gewechselt werden 
weiss ja scheinbar noch niemand (oder doch?).
Nur mal so als Idee: Die NRF24L01+ Module kosten ja nicht die Welt. Was 
spricht denn gegen den Einsatz von 5 Stk. - jedes auf einem festen Kanal 
?
Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?

[Jan-Jonas S. (janjonas_s)]

Moin,

ich baue ja in der Python-Implementierung am empfang der vollständigen 
Payload vom Wechselrichter. Weil noch sehr "work in progress" gibts da 
noch kein PR zu. Nur so zur Info. Oben schrieb ich, die Zusammengesetzte 
Payload ist mit der crc8 im letzten byte der Payload der 0x8n-Fragmente 
signiert. Es ist jedoch ModbusCRC. Definitiv.

Ich hab das bei mir so nebenbei laufen und bekomme sehr gute Ergebnisse. 
Zur Zeit ist nur der HM-600 implementiert, weil der mit dem Ansatz des 
Auswertens von Payload-Fragmenten eben nicht vollständig lesbar ist. Was 
anderes habe ich nicht.

Was ich vor dem PR noch tun will:
 * Dekoder neu implementieren (bloß schnell hin gepfuscht als Beiwerk 
zum PoC)
 * PayloadBuilder bauen
 * Inverter-Klasse als Interface
 * Multi-Inverter

Wie in der test.py zu sehen ist, lassen sich damit auch Logfiles mit 
Rohdaten neu auswerten. Sehr gut zum nachts entwickeln. ;)

https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi (Preview, 
wird sicher noch ein paar mal amended)

Der Output läuft bei mir aus Faulheitsgründen in eine vergleichbare 
Topic-Struktur, wie auch Shelly sie verwendet. Damit frisst der telegraf 
das gleich in die richtigen Influx measurements weg.

Gruß,
Jan

[Klaus K. (Gast)]

Ich hätte da mal eine grundsätzliche Frage: beim Nordic Protokoll, dass 
die Daten seriell fliessen ist schon klar aber wird da eigentlich MSB 
oder LSB zuerst geschickt?

Ich dachte bisher immer MSB first, aber das passt überhaut nicht mir der 
Anzeige meines LA (SALEAE/Sigrok) zusammen. Die Anzeige meines DSO 
(Batronix Rigol DS1054Z, alle Optionen freigeschaltet) decken sich damit 
auch nicht.

Ich habe schon probiert wie wild, komme damit aber nicht so recht 
weiter. Wer kann helfen?

[B. G. (golf2010)]

Herbert K. schrieb:
> Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?

Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme 
vermissen.

[isnoAhoy (Gast)]

> > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?
> Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme
> vermissen.

Das hatte Oliver F. bereits am 16.04.2022 auf Seite 3 mit einem hübschen 
Modell mit insgesamt sechs NRF24L01+ vorgeschlagen.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

@Oliver F., was ist denn daraus geworden ?

[Mich@ (Gast)]

Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana 
visualisiert. Anbei einige Diagramme.

Die AC-Leistung stimmt mit meiner Kalibrierten Sonoff Steckdose bis auf 
wenige Watt Unterschied überein.

Danke und großes Lob an alle.

[Jan-Jonas S. (janjonas_s)]

Mich@ schrieb:
> Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana
> visualisiert. Anbei einige Diagramme.

Netter Versuch :) Anbei mal Ausschnitte aus meinem Dashboard. Die 
zugehörige Telegraf-Config hab ich oben mal gepostet.
Das Dash braucht Influx2 (Flux)

Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus 
dem HM600 raus geholt.

Request 80 02 + time

2022-05-03 20:27:56.781439 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 2c 00 00 00 05 00 00 00 00 86 3c 79
2022-05-03 20:27:56.844744 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:27:56.887237 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:27:56.935143 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:27:56.977203 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:27:57.025358 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:27:57.073432 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:27:57.115671 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:27:57.163807 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:27:57.211908 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:05.613912 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 35 00 00 00 05 00 00 00 00 16 9b 57
2022-05-03 20:28:05.689287 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:05.737622 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:05.785561 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:05.827717 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:05.875809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:05.923963 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:05.966142 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:06.014271 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:06.056376 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:13.833624 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 3d 00 00 00 05 00 00 00 00 d6 fc f8
2022-05-03 20:28:13.890903 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:13.939259 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:13.981286 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:14.029283 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:14.071458 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:14.119636 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:14.167809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:14.209973 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:14.258033 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:40.145516 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 58 00 00 00 05 00 00 00 00 84 6b 58
2022-05-03 20:28:40.214575 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:40.262608 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:40.304763 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:40.352869 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:40.401014 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:40.443199 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:40.491307 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:40.533532 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:40.581560 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:42.355754 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5a 00 00 00 05 00 00 00 00 e4 72 23
2022-05-03 20:28:42.454595 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:42.490861 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:42.526965 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:42.592729 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:42.629048 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:42.671269 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:42.719446 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:42.791353 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:42.839432 Received 23 bytes channel 3: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:44.815962 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5c 00 00 00 05 00 00 00 00 44 59 ae
2022-05-03 20:28:44.885060 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:44.933349 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:44.975352 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:45.029316 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:45.071513 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:45.113829 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:45.161987 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:45.210197 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:45.252331 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd

Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche 
Transaktionen mit valider crc über die 140 byte. Viel Spaß beim 
dechiffrieren *duckundweg

Eine Antwort auf 80 0b "Zeit setzen" sieht zum Vergleich so aus:

2022-05-03 20:27:07.155080 Transmit | 15 72 22 01 43 78 56 34 12 80 0b 00 62 71 73 fb 00 00 00 05 00 00 00 00 a0 3f 85
2022-05-03 20:27:07.219066 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 24 00 04 00 0b 01 25 00 04 00 0c 00 00 93
2022-05-03 20:27:07.267618 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 97 5f 00 00 8e 5f 07 b2 07 b9 08 e2 13 8a 00 00 f6
2022-05-03 20:27:07.316231 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 00 00 00 00 ca 00 06 0a 1b cb
2022-05-03 20:27:07.316231 Decoded: 44 string1= 29.2VDC 0.04A 1.1W 38751Wh 1970Wh/day string2= 29.3VDC 0.04A 1.2W 36447Wh 1977Wh/day phase1= 227.4VAC 0.0A 0.0W inverter=114172220143 50.02Hz 20.2°C

Gruß,
Jan

[Sorbit (Gast)]

@ahoy,


Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat 
und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt?
Ich bleibe immer auf der Konfig Seite kleben..

[Andi (Gast)]

Hallo Freunde,
solange ihr noch aktiv am Loggen und Entschlüsseln der CMD´s seit, 
möchte ich euch nochmal an ein in den Hintergrund gerücktes aber 
wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft 
werden oder hier wichtige Leute abspringen:
Es wäre toll, wenn ihr herausfindet, wie sich die Wechselrichter in der 
Leistung limitieren lassen, pro Kanal muss nicht unbedingt sein, die 
Gesamtleistung wäre schonmal ein sehr guter Anfang. (am besten diesen 
Thread nach "limit" durchsuchen, um die bisherigen Informationen dazu zu 
finden)
Dann hätten wir endlich mal einen qualitativ hochwertigen Wechselrichter 
zum guten Preis/Leistungsverhältnis, der an einen kleinen Speicher 
angeschlossen werden kann, um z.B. die Grundlast oder zumindest ein Teil 
davon nachts mit dem Speicher zu decken.
Es gibt bereits ein älteres Projekt aus dem photovoltaikforum mit dem 
MI-300 und neuerdings auch ein Update mit dem HM-800 (und natürlich 
baugleiche Modelle in den jeweils 3 Leistungsstufen), bei dem vorsichtig 
ein Loch an der richtigen Stelle in das Gehäuse gebohrt werden muss und 
mit einer kleinen Schaltung per PWM über einem Operationsverstärker ein 
falscher Strommesswert vorgegaukelt wird, so kann man den WR also auch 
regeln. Das hat natürlich den Nachteil, dass man etwas basteln muss und 
die Garantie weg ist. Gut, als Batteriewechselrichter sind die auch 
nicht gedacht, also wie es da mit der Garantie aussieht ist fraglich, 
aber sie sind zumindest geeignet und man lässt den ja auch nicht 
permanent mit 100% laufen, sondern regelt ihn ja dann intelligent je 
nach Bedarf oder Speicherfüllung. Diese guten Mikrowechselrichter sind 
jedenfalls besser als der Chinaschrott, der ähnlich viel kostet und noch 
dazu größer, lauter und ineffizienter ist.
Es wäre daher toll, wenn quasi die gleiche Regelung per Funk einfach 
möglich ist.
Deshalb würde ich euch darum bitten, dieses Signal mal zu sniffen und zu 
implementieren.

Aber schonmal ein großes DANKE an alle, für eure bisherige tolle Arbeit, 
gemeinsam bekommen wir den Rest auch noch implementiert!

Sonnige Grüße, Andi

[Heinz R. (heijz)]

Andi schrieb:
> möchte ich euch nochmal an ein in den Hintergrund gerücktes aber
> wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft
> werden oder hier wichtige Leute abspringen:

wozu willst den WR regeln?
Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, 
bringt paar Euro

Eine Abregelung macht nur wegen der 70% Grenze- die eh keinen 
Interessiert - Sinn - oder wenn man den WR als Batterie-WR nutzen möchte

[Sorbit (Gast)]

> wozu willst den WR regeln?
> Der soll so viel wie möglich bringen- der Überschuss geht ins Netz,
> bringt paar Euro
>

Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein 
hat.

[IsnoAhoy (Gast)]

> Es wäre toll, wenn ihr herausfindet,
> wie sich die Wechselrichter in der
> Leistung limitieren lassen, pro
> Kanal muss nicht unbedingt sein, die
> Gesamtleistung wäre schonmal ein
> sehr guter Anfang. (am besten diesen
> Thread nach "limit" durchsuchen, um
> die bisherigen Informationen dazu zu
> finden)

> Es wäre daher toll, wenn quasi die
> gleiche Regelung per Funk einfach
> möglich ist. Deshalb würde ich euch
> darum bitten, dieses Signal mal zu
> sniffen und zu implementieren.

Hallo Andi,
das ist in der Tat ein interessantes und mE wichtiges Thema.

1. Zero Export Restrictions Mode
Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. 
Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU 
setzen.

> 4.1 Work Mode (page 9)
> Normal: In this mode, the microinverter operates normally and converts DC power 
into AC power to support the household loads and feeds into the public grid.
> Zero Export Control: In this mode, the microinverter’s generation is limited 
based on the current household loads, and there is no extra power fed into the 
public grid.
> Standby: There are several circumstances in which the microinverter will be in 
Standby mode:
> • The current condition contradicts with the microinverter operating 
requirements.
> • No household loads or the export control value has been set as “0” on the DTU 
in the Zero Export Control mode.

2. Grid Power Profile
Zusätzlich gibt es noch ein sog. Grid Profile in der DTU/Hoymiles Cloud. 
Ich weiß aber nicht ob man das zB von AT auf DE oder PT ändern kann…
Es wird u.a. auf den Screenshots von Enercab bzw in deren Hoymiles Cloud 
ausgegeben.

> Grid Profile Version: 2.0.0 (AT_TOR_Erzeuger_default)

3.
Als drittes ist mir in den Fehlercodes des HM-600/700/800 (6.1 
Troubleshooting List, page 14ff) aufgefallen, dass es u.a. auch einen
Code „149 Island detected“ gibt. Einige dieser Fehler sollte man ja ggf. 
Provozieren und auslesen können.

4. Communication with DTU changes Status LED Indicator

> 6.2 Status LED Indicator
> The LED flashes five times at startup. All green flashes (1s gap) indicate 
normal startup.
> Status LED
> (1) Startup Process
> • Five green flashes (0.3s gap): Startup success
> • Five red flashes (0.3s gap): Startup failure
> (2) Running Process
> • Fast green flashing (1s gap): Producing power.
> • Slow green flashing (2s gap): Producing power, but one input is abnormal.
> • Slow green flashing (4s gap): Producing power, but there is no communication 
with DTU.
> • Red flashing (1s gap): Not producing power, AC grid fault (voltage or 
frequency out of range).
> • Red flashing (0.5s gap): Non-grid abnormality fault.
> (3) Other Status
> • Alternating red and green flashing: Firmware is corrupted.
> *Note: All faults are reported to the DTU, refer to the local DTU app or S-Miles 
Cloud (Hoymiles Monitoring
Platform) for more information.

https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_HM-600700800_Global_EN_V202203.pdf

[Heinz R. (heijz)]

Sorbit schrieb:
> Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein
> hat.

IsnoAhoy schrieb:
> 1. Zero Export Restrictions Mode
> Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog.
> Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU
> setzen.

kann es sein das hier die 70%-Regelung (harte/ weiche Abregelung) 
durcheinander gebracht wird?
Für den Zero Export Control mode reicht es sicher nicht diesen zu setzen 
- an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU 
regelt die WR dynamisch

IsnoAhoy schrieb:
> 2. Grid Power Profile

Damit ist wohl die Einstellung des CosPhi gemeint

[Herbert K. (avr-herbi)]

Heinz R. schrieb:
> - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU
> regelt die WR dynamisch

Interessant wäre das schon.
Leider können da nur die weiterhelfen, die auch die DTU-Pro haben 
vermute ich.

Bei möglichen Fehlern (wie bei MODBUS erklärt), da sind wohl auch die 
DTU-Pro Besitzer gefragt ?

Ich habe beim HM-350 und HM-400 mal auf DC-Plus und DC-Minus einen 
Kurzschluß zu "Erde" gemacht. Begonnen mit 100K Ohm bis herunter zu 0 
Ohm mit verschiedenen Werten. Das hat beide nicht gejuckt. Weder Mitten 
im Betrieb, noch bevor sie mit dem PV Modul verbunden waren. Die gehen 
ganz Normal in Betrieb wie immer. Erwartet hätte ich einen 
"Isolationsfehler", ohne das sie in Betrieb gehen, wie z.B. bei den SMA 
WR. Bisher habe ich keine DTU-....

Grundsätzlich wäre auch erst mal Interessant, wer welche Fehlermeldungen 
über die DTU-... dann in der Cloud gesehen hat. So was wie falsche 
Netzfrequenz zu simulieren, wird schwierig.

[Sorbit (Gast)]

Sorbit schrieb:
> @ahoy,
>
> Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat
> und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt?
> Ich bleibe immer auf der Konfig Seite kleben..

Ahoy, wo bist DU ?;-)

[franz (Gast)]

Hallo,
ich habe mir vor ein paar Wochen 2 Balkonmodule vom Stromanbieter mit 2 
(vermutlich HM-350) Wechselrichtern gekauft, und ahoy.py dafür 
angepasst, damit ich die Ergebnisse in den io-broker bekomme. Vielen 
Dank was da alles schon an Vorarbeit geleistet wurde!

Softwareinstallation wie im repository beschrieben, hardware raspi4, 
Kabel aus https://www.amazon.de/gp/product/B078JGQKWP weil ich so die 
gleichen Farben wie in der Anleitung verwenden konnte 😊 und Radiomodul 
aus https://www.amazon.de/gp/product/B07PBBC4H9 (sind also NRF24L01+ und 
das + bezieht sich nicht auf die anderen Teile). Damit lässt sich das 
ohne Aufwand zusammenstecken.

Habe mir das Forum von Anfang an durchgelesen und noch hoffentlich noch 
für HM300,  HM450, HM600, HM700, HM-800, HM-1200, HM1500 support 
eingebaut, indem ich die ersten 4 Stelen der Seriennummer auswerte und 
entsprechend verzweige. Außerdem Support für mehrere Wechselrichter und 
etwas weniger Radio Noise nachdem das Programm nach einer Meldung 10 
Sekunden wartet um einen Inverter der geantwortet hat nochmals zu 
fragen. Programm liegt in franzongit branch.
Ich hoffe das erleichtert den Einstieg für technisch nicht so versierte.

lg Franz

[Jan-Jonas S. (janjonas_s)]

franz schrieb:
> für HM300,  HM450, HM600, HM700, HM-800, HM-1200, HM1500 support
> eingebaut...

Die alte ahoy.py, sowie das C-Projekt brauchen einen full-rewrite.
Am Python bin ich gerade dran und bau da ein flexibles Modul draus, was 
im Idealfall so einfach instanzierbar ist wie der mqtt-client, und 
Framing, Fragmentierung beim senden einer arbiträr langen Payload, sowie 
Transport-Layer und Dekodierung übernimmt.

Im Wesentlichen senden die Wechselrichter halt größere Payloads über 
mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die 
längste Payload, die ich von einem HM600 empfangen habe ist 140 byte 
lang. Da die crc stimmt, confirmed.
Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt 
in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich 
einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten.

Ich gehe bisher davon aus, dass der Fragment-Zähler (ehem. cmd) von 
0x01-0x80 zählen kann und 0x80-0xNN (0xNN = Fragment-Zähler größer 0x80) 
die Anzahl der Fragmente des Pakets angibt. Schon passt da eine ganze 
Firmware rein.

Die einzelnen Fragmente isoliert zu verarbeiten ist ein Dead-End.

Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit 
Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet.

Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in 
zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten 
und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was 
angefragt wurde, um die Payload dekodieren zu können.

Wir sollten zukünftig also von:
Fragmenten, Paketen, und Payloads sprechen.
Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das 
Paket enthält die Payload.

Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment 
+ 1 byte crc
Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc
Jede Payload kann demnach max 2046 byte haben.
Vermutung, abgeleitet aus den bisher bekannten Umständen.

Man müsste jetzt mal schauen, ob man aus dem 1. byte Payload vielleicht 
Rückschlüsse auf den Inhalt der Payload gewinnen kann.

Gruß,
Jan

[IsnoAhoy (Gast)]

Hallo Sorbit,
ich habe keine Ahnung wen Du mit Ahoy meinst. Ich glaube Martin G. / 
Petersilie hat das Logo gemalt und das Projekt so genannt ? Ich nenne 
mich isnoAhoy also eben nicht Ahoy :)

> Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur 
eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf 
der Konfig Seite kleben..

Das Problem habe ich auch. Das Programm macht beim Neustart mehrere 
Versuche das konfigurierte WLAN zu kontaktieren. Wenn es nicht klappt 
oder die Verbindung später abreißt dann kommt man ausser über den Serial 
Port oder ggf den AccessPoint nicht mehr an die Oberfläche.
Lukas P. versucht das Problem einzugrenzen bzw zu beheben.
Siehe auch:

https://github.com/grindylow/ahoy/issues/15

Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je 
nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN 
Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet.

Evtl. kann man in Zukunft die beiden Oberflächen vereinheitlichen und 
den Reconnect mit dem WLAN alle X Minuten einstellen oder per Serial 
Command forcieren?

[Andi (Gast)]

@Heinz
Ja, natürlich macht im ersten Moment eine Limitierung keinen Sinn, man 
verschenkt ja dadurch gratis Energie, wenn man Module dran hängen hat. 
Aber ich habe ja auch geschrieben, um ihn als günstigen und guten 
Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) 
Der beliebte Chinawechselrichter GTIL SUN-1000 bewegt sich auch in der 
Preisspanne des HM-800, allerdings ist der Wirkungsgrad davon schlecht 
und die Leistungssteuerung muss man sich auch mehr oder weniger selbst 
zusammen basteln mit z.B. elektronischen Poti. Noch dazu hat das Ding 
einen Lüfter der recht laut wird bei 1000W, hängt aber wohl damit 
zusammen, das die recht hohe Verlustleistung ja irgendwie gekühlt werden 
muss. Ein Victron Wechselrichter übersteigt die Kosten enorm und ist 
auch viel zu viel Leistung um die Grundlast über die ca. 10 Stunden 
Nacht zu decken. Lastspitzen lohnen sich nie die ausgleichen zu können, 
mit denen muss man leben, das darf ruhig der Stromanbiete rübernehmen, 
ist einfach am billigsten und macht Insgesamt nur einen kleinen Anteil 
der Autarkie aus.
Das ich den HM-800 nicht permanent mit 800W betreiben sollte ist mir 
klar, aber darum möchte ich ihn ja auch begrenzen und um halt dynamisch 
die Grundlast nachts zu decken, die keine 800W beträgt.
Böse Zungen würden jetzt sagen, das Netz ist der beste Speicher, das ist 
aber illegal und nur mit einem rückwärtsdrehendem Ferraiszähler möglich.
Ich und viele andere haben bereits einen digitalen Zweirichtungszähler 
verbaut und der wird nach und nach bei allen kommen...
Und ja, eine EIGENBAU PV-Anlage mit Batteriespeicher lohnt sich, aber es 
dauert natürlich ca. doppelt so lange bis die Investition wieder rein 
ist gegenüber nur Module + nötiges Zubehör. Einen Fertigspeicher oder am 
besten noch PV-Anlage montieren lassen würde ich auch nicht, da dauert 
es mal ebend locker 15+ Jahre bis das wieder rein ist, da die Kosten 
deutlich höher sind. Mit meinem Eigenbauprojekt komme ich auf knapp 6 
Jahre(bei steigenden Strompreise, wovon auszugehen ist, noch eher und 
bevor die Kritiker kommen: gute LiFePo4-Akkus halten noch ein paar Jahre 
länger, wenn man die richtig betreibt). Ja ist eine ganze Weile, aber 
was will man machen, mehr Wp und Einspeisen rechnet sich noch weniger, 
davon holt man die Nacht auch nicht rein und auf die Bürokratie habe ich 
auch keine Lust...
Außerdem selbst wenn man nach 6 Jahren rechnerisch bei +-0 ist, hat man 
immernoch die Hardware(Panel, Wechselrichter, Laderegler, Akku mit 
Restkapazität ...), die einen Restwert hat, beim Stromanbieter sieht man 
von seinem Geld nichts mehr wieder, das hat mich überzeugt, dieses 
Projekt zu starten. Warnung: PV macht süchtig! :D ...alles beginnt mit 
einem einfachen Balkonkraftwerk und nach dem ersten Jahr will man mehr.

Aber zurück zum Thema:
In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure 
Daten rankommt, aber leider auch nicht identisch ist), sind Register zu 
sehen, die dafür zuständig sind: 
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über 
ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit 
dem Protokoll zum WR aussieht, aber es muss ja alles über NRF 
funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70% 
Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in 
jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer 
wieder zyklisch das aktuelle Limit geschrieben.
Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur 
da das möglich bzw. freigegeben ist.

Grüße

[Manuel M. (petrosiliuszwackelm)]

Ich konnte der (esp8266) Anleitung sehr gut folgen und kann seit heute 
meinen HM-800 auslesen. Super wie schnell dies hier entwickelt wurde!

Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry 
über MQTT.

Mir sind zwei Dinge aufgefallen:
1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche 
Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel 
vom Wert des 2. Channels sofort überschrieben.

2) In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay 
angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der 
Channels.
Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler 
wenn dieser Wert direkt angezeigt wird.

Gruß Manuel

[Lukas P. (lumapu)]

IsnoAhoy schrieb:
> Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je
> nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN
> Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet.

Im Prinzip ist alles gleich, nur dass im AP Modus standardmäßig auf die 
Setup Seite verwiesen wird.
Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem 
WLAN zu verbinden.
Achtung, einige Einstellungen gehen beim Upgrade verloren, das wurde 
noch nicht bearbeitet. Changelog = Git-Log 
(https://github.com/grindylow/ahoy/commits/main)

Wie gewünscht sind jetzt alle Einstellungen, die zur Kompilierzeit 
gemacht werden können in einer config.h

Manuel M. schrieb:
> In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay
> angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der
> Channels.

Sehr schön, dass es auf Anhieb geklappt hat. Ich verwende ioBroker als 
MQTT Server, dieser erstellt dann "Unterordner" da jedes Topic mit 
Slashes getrennt geschickt wird, z.B.:
/inverter/hm1200/ch1/u_dc
/inverter/hm1200/ch2/u_dc
...
Bei mir wird hierdurch nichts überschrieben, da alles eindeutig und 
unique ist.

> Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler
> wenn dieser Wert direkt angezeigt wird.

Die Summe lässt sich recht einfach bilden, indem du in der hmDefines.h 
für den HM800 folgende beiden Zeilen hinzufügst (kopiert vom HM1200):

{ FLD_YD,  UNIT_WH,  CH0, CMDFF, CALC_YD_CH0,   0, 0 },
{ FLD_YT,  UNIT_KWH, CH0, CMDFF, CALC_YT_CH0,   0, 0 },

Andi schrieb:
> Aber ich habe ja auch geschrieben, um ihn als günstigen und guten
> Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt)

Tolles Thema, gibt es hierzu auch ein Forum? Bin auch interessiert an 
einer Selbstbau-Speicherlösung. Wäre super wenn man hier eine ähnliche 
Community hätte wie diese hier, wobei bei Geschwindigkeit kann uns hier 
keiner was vormachen! ;-)

[Robert S. (Gast)]

Lukas P. schrieb:
> Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem
> WLAN zu verbinden.

Super, wie schnell die Entwicklung voranschreitet!
Habe die neue Version gleich installiert :-P
Ist leider in mehreren Versuchen nur jeweils wenige Minuten erreichbar,
WIFI wurde nur einmal aut. restarted.
Nach welchem Zeitraum sollte das WIFI neustarten, muss ich länger 
warten?
Ausserdem ist mir aufgefallen, dass nach dem aut. restart die MQTT
Verbindung nicht mehr connected war. Wird die auch restarted?

SG
Robert

[Martin G. (petersilie)]

Herbert K. schrieb:
> martin schrieb:
>> Herbert K. schrieb:
> ...
>> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
>> handelt, der einen eigenen Controller drin hat.
> ...
> Entschuldigung !  Daran hatte ich nicht mehr gedacht.

Hatte schonmal jemand den Mut, seinen WR aufzuschrauben? Mit etwas Glück 
ist ja darin direkt ein NRF24L01+ verbaut anstelle des NRF24LE1E?

[Manuel M. (petrosiliuszwackelm)]

Lukas P. schrieb:
> { FLD_YD,  UNIT_WH,  CH0, CMDFF, CALC_YD_CH0,   0, 0 },
> { FLD_YT,  UNIT_KWH, CH0, CMDFF, CALC_YT_CH0,   0, 0 },

Danke - das klappt so - kann man das in der hmDefines.h
für den HM800 so einchecken?

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
>
> Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus
> dem HM600 raus geholt.
>
> Request 80 02 + time
> [code]
....
04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c
....
> Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche
> Transaktionen mit valider crc über die 140 byte. Viel Spaß beim
> dechiffrieren *duckundweg
> Gruß,
> Jan

Hallo Jan, kann ich so bestätigen für HM-350/HM-400.
Telegramm "04" sieht bei einem von meinen identisch aus.
Telegramm "89" sieht bei einem von meinen anders aus bei einigen Bytes, 
einige sind identisch.
Mehr habe ich noch nicht verglichen. Was auch immer das bedeutet. Ich 
lass das mal ne Zeit mitlaufen, ob sich da Werte ändern.

[Damian B. (damian_b)]

Hallo,
Ich entschuldige mich für meinen deutschen Übersetzer

Ich möchte einen externen MQTT-Server verwenden, jetzt kann ich die 
IP-Adresse angeben (1.2.3.4), kann ich Unterstützung für Hostnamen 
hinzufügen?

[franz (Gast)]

Jan-Jonas S. schrieb:
> Im Wesentlichen senden die Wechselrichter halt größere Payloads über
> mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die
> längste Payload, die ich von einem HM600 empfangen habe ist 140 byte
> lang. Da die crc stimmt, confirmed.
> Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt
> in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich
> einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten.

ja, das ist sicher so, nur bei meinen kleinen 3xx geht/ginge sich alles 
in je einem Paket aus. Allerdings ist die python version schon so 
schlau, alle Antworten einer Sendung einzusammeln und dann 
hintereinander zu verarbeiten, somit konnte ich einbauen, mit globalen 
Variablen Daten zwischen 2 Fragmenten auszutauschen, ob es funktioniert, 
kann ich mangels entsprechender WR nicht testen. Ich nehme an, beim 
HM-600 ist das highword von total power 1 in 0x02 das letzte Word in 
0x01, das das schon aufgetreten?

Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das 
letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich alles 
im 2. ausgehen, ist aber geteilt.

Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder 
konstant oder springen. Ich erwische aber jedenfalls auch nicht alle 
Pakete, auch wenn ich 10 Sekunden Pause mache. Zumindest in 87% der 
Fälle wo ich die Antwort erwische, habe ich beide, so ich mit 40 sende. 
Bei 23 als Sendechannel ist es bei mir um 25% besser, allerdings 
erwische ich da ingesamt auch nur auf 40% der Sendungen eine Antwort, 
wobei auch wieder fast alle auf je 2 channels kommen (40 ->3,75, 23-> 
61,75). Den in einem C source aufgeführten Channel 83 habe ich noch nie 
gesehen, in der DTU-W100 Doku für MI-... steht aber auch nur von 5 und 
nicht 6 Channels.

Habe die von lbp beschriebene Logik zum Holen der Pakete 
nachimplementiert, war aber bei mir auch nicht besser. Ich denke auch, 
dass auf dem Channel für weitere Pakete bleiben wie zZ implementiert gar 
nicht zielführend ist, da nicht nach x-Paketen die Suche beendet wird, 
greift der Algorithmus aber sowieso zwischen Versendungen nicht. Auch 
aus Sicht des WR wäre es unklug alles auf je einen Channel zu setzen.

Seine Beschreibung zum Nachfordern habe ich noch nicht versucht, diese 
Sonnenabhängigkeit ist eine echte Programmierbehinderung :-)

lg,
Franz

[Petra R. (petra-kathi)]

Hallo zusammen,

ich habe in den letzten Tagen Martin G.'s Raspi-Programm ahoy.py für den 
HM-1500 adaptiert und die (ich meine, auch von ihm) als Farbgrafik 
gepostete Feldbedeutung der CMDs durchgesehen und in Teilen ein wenig 
nachkorrigiert. Jetzt sind die Ausgaben jedenfalls stimmig und für mich 
mit meiner PV-Paneel-Anordnung nachvollziehbar. (Ich habe 4 180 W 
bp-Solar Paneele auf dem Balkon liegen.)

Um einen besseren Überblick über noch nicht zuweisbare Feldeinträge aus 
den Commands (1, 2, 3, 132 - was Anderes scheint's beim HM-1500 nicht zu 
geben) zu bekommen, habe ich das Logging zwecks visueller Inspektion ein 
wenig umgestellt und die Variablen anders benannt. Alle Änderungen 
beziehen sich auf die Subroutine on_receive(), die ich in der neuen Form 
als Anhang dranhänge.

Die sich durchaus stark ändernden Blöcke des 132er Commands scheinen 
wesentlich mit der Verfügbarkeit des AC-Anschlusses zu tun zu haben. Um 
das zu untersuchen, habe ich den HM-1500 mal stromlos geschaltet und 
dann wieder eingestöpselt (entspricht ja einem Stromausfall). Die 
kondensierte Logdatei hängt dazu ebenfalls an.

Meine Schlüsse daraus:

- Die Variable uk_132_1 korreliert mit einer bemerkten AC-Frequenz
- Die Variable uk_132_2 korreliert mit der Stromabgabe

Weiter bin ich allerdings leider noch nicht vorgedrungen.

Aber vielleicht finden ja einige Gurus hier noch was dazu raus ...  ;-)

Viele Grüße,
Petra

[Petra R. (petra-kathi)]

Nachtrag:

- Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des 
Wechselrichters.

[Mc_K (Gast)]

Einen Wunderschönen guten Tag,

da ich so gut es geht vermeiden will, mit China-Servern verbunden zu 
sein, bin ich auf das Forum gestoßen und bin Erstaunt darüber, was 
bereits zustande gekommen ist. Applaus dafür!
War beim lesen der Postings schon nervös, ob dieses Projekt überhaupt 
was wird. (Beim Thema sniffen der internen Kommunikation der DTU-W100).

In den nächsten Tagen bekomme ich einen HM-1500 und 4x 450Wp Panele, die 
ich unbedingt begrenzen möchte. Im Idealfall mit Zero-Export-Funktion. 
(Mir ist bewusst dass hierzu zusätzliche Messinstrumente usw. 
installiert werden müssten)
Die Drosselung des Inverters auf fixe Maximalwerte, wird wohl etwas 
einfacher zu realisieren sein.
Beispiel:
Geringer Eigenverbrauch = Inverter auf 50%
Höherer Verbrauch = Inverter auf 90%

Es gibt auch Möglichkeiten in Form von Zuschaltung zusätzlicher 
Verbraucher.

Habe einige ESP32, ESP8266 und Gosund(Tasmota) Steckdosen zuhause. 
NRF24L01+ sind auch bestellt.

Nach inbetriebnahme kann icht gerne auch Daten beisteuern.
Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu 
unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion 
zu "entschlüsseln".

Fragen:
Habe zu diesem Thema nichts gelesen (möglicherweise überlesen):

Wenn die Inverter/DTUs ausgeliefert werden, sind sie ja auf einer 
bestimmten FW, die vermutlich übers Internet upgedatet werden kann.
Kann es sein, dass das Verhalten der Kommunikation je nach FW anders 
ist?
Dann müssten wir am besten alle auf der selben FW sein um 
weiterzukommen..

Besteht bzw. wie hoch ist die Gefahr, dass Hoymiles die Inverter und 
DTUs updatet und verschlüsselt, wenn man sich zu ihren Servern 
verbinden?

Sollte ich mir vorbeugend jetzt schon einen weiteren HM1500 für eine 
Zukünftige Erweiterung besorgen?
Gehe davon aus, dass Hoymiles die Geräte durch weitere 
Hardware/Softwareeingriffe noch "sicherer" machen werden und die 
Inverter in Zukunft keine Seemanssprache verstehen.

(Siehe Playstation 4 Jailbreaks)

Freue mich darauf, eure Meinungen zu hören.

[Damian B. (damian_b)]

Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie
Hat die HMT-Serie ein geändertes Protokoll?


Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern: 
HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500  1200-4T HMS-1000  
900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.

[Sorbit (Gast)]

Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist.
Hoymiles 1200.

[IsnoAhoy (Gast)]

Hallo Franz,

> Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das
> letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich
> alles im 2. ausgehen, ist aber geteilt.
>
> Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder
> konstant oder springen.

Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD 
genannt wird/wurde.
Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y 
gesetzt, also das höchstwertige Bit 8 wird gesetzt.
Bei zwei Paketen also 0x01, 0x82
Bei drei Paketen 0x01, 0x02, 0x83
Und bei vier 0x01, 0x02, 0x03, 0x84
etc pp

Die CRC8 der Pakete sind jeweils die letzten Bytes vor 0x7F
Und die CRC_M/CRC16 sind die letzten beiden Bytes vor dem CRC8 des 0x8y 
Pakets.

Wie Jan Jonas schon schrieb wäre es sinnvoll statt von CMD von einem 
Paket Counter zu sprechen, dessen höchstwertiges Bit 8 gleichzeitig als 
Nachrichtende Flag dient

[Jan-Jonas S. (janjonas_s)]

Python voraus!

ich habe heute mal einen weiteren riesigen Dev-Snapshot gepushed.

ahoy.py implementiert jetzt
 - Multi-Inverter
 - Transport-Layer und Retransmits von verlorenen Frames
 - Full Payload Decode mit Device- und Request- abhändigen Decodern
 - Dynamisches mqtt-publishen, jenachdem wieviel Phasen/Strings

TBD:
 - mehr als nur den HM-600 supporten
 - code cleanup
 - irgendwie noch eine Strategie für Struktur der Decoder einfallen 
lassen

Ist halt noch ein PoC und enthält mit Sicherheit Fehler.

Hier: https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi

Das mit den Retransmits sieht dann so aus:

2022-05-05 18:46:56.432521 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 73 ff 7e 00 00 00 05 00 00 00 00 59 ad e5
2022-05-05 18:46:56.525429 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 e4
2022-05-05 18:46:56.579134 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 0f 03 e8 00 f5 00 2a 6b f2 b4
Error while retrieving data: Frame 1 missing: Request Retransmit
2022-05-05 18:46:57.083093 Transmit 11 | 15 72 22 01 43 78 56 34 12 81 8e
2022-05-05 18:46:57.137897 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 86
2022-05-05 18:46:57.641794 Payload: 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 00 00 00 0f 03 e8 00 f5 00 2a 6b f2
2022-05-05 18:46:57.641794 Decoded: 24.5 phase0=voltage:227.5, current:1.5, power:33.7, frequency:49.98 string0=voltage:31.5, current:0.55, power:17.5, total:41.482, daily:1595 string1=voltage:31.5, current:0.57, power:17.8, total:39.191, daily:1600

Gruß,
Jan

[Peter L. (leliep)]

Sorbit schrieb:
> Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist.
> Hoymiles 1200.

Das kann ich bestätigen. HM-1200 mit AHOY 0.3.6

[Hans W. (hans_w801)]

Servus,

habe das ganze jetzt auch laufen. MQTT Broker läuft in Home Assistant.
Emfange damit auch alle anderen Geräte, die über das MQTT Protokoll 
senden.

Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected 
ist.

CMDs:
0x1: 97
0x2: 193
0x3: 145
0x81: 0
0x82: 0
0x83: 0
0x84: 65
other: 0

Send Cnt: 245

MQTT: connected

Kann ich das irgendwie anders prüfen ?

[Robert S. (Gast)]

Hans W. schrieb:
> Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected
> ist.

Hast schon mit einem MQTT Sniffer die Topics geprüft?
Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem //

SGR

[Hans W. (hans_w801)]

Robert S. schrieb:
> Hast schon mit einem MQTT Sniffer die Topics geprüft?
> Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem //

hab das ganze mal mit iobroker versucht und da wird ein ganzer 
Ordnerstamm erstellt. Scheint also an Home Assistant zu liegen...

Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( 
/inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA.
Aber das kommt dann im Sekundentakt rein.

Muss ich wohl noch ein wenig suchen, woran es das liegt im HA.

ESP-DTU funktioniert also !!! Top !!!

[Robert S. (Gast)]

Hans W. schrieb:
> Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde (
> /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA.
> Aber das kommt dann im Sekundentakt rein.
>
> Muss ich wohl noch ein wenig suchen, woran es das liegt im HA.

Ich habe bei mir folgendes in der configuration.yaml:

 - platform: mqtt
   state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal"
   name: "Gesamtproduktion PV-Gartenhaus"
   device_class: energy
   unit_of_measurement: "kWh"

Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein

   value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | 
float) | round(2)) }}"

will einfach nicht funktionieren.

[Lukas P. (lumapu)]

Sorbit schrieb:
> Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist.
> Hoymiles 1200.

Kann mir vorstellen, dass das an den MPPT Reglern liegt. Der HM1200 hat 
nur zwei, also sind je zwei Anschlüsse parallel geschaltet. Hier 
entsteht wahrscheinlich ein geringer Fehler beim messen.
Die Spannung wird übertragen, da es für den WR nur 2 DC Spannungen gibt.


Petra R. schrieb:
> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des
> Wechselrichters.

Das ist kein Last-%-Grad, sondern der Power-Factor. 
https://de.wikipedia.org/wiki/Leistungsfaktor


Jan-Jonas S. schrieb:
> Transport-Layer und Retransmits von verlorenen Frames

Lohnt es sich das Re-Transmit der Pakete zu implementieren? Aktuell ist 
meine Statistik fast jeden Tag gleich von der Verteilung her. Ich frage, 
da es ja noch nicht so genau bekannt ist, welche Sendekanäle der WR 
wirklich benutzt. Hat jemand schon mal eine DTU beim Re-Transmit 
erwischt?

CMDs:
0x1: 3617
0x2: 11571
0x3: 9310
0x81: 0
0x82: 0
0x83: 0
0x84: 4332
other: 0

Send Cnt: 20883

[franz (Gast)]

Hallo IsnoAhoy

IsnoAhoy schrieb:
> Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD
> genannt wird/wurde.
> Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y
> gesetzt, also das höchstwertige Bit 8 wird gesetzt.
> Bei zwei Paketen also 0x01, 0x82

ja, dass die "cmd" paketzaehler sind ist mir klar, dass das leftmost bit 
die endmarkierung ist, leuchtet mir jetzt auch ein. Ich hatte 
fälschlicherweise geglaubt, dass es bei anderen Modellen sowas wie 
anfragenübergreifende Nachrichtenzähler gibt den meine einfachen 3xx 
inverter mit 112174.. nicht haben - obwohl ich sie beim Zusammensuchen 
der dortigen Felder nicht gesehen hatte. Als ich mit anderen 
Sendekombinationen experimentiert hatte, war ich bis (durchgängig) 7 
gekommen, allerdings habe ich das 0x88er dann wohl immer verpasst.

Fast schade, dass ich Dienstag soviel Zeit hatte andere Modelle 
dazuzusuchen und die Struktur anzupassen (z.B. 3 mal umüberlegt ob mit 0 
oder 1 bei DC zu starten, in der micro version ist es ja 1), immerhin 
habe ich nur heute abend ein wenig erfolglos refetching probiert.

Ich habe mir aber als ich es merkte gleich Jans neue Version geholt.
Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein 
Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-(

lg,
Franz

[Sorbit (Gast)]

Kann ich mit Daten aus meinem HM1200 helfen?
Wenn ja, welche werden benötigt?

[Hans W. (hans_w801)]

Robert S. schrieb:
> Ich habe bei mir folgendes in der configuration.yaml:
>
>  - platform: mqtt
>    state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal"
>    name: "Gesamtproduktion PV-Gartenhaus"
>    device_class: energy
>    unit_of_measurement: "kWh"
>
> Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein
>
>    value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' |
> float) | round(2)) }}"
>
> will einfach nicht funktionieren.

ich hab es jetzt mal so eingetragen. Morgen sehen wir weiter.

- platform: mqtt
    state_topic: "/inverter/hm1500/ch0/YieldTotal"
    name: "Gesamtproduktion PV-Gartenhaus"
    device_class: energy
    unit_of_measurement: "kWh"
    value_template: >
        {{value|round(2)}}
    state_class: total_increasing
    unique_id: "pv_gartenhaus_total"
    last_reset_topic: "/inverter/hm1500/ch0/YieldTotal"
    last_reset_value_template: "1970-01-01T00:00:00+00:00"

[Petra R. (petra-kathi)]

Lukas P. schrieb:
>> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des
>> Wechselrichters.
>
> Das ist kein Last-%-Grad, sondern der Power-Factor.
> https://de.wikipedia.org/wiki/Leistungsfaktor

Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" 
getaufte Variable (Werte typisch bei 980 => 0,98) meintest?

Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" 
(oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und 
"uk_132_4" (wild im einige Zehntausenderbereich schwankend).

Any ideas?

Tschüssi,
Petra

[Thomas B. (tbnobody)]

Petra R. schrieb:
> Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2"
> getaufte Variable (Werte typisch bei 980 => 0,98) meintest?
>
> Blieben vor allem noch die Interpretationen der Werte von "uk_132_1"
> (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und
> "uk_132_4" (wild im einige Zehntausenderbereich schwankend).
>
> Any ideas?

Hallo Petra,

ich kann bestätigen, uk_132_2 verläuft nahezu genauso wie der 
Leistungsfaktor den meine Gosund Zwischensteckdose ausgibt. Dies ist 
auch so bei [1] und [2] implementiert.

Was Jan herausgefunden hat steht im letzten empfangenen Paket (also das 
mit 0x8*) in den letzten beiden Bytes (bei dir uk_132_4) der CRC über 
die gesamte Payload. Dies ist auch in seiner Implementierung so 
umgesetzt.

Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl 
0x00 0x07

Dein uk_132_1 konnte ich hier ebenfalls noch nicht zuordnen.


[1] 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h
[2] 
https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py


Güße
Thomas

[Jan-Jonas S. (janjonas_s)]

franz schrieb:
> Ich habe mir aber als ich es merkte gleich Jans neue Version geholt.
> Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein
> Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-(

Sehr schön :)

Übrigens kann man mit dem python-Modul auch "offline" debuggen
[code]
root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hoymiles
>>> response = bytes.fromhex("00 01 01 3b 00 03 00 0b 01 3c 00 04 00 0d 00 00 a2 
16 00 00 99 24 06 47 06 4d 08 dc 13 8a 00 00 00 00 00 00 00 00 00 d8 00 5a b1 89")
>>> hoymiles.decoders.HM600_Decode0B(response).__dict__()
{'phases': [{'voltage': 226.8, 'current': 0.0, 'power': 0.0}], 
'strings': [{'voltage': 31.5, 'current': 0.03, 'power': 1.1, 
'energy_total': 41494, 'energy_daily': 1607}, {'voltage': 31.6, 
'current': 0.04, 'power': 1.3, 'energy_total': 39204, 'energy_daily': 
1613}], 'temperature': 21.6, 'frequency': 50.02}
>>>
[code]

Die response ist dabei eine komplette Payload, wie sie in meinem obigen 
Logauszug zum retransmit-Beispiel zu finden ist.

Die Decoder sind Klassen in hoymiles/decoders/__init__.py

class {model}_Decoder{req_cmd}(AntwortTypElternklasse)
also
HM600_Decoder0B(StatusResponse)
Bisher gibts 2 Hautklassen UnknownResponse und StatusResponse
StatusResponse ist hauptsächlich für die 0b-Werte zu verwenden und 
stellt den __dict__() accessor bereit.

Dann muss man noch in der ResponseDecoderFactory-Klasse in 
hoymiles/__init__.py die ser_db um die Seriennummern-Maske erweitern, 
wenn die Liste das gewünschte Modell bisher nicht abdeckt.

Wie gesagt, die Struktur ändert sich wohl noch. Das hab ich jetzt alles 
schnell um den eigentlichen Transport-Layer drumrum gehackt.

Teaser:
Es gibt dann schon eine Vorbereitung für einen command_queue, um später 
auch WR per mqtt steuern zu können.

Bei mir geht übrigens ein Interval von 4 Sekunden. Bei mehreren WR würde 
ich sagen interval + 5s für jeden WR.

Nachtabregelung muss noch implementiert werden. Ich würde das aber 
lieber an Anzahl TX ohne Antwort binden statt an Uhrzeiten. Also wenn 
nach 30 Anfragen keine Antwort, interval auf 5 Minuten oder so.

Jede Payload wird im Übrigen bis zu 4x je interval wiederholt, wenn 
keine Antwort kommt. Das ist Absicht, brauchen wir spätestens wenn wir 
steuern wollen und außerdem will ich meine Antworten garantiert 
innerhalb des interval bekommen.

[Petra R. (petra-kathi)]

Hi Thomas,

> Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl
> 0x00 0x07

Da kommen bei mir aktuell häufig Werte 11 und 12.

Vielleicht kann ja mal ein DTU-behafteter Kollege nachschauen, welche 
Werte man über die bereits zuweisbaren hinaus als Information abfragen 
kann?

Tschüssi,
Petra

[Ha F. (harry_f)]

Hallo bin neu hier. Habe heute meine Hardware bekommen:
NodeMCU + NRF24L01.
Compilieren, Upload und Config hat funktioniert.
Daten vom HM600 bekomme ich noch keine, evtl. bin ich zu weit weg.
NRF24L01 wird erkannt, MQTT ist connected (IoBroker).

Folgendes ist mir aber bis jetzt aufgefallen:

Nach einem Reboot klappt scheinbar die NTP-Abfrage nicht immer. In der 
seriellen Console steht oft [NTP]: 1970-00-00+00:00:00, selten das 
korrekte Datum/Uhrzeit.

Im WebIf steht immer 1970-00-00+00:00:00.
Habe den Timerserver auch schon auf fritz.box geändert, bringt nichts.
Evtl ist die Abfrage ja zu schnell nach dem Wifi-Connect.

Update:  Die ersten Daten sind angekommen.
Wenn ich mit irgendwelchen Rohdaten helfen kann, bitte melden.

[IsnoAhoy (Gast)]

Hallo Harry F.
Daten bekommst Du erst wenn Du die Seriennummer im Setup eingetragen 
hast. Das sollte selbst ohne WLAN Verbindung zum NTP server 
funktionieren.
Ich weiss aber nicht ob der WR auf Epoch 1970-01-01 reagiert, die 
Anfrage für die Statusdaten ist ja im Prinzip das Zeit setzen Kommando.
Was sagt er denn bzgl RF24 und Anschlüssen. Irgendjemand hat auch hier 
oder im github unter Issues gemeldet dass die IRQ Leitung nicht an allen 
/ beliebigen ESP8266 Anschlüssen funktioniert. Der Anschluss muss 
Interrupt fähig sein.
Mit besten Grüßen
Stefan

[H. E. (h_e)]

Hallo zusammen,

erst mal tausend Dank für die super Arbeit die ihr bisher gemacht habt. 
Der ganze Thread liest sich echt wie ein Krimi. Ich habe einen HM600 mit 
zwei Modulen und heute mal den Lötkolben angeschmissen und das ganze auf 
einem Wemos D1 Mini zum laufen gebracht.

Wenn ich die Statistik-Werte mit den anderen hier geposteten vergleiche, 
kommt es mir so vor, als würden bei mir deutlich weniger Pakete 
ankommen. Mein ESP6288 ist nur ca. 2m vom WR entfernt. Ist bei meinem 
Setup irgendwas schief gelaufen oder ist das im Rahmen?

Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast 
doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen 
erzeugt worden.

[IsnoAhoy (Gast)]

Hallo Lukas,

habe gerade mal nachgesehen mein ESP8266 (v0.3.6) hatte vor 2:15h wohl 
einen Reset. Das Datum steht immer noch auf 1970 aber er zeigt Werte 
(Temperatur, Yield Total, Spannung, Strom, etc.) an und ist auch per 
WLAN Router erreichbar. D.h. nach erfolgreicher Verbindung mit dem WLAN 
Router erfolgt kein erneuter NTP Abgleich.

[Herbert K. (avr-herbi)]

H. E. schrieb:
...
> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast
> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen
> erzeugt worden.
Wieso ist Dein HM600 auf 72% abgeregelt ?  Absicht ?  Nicht bemerkt ?

292,70 + 290,80 = 583,50 P_DC
583,50 P_DC /// 420,00 P_AC --->  72% ?

Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%

[Chris (Gast)]

Hallo und danke an alle die hier so tolle Arbeit leisten! Auch ich habe 
heute meine Anlage bekommen (HM-1500) und habe die ersten Daten 
empfangen. Allerdings war das erste NRF24 Modul defekt. Erst nach dem 
Austausch lief alles. Aber dann wirklich wunderbar. Die Daten sind 
plausibel und die Pakete kommen in hoher Anzahl. Auch mit einer 
Entfernung von aktuell ca. 6-7m.

Hab den MQTT Client in FHEM eingebunden. Daten kommen sauber rüber. 
Allerdings wird der Client nach jedem Neustart als neues Device erkannt. 
Könnte da noch etwas angepasst werden? Ich hab die AHOY:0.3.2 auf einem 
NodeMCU. Könnte der
Device Host Name genutzt werden?

[H. E. (h_e)]

Herbert K. schrieb:
> H. E. schrieb:
> ...
>> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast
>> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen
>> erzeugt worden.
> Wieso ist Dein HM600 auf 72% abgeregelt ?  Absicht ?  Nicht bemerkt ?
>
> 292,70 + 290,80 = 583,50 P_DC
> 583,50 P_DC /// 420,00 P_AC --->  72% ?
>
> Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%

Ne, abgeriegelt habe ich nichts. Ich habe auch keine DTU mit der ich das 
tun könnte. Ich glaube das liegt daran, dass die Daten der beiden 
Channel nicht synchron mit den oberen Daten sind. Die Daten dort sind 
auch lange auf 0 stehen geblieben (außer YieldDay), bis dann nach ca. 
einer Stunde das erste 0x1 Signal kam. Läuft also noch nicht so rund bei 
mir.

[Jan-Jonas S. (janjonas_s)]

Hallo,

habe gerade meine Python-Implementierung [1] nochmal gepusht.

Hinzugekommen sind:
  * Support für den HM-1500
  * Mqtt {topic}/command payload-relay
  * Default decoder zur einfacheren Protokollanalyse

$ mosquitto_pub -t hoymiles/11417/command -m 800b00tttttttt0000000500000000

Injiziert z.B. ein Zeit-Setzen-Kommando. tttttttt ist eine Variable für 
die Zeit. So kann man sehr einfach und zur Laufzeit neue Payloads 
ausprobieren.

Gruß,
Jan

[1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi

[Jan-Jonas S. (janjonas_s)]

H. E. schrieb:
> Herbert K. schrieb:
>> Wieso ist Dein HM600 auf 72% abgeregelt ?  Absicht ?  Nicht bemerkt ?
>
> Channel nicht synchron mit den oberen Daten sind.

Genau, weil es keine "channel" gibt. Das passiert, wenn man 
Datenfragmente die zu unterschiedlichen Zeitpunkten "aus dem Kontext 
gerissen" wurden korelliert.

Bei einer Abregelung sinken zwingend DC und AC-Werte um die gleiche 
Summe.
Blieben die DC-Werte hoch würde der WR massiv Energie vernichten müssen. 
Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung 
einfach der falschen Datenerhebung geschuldet und wenn mans richtig 
machen würde, wie es aktuell das Python-Ding tut, ist das der 
Wirkungsgrad des WR. Unabhängig von der Abregelung.

[Lukas P. (lumapu)]

Hallo Jan-Jonas

ich finde es toll mit welchem Elan du an die Sache dann gehst. Echt 
schön zu sehen, dass auch andere viel Zeit investieren.

> Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung
> einfach der falschen Datenerhebung geschuldet und wenn mans richtig
> machen würde, wie es aktuell das Python-Ding tut, ist das der
> Wirkungsgrad des WR. Unabhängig von der Abregelung.

Allerdings finde ich hast du dich hier im Ton vergriffen. Ich fühle mich 
in keinem Wettbewerb und ich will schon gar keine zwei Lager bilden. 
Bitte lass uns weiterhin an einem Strang ziehen. Jeder kann per PR 
beitragen. Die aktuelle Implementierung ist bei allen noch ein PoC oder? 
Es gibt noch kein richtig oder falsch sondern eher Fortschritte. Die 
Version des ESP8266 ist halt Stand heute nicht mehr 'up to date'.

[Hans W. (hans_w801)]

Guten Morgen,

soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr 
zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum 
MQTT Broker. z.B. bei mir gestern um 16 Uhr.

Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine 
Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den 
Logs.

Also ESP reboot und dann ist er sofort wieder connected.

Sonst noch jemand Probleme mit MQTT ?

[Lukas P. (lumapu)]

Wir diskutieren schon länger auf github über Stabilität.
https://github.com/grindylow/ahoy/issues

MQTT läuft bei mir stabil, hatte vor 20h den letzten Komplettabsturz, 
danach hat alles von selbst wieder funktioniert. (Version 0.3.6)

[H. E. (h_e)]

Hans W. schrieb:
> Guten Morgen,
> soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr
> zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum
> MQTT Broker. z.B. bei mir gestern um 16 Uhr.
> Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine
> Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den
> Logs.
> Also ESP reboot und dann ist er sofort wieder connected.
> Sonst noch jemand Probleme mit MQTT ?

Bei mir selbiges. Das Wlan läuft stabil, aber der MQTT-Client schließt 
die Verbindung und macht sie nicht wieder neu auf.

[Robert S. (Gast)]

Mein Wemos D1 mini mit 0.3.6 läuft leider gar nicht stabil. Die Uptime 
ist selten höher als 1 Stunde, die automatischen reboots dauern oft sehr 
lange oder vielleicht findet er auch keine SSID oder DHCP. Jedenfalls 
habe ich in der Statistik manchmal stundenlange Lücken. Vermutlich auch 
deshalb weil er nur ca. jedes zweite Mal den MQTT connected. Die onboard 
LED blinkt übrigens unregelmäßig, weist das auf Ausfälle hin?

WIFI Probleme glaube ich eher nicht, RSSI ist bei ca. -70dbM,
andere ESP8266 in der Nähe funktionieren ohne Probleme.
Kann es sein dass das NRF Modul stört, es sendet und empfängt ja auf 
derselben Frequenz. Das NRF-Modul scheint recht stabil zu sein, der WR 
ist durch ein Fenster mit Jalousie und dann noch ca. 20m Luftlinie 
entfernt.

Wäre es möglich den WIFI-RSSI auf der Webpage anzuzeigen oder via MQTT 
zu publishen? Damit könnten wir schlechte Verbindungen leichter 
erkennen.

[Hans W. (hans_w801)]

Also heute ist es wie gestern ... um 16 Uhr MQTT Abbruch aber der Wemos 
ist noch up

[isnoAhoy (Gast)]

Hallo Zusammen,

ich habe heute mal versucht den HM-600 aufzuschrauben. Leider habe ich 
ihn nicht komplett aufbekommen. Ich vermute daß man irgendwie die 
Kabelzugentlastungen lösen muß und evtl. auch noch mit etwas Wärme aus 
einem Heißluft-/-fön die Dichtungen lösen muß. Das habe ich meinem neuen 
Geräte dann doch nicht alles zumuten wollen, es soll ja nachher wieder 
wasserdicht und möglichst lange seinen Dienst verrichten.

Vielleicht hat ja jemand einen gebrauchten, defekten HM den er mal zu 
Anschauungszwecken defilieren kann ?

@Jan-Jonas, ich habe Deine Paketanalyse mal nachvollzogen. M.E. hast Du 
Recht mit dem Paketzähler und dem höchstwertigen Bit 0x8y das das letzte 
Paket oder eben die Anforderung für einen Request (vielleicht sogar 
einen Retransmit) bedeutet.

Ich habe die Ergebnisse dieser Paketanalyse vorläufig hier im Github 
Issue dokumentiert, das kann man ggf. auch in die hoymiles Doku 
aufnehmen.
https://github.com/grindylow/ahoy/issues/24

Hat das (so einen Retransmit oder die Spezialanfrage mit X Paketen von 
Jan Jonas) bei den auf Seite 1 & 2 gemachten HackRF und anderen 
Funkprotokollmitschnitten der Original DTU auch sonst noch jemand 
feststellen können ? Vielleicht können ja noch ein paar alte Hasen (die 
schon vor Ostern hier geforscht haben) hierzu etwas beitragen ?

[Lukas P. (lumapu)]

lpb schrieb:
> Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das
> Anfordern eines nicht erhaltenen Pakets.
> Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket
> anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'.

@isnoAhoy
Hier wurden die Retransmits bereits im DTU Log gefunden.

Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal 
die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein 
Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die 
Statistiken, also die Counter wie oft welches Paket kam.
"CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x 
0x84

Anfrageinterval war 1s auf Kanal 40, empfangen statisch auf Kanal 3.

[Chris (Gast)]

Bei mir werden die Werte per MQTT alle Sekunde geschickt obwohl es auf 
10 Sekunde  eingestellt ist. Änderungen der Zeit haben keinen 
Einfluss.Ist das auch bei anderen so? ESP-DTU 0.3.6

[isnoAhoy (Gast)]

Hallo Lukas P.,
Du hast Recht in Spalte AA bis AE stehen drei Pakete der 
Standardantwort.
Man kann gut sehen, daß der GD32 das Paket 0x01 nicht empfangen hat und 
damit in Spalte AD nochmal mit 0x81 und CRC8 0x94 anfordert. Die Antwort 
mit dem fehlenden Paket kommt dann in Spalte AE.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Nur die Paketcounter sind eben nicht in Zeile 16 wie von martin (Gast) 
im Excel vermutet. Sondern wie richtig von lbp und Jan-Jonas bemerkt das 
in Zeile
10 bisher als CMD bezeichnete Byte. Zeile 13-16 ist hingegen die Zeit in 
Unix-Epoch wie anderweitig bereits herausgefunden wurde.

In Spalte AU-AZ taucht dann auch die Anfrage mit 0x80 0x11 auf, die 
Jan-Jonas als bisher größtes Antwortnachricht mit den Paketen 0x01..0x85 
des WR identifiziert hat.

@martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in 
der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export 
Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt 
zwischen GD32 und nRF24 aufzuzeichnen ?

[Lukas P. (lumapu)]

Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) 
werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, 
ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen 
Sinn ständig die Zeit neu zu setzen. Gedacht habe ich an sowas wie ein 
Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die 
Retransmits.

@Jan-Jonas S. (janjonas_s)
Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der 
C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu 
prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh 
oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den 
Payload gebildet werden.

Beispiel, so wie es aktuell verstehe, aber die CRC8s und CRC16_P stimmen 
nie:

01 [...] CRC8 CRC16_H CRC16_L
02 [...] CRC8 CRC16_H CRC16_L
....
8X [...] CRC16P_H CRC16P_L CRC8 CRC16_H CRC16_L

CRC8: über Paketpayload ohne CRC8 und CRC16
CRC16: ist implementiert und funktioniert
CRC16P: über die gesamte Payload aller Pakete - mit oder ohne dem 
Paketcounter?

[franz (Gast)]

Hallo Jan,

Jan-Jonas S. schrieb:
> Hinzugekommen sind:
>   * Support für den HM-1500

ich dachte bisher dass ich HM-350 haette (steht leider nicht lesbar 
drauf ohne den WR vom Modul zu lösen, das ja auch noch montiert ist),

Aber HM-4xx macht keinen Sinn, da ich pro Modul nur 325Wp habe. 
Allerdings war ja die Vermutung dass die 3xx und 400 gleiches Protokoll 
haben, darum hatte ich die bei mir alles als 300 zusammengefasst. Ich 
habe daher im angefügten diff meine (mit 112174..) als 3XX  bezeichnet, 
aber vermutlich könnte man die letzte Stelle weglassen und 3xx und 4xx 
damit covern. Ich habe ein diff attached.

Ad Retransmit, das hatte bei mir nicht funktioniert, bis ich die +6e7 ns 
bei empfangenen Paketen entfernt hatte, dann erwischte ich ueberhaupt 
fast alles, das hast Du jetzt auf +5e8, meine Antworten kommen zwischen 
1ms und 10ms, geht sich also locker aus.
Sollte auch in der Mikrocontrollerversion also mindestens so hoch sein.

Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages 
auch flat in ein kompaktes File schreiben zu können, hab mir sowas für 
einen geplanten remote site implementiert wo ich keine db hinter 
iobroker haben werde.

lg,
Franz

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen)
> werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich,
> ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen
> Sinn ständig die Zeit neu zu setzen.
Ich glaube der WR hat keine RTC und braucht daher die Updates der Zeit 
über die Luft, damit er z.B. weiß wann die daily counter resetet wetden 
müssen.

> Gedacht habe ich an sowas wie ein
> Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die
> Retransmits.
Da stehen wir noch vor dem Anfang.
Ich glaube, dass das byte nach 0x80 (normal 0x0b) das Kommando ist. Die 
Zeit, die wir dahinter setzen die Parameter zum Kommando.

Ich hab das mal durchgesweept und bekomme da alle möglichen langen und 
kurzen Antworten, die sich meist auch unterscheiden jenachdem welche 
Parameter man anhängt. Da sind wir auf mehr DTU Captures angewiesen um 
das verstehen zu können. Aber da war in python spätestens auch Schluss 
mit den cmd'd, weil jede Antwort mindestens ein Fragment 1 enthält, wo 
keine bekannten Werte drin stehen. Das macht dann graphen sehr kaputt, 
wenn man random binärdaten zu Zahlen macht.

Übrigens zum sweepen s.O. das /command-Topic. Sehr handy.

> @Jan-Jonas S. (janjonas_s)
> Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der
> C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu
> prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh
> oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den
> Payload gebildet werden.

in hoymiles/__init__.py InverterTransaction.get_payload()

# check crc
pcrc = struct.unpack('>H', payload[-2:])[0]
if f_crc_m(payload[:-2]) != pcrc:
    raise ValueError('Payload failed CRC check.')

Jedes Frame besteht aus
0x95, 4byte dst_addr, 4byte src_addr, 1byte sequence, bis 16byte(?) 
data, 1byte crc8

sequence:
 0x01 - 0x80 ist ein forlaufendes Fragment
 0x81 - 0xFF(?) markiert das letzte Paket, und die Gesamtzahl der 
Fragmente

Wenn sequence größer 0x80:
    int(sequence - 0x80) = Anzahl Fragmente

Das Endpaket zählt mit in den Paketzähler, 0x80 kann daher kein Wert des 
Endpakets sein. 0 Pakete = keine Übertragung ;)

Wenn mann alle data bytes in der richtigen Reihenfolge zusammen setzt 
(Payload), sind am Ende die 2 byte die modbus crc über die ganze Payload

Fehlt das Endpaket ist die Transaktion verloren. Die Pakete werden 
meistens nicht in der richtigen Reihenfolge empfangen. Kann sein, dass 
man die in der Reihenfolge 84, 01, 03, 02 liest.

Neu ist für mich auch, dass bei längeren Payloads, der WR auch auf Ch 40 
antwortet.

Den ersten Re-Transmit habe ich hier gefunden
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Jan-Jonas S. (janjonas_s)]

Hallo franz,

vielen Dank für das HM3XX-Mapping! Pulled-in.

franz schrieb:
> Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages
> auch flat in ein kompaktes File schreiben zu können, hab mir sowas für
> einen geplanten remote site implementiert wo ich keine db hinter
> iobroker haben werde.

Sowas ist geplant und möglich.
Ich stelle mir das python-modul später mal so vor, dass man es ähnlich 
wie auch den paho mqtt-client irgendwo rein laden kann und ein 
on_message-Callback bekommt, indem man Daten aus der Response nach 
belieben verarbeiten kann.

Ich plane z.B. einen direkten Influx2-Exporter, so umzusetzen. Das soll 
dann jeder selber modular bauen können, weil jeder sein eigenes Backend 
hat und die Zahl der Output-Plugins den Rahmen des Projekts sprengen 
würde.

Da bin ich aber noch nicht soweit, weil wir mit Sicherheit im Kern noch 
Dinge entdecken die möglicheriweise grundlegend überarbeitet werden 
müssen. Da liegt im Moment mein Fokus drauf. Bis dahin würde ich gerne 
die Komplexität außen rum so gering wie möglich halten.

Gruß,
Jan

[franz (Gast)]

Hallo Jan,

Jan-Jonas S. schrieb:
> Pulled-in.

hab die germergte version ausprobiert, funktioniert. Überinges war meine 
timing Aussage vorher falsch es sind 1-10 hundertstel-, nicht 1-10ms.

Ich hatte mir mehrere (7) NRF module bestellt, weil ich mir nicht sicher 
war, ob die wayintop + sind, die + von AZ so billig waren und laut 
Kommentaren und eigenen Beobachtungen gibt es öfters Aufälle, bzw 
schlimmer, funktioniert dann nicht zuverläßig. Ich habe nur in ca einen 
von 1000 Fällen eine Antwort am Sendekanal (40) und 90% auf 3 und 75. 
ALso kann ich mit einem chip staendig auf 3 und mit dem Sender gleich 
auf 75 umschalten, um zu sehen ob was kommt. Mit einem 2. Rapsi kann ich 
dann auch noch auf 2 weiteren Kanälen lauschen, sollte von der library 
her gehen und werde das mal ausprobieren :)

lg,
Franz

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> lpb schrieb:
>> Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das
>> Anfordern eines nicht erhaltenen Pakets.
>> Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket
>> anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'.

So, wie es halt das python-modul seit einiger Zeit macht. Was ich ja 
alles schon geschrieben habe. Offensichtlich lest Ihr nicht.

> Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal
> die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein
> Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die
> Statistiken, also die Counter wie oft welches Paket kam.
> "CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x
> 0x84
Was für einen Nährwert hat diese Satistik?
Das ist wie wenn man hin und wieder mal aus dem Fenster schaut und über 
den Tag die Autos nach Farbe zählt, die gerade zufällig vorbei fuhren.

Die Daten aus dem 220507_PayloadHm1200.log machen für mich überhaupt 
keinen Sinn. Je Frame gibts max 16 byte Payload-Fragment.

In der Payload gibts garkeinen Bezug mehr, in welchem Frame ein 
Schnipsel mal rein kam.

Im Anhang nochmal valide Daten von einem HM600 als Referenz.
Daran könnt Ihr eure Implementierung mal testen, bis diese zu den 
gleichen Werten kommt.

Die Transaktion:
  * Transmit Request (gesendete Daten merken)
  * Alle innerhalb $Timeout empfangenen Daten per Frame-CRC (letztes 
byte) virifizieren und wenn valide den Datenteil und die sequenz in ein 
stack aus (seq, data) appenden. Die Adressen und Frame-CRC können da 
schon verworfen werden.
  * buffer nach sequenz größer 0x80 durchsuchen, damit man weiß wieviele 
Frames der WR gesendet hat
  * über den stack iterieren range(1, int(sequenz - 0x80)) und alle 
daten der reihe nach zusammensetzen + daten letztes Frame oder wenn man 
kein frame mit der sequenz findet, re-transmit anfordern und response 
auf den stack werfen. Schritt Wiederholen.
  * modbus_crc(data ohne letzten beiden byte) == data letzten beiden 
byte checken
  * final payload = data[:-2] (2 byte checksum weg)

Dann wird der Request der Transaktion wieder wichtig, weil man daran den 
Decoder wählt, dem man die finale Payload überreicht.

Nach aktuellem Kenntnisstand ist der Dekoder anhand des byte 11 (0b bei 
Zeit setzen) aus dem Request zu wählen. In der Payload gibts wohl keinen 
Identifier der enthaltenen Daten.

Der Wesentliche Teil findet sich da in 
hoymiles/__init__.py:InverterTransaction.get_payload()
Dort wird die Payload zusammengebaut.

Gruß,
Jan

[martin (Gast)]

isnoAhoy schrieb:
> @martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in
> der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export
> Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt
> zwischen GD32 und nRF24 aufzuzeichnen ?

Leider habe ich nur die DTU Lite, damit kann ich nichts regeln. Die 
Anzeige der Live-Werte im Installationsmodus kann ich mal testen. Bisher 
schneide ich die Kommunikation nur mit dem Logic Analyzer mit, was einen 
gewissen Aufwand darstellt - stattdessen möchte ich mir demnächst mal 
einen Logger basteln, damit ich längerfristig die Daten mitschreiben 
kann. Die werde ich dann gerne bereitstellen.

Für die Statistik hier noch meine Seriennummern:
DTU Lite: 10D9-72...
HM-600: 1141-72...

[Andi (Gast)]

Danke martin,
dass du es zumindest schonmal kurz versuchst hast dir anzusehen.
Das Power Limit lässt sich aber defintiv nur mit der DTU-Pro einstellen.
Ich habe dazu auch noch eine kleine Anleitung gefunden vom letzten Jahr, 
für die DTU-Pro Nutzer, die es Testen wollen/können:
https://www.shinetech-power.de/wp-content/uploads/2021/11/Shinetech_DTU_Set70Percent_Hoymiles.pdf
Die Oberfläche sieht vielleicht inzwischen etwas anders aus, aber 
irgendwo sollte der Punkt versteckt sein.
Der Zero Export Modus wird logischerweise ohne externe Modbus 
Messeinrichtung nicht funktionieren und falls es dort 70% Festwert zur 
Auswahl gibt, könnte es sein, dass er einfach nur als beliebiges Limit 
die 70% an den WR sendet. Egal welcher Weg, es wird am Ende wohl immer 
nur ein Prozentwert in ein Register des WR gesendet werden und das lässt 
sich wohl am besten mit der frei wählbaren Option testen/loggen.
Ich würde mich sehr freuen, wenn das noch klappt, ansonsten muss ich in 
knapp einem Monat ein Loch in meinen WR bohren und etwas löten. Mehr zu 
meinem Grund/Vorhaben dafür habe ich bereits eher geschrieben.

Das mit den Seriennummern sollte ja inzwischen fest stehen, wie es auch 
Sprinterfreak im Git und isnoahoy hier geschrieben hat:
Hoymiles HM Serie:
SN 1121 = 1 MPPT/Eingang  -> HM-300/350/400
SN 1141 = 2 MPPT/Eingänge -> HM-600/700/800
SN 1161 = 4 MPPT/Eingänge -> (HM-1000)/1200/1500

Mein frisch gelieferter HM-800 hat die SN 114180...

Grüße

[Mc_K (Gast)]

Danke für die Info. Sollte dieses "Funfact" bezug auf mein Posting 
nehmen, so möchte ich darauf hinweisen dass ich von der DTU in der 
Mehrzahl (Plural) geschrieben habe und nicht explitit die DTU-Pro-S 
erwähnt habe.

Ist es Empfehlenswert, die Inverter vorerst nicht mit einer DTU zu 
verbinden, um mögliche komplikationen durch Updates zu vermeiden?

[Lukas P. (lumapu)]

Jan-Jonas S. schrieb:
> Im Anhang nochmal valide Daten von einem HM600 als Referenz.
> Daran könnt Ihr eure Implementierung mal testen, bis diese zu den
> gleichen Werten kommt.

Das war sehr hilfreich. Habe jetzt den CRC8 und den CRC16 korrekt 
nachvollziehen können.

Kanal-Switching auf RX Seite habe ich eingebaut, die Ergebnisse sind 
gemischt:
Was mir aufgefallen ist: Wenn ich TX auf 40 stelle, dann bekomme ich nie 
Antworten auf Kanal 40. Habe den vorerst mal rausgenommen, evtl. kann 
man hierdurch die Retransmits zu reduzieren, da man in dieser Zeit auf 
anderen Kanälen lauschen kann.
Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus 
bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten 
liegen.

Gibt es schon Erkenntnisse wie oft der WR seine Daten erneuert? Ich 
glaube im Python Code ein 5s Interval erkannt zu haben.

Hat schon jemand bei diesem Kommando mit den Parametern experimentiert?

setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms

[Thomas B. (tbnobody)]

Ich habe aktuell das Python in der letzten Version von Jan am laufen [1]
Die Ergebnisse sind toll. Habe ein 5 Sek. Intervall eingestellt und 
bekomme dort zuverlässig Daten.

[1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi

[Thomas B. (tbnobody)]

Lukas P. schrieb:
> Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus
> bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten
> liegen.

Ja, das ist mir auch schonmal aufgefallen. Eine Änderung der 
Antennenausrichtung hat hier wunder gewirkt. (Zusätzlich zu dem 
Kondensator den ich sowieso am NRF Modul habe)

[st_b (Gast)]

in der app.cpp hab ich folgendes beim Serial-Output (mit 
mSerialInterval=600) reingefrickelt - sorry, ich hatte keine Zeit mich 
in den Code ernsthaft einzulesen - vielleicht bringt es trotzdem 
jemanden etwas:

#include <ESP8266HTTPClient.h>

#define SERVERNAME "http://pvoutput.org/service/r2/addstatus.jsp"
#define APIKEY "40digit-hex-API-Key" // pvoutput.org API-Key
#define SYSTEMID 12345 // pvoutput.org systemID

...
...
...

void app::loop(void) {

...
...
...

    if (mSerialValues) {
      if (++mSerialTicker >= mSerialInterval) {
        mSerialTicker = 0;
       uint16_t energy = 0;
        for (uint8_t id = 0; id < mSys->getNumInverters(); id++) {
          Inverter<> *iv = mSys->getInverterByPos(id);
          if (NULL != iv) {
            uint8_t modNum, pos;
            switch (iv->type) {
              default:              modNum = 1; break;
              case INV_TYPE_HM600:
              case INV_TYPE_HM800:  modNum = 2; break;
              case INV_TYPE_HM1200: modNum = 4; break;
            }

            for (uint8_t ch = 1; ch <= modNum; ch ++) {
              energy += iv->getValue(iv->getPosByChFld(ch, FLD_YD));
            }
          }
        }

        char serverPath[255] = {0};
        sprintf(serverPath, "%s?key=%s&sid=%d&d=%04d%02d%02d&t=%02d:%02d&v1=%d", SERVERNAME, APIKEY, SYSTEMID, year(mTimestamp), month(mTimestamp), day(mTimestamp), hour(mTimestamp), minute(mTimestamp), energy);

        Serial.println(serverPath);

        HTTPClient http;
        WiFiClient client;

        http.begin(client, serverPath);

        // Send HTTP GET request
        int httpResponseCode = http.GET();

        if (httpResponseCode > 0) {
          Serial.print("HTTP Response code: ");
          Serial.println(httpResponseCode);
          String payload = http.getString();
          Serial.println(payload);
        }
        else {
          Serial.print("Error code: ");
          Serial.println(httpResponseCode);
        }
        // Free resources
        http.end();



        char topic[30], val[10];
        for (uint8_t id = 0; id < mSys->getNumInverters(); id++) {
          Inverter<> *iv = mSys->getInverterByPos(id);
          if (NULL != iv) {
            for (uint8_t i = 0; i < iv->listLen; i++) {
              if (0.0f != iv->getValue(i)) {
                snprintf(topic, 30, "%s/ch%d/%s", iv->name, iv->assign[i].ch, iv->getFieldName(i));
                snprintf(val, 10, "%.3f %s", iv->getValue(i), iv->getUnit(i));
                DPRINTLN(String(topic) + ": " + String(val));
              }
              yield();
            }
          }
        }
      }

[st_b (Gast)]

oben sollte eine Antwort auf folgenden Beitrag sein - sorry
Robert Bleumer schrieb:
> HM1500 funktioniert hier auch mit ESP8266 und NFR24L01+ und die
> letzte
>
> Seriennummer meine 1500 fangt auch mit 1161 an.
>
> Steht upload nach PvOutput.org noch auf's Programm?

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> Was mir aufgefallen ist: Wenn ich TX auf 40 stelle, dann bekomme ich nie
> Antworten auf Kanal 40. Habe den vorerst mal rausgenommen, evtl. kann
> man hierdurch die Retransmits zu reduzieren, da man in dieser Zeit auf
> anderen Kanälen lauschen kann.

Auf 40 antwortet der WR einiges, wenn man ihn was fragt wo es längere 
Payloads als 4 Frames gibt. Also bei mir bleibt der definitiv drin. ;)
8002tttttttt00000500000000 z.B. liefert mir fast immer ein Teil der 
Response auf Ch40 aus.

Dafür habe ich vom WR noch nie was bekommen, wenn ich auf was anderem 
als 40 anfrage. Oli hat aber glaub ich auch schon Antworten auf Anfragen 
auf anderen Kanälen bekommen? Solange 40 bei allen funktionert bin ich 
glücklich. Eine Hoplist ist zumindest auch für TX schon so halb 
vorbereitet. Ich sehe gerade keinen Grund dafür. Meine Idee währe 
ohnehin eine Transceiver-List im YAML-File hinzuzufügen wo man sagen 
kann.

- channel: [23,40]
  mode: tx
  ce_pin: n
- channel: [3,23,40,61]
  mode: rx
  ce_pin: n

z.B. Da ich aber auch mit nem 2s Interval eigentlich kein cycel 
verliere, sehe ich dafür absolut kein Bedarf mehr. (Also 
multi-transceiver Setup)

> Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus
> bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten
> liegen.

Da wir keinem Funkplan folgen und kenie Rücksicht drauf nehmen ob wir 
irgendwas dazwischen funken was gerade schon auf Welle ist, ist eine 
Kollision sehr wahrscheinlich. Dann versteht natürlich niemand mehr was, 
da können wir nichts machen außer re-transmitten bis wir eine Antwort 
bekommen. Also quasi das Band solange jammen bis andere aufgeben. :D
Dann kommt noch dazu, dass die Antenne tatsächlich kein wirklicher 
Rundstrahler ist und schon recht optimal stehen muss.

> Gibt es schon Erkenntnisse wie oft der WR seine Daten erneuert? Ich
> glaube im Python Code ein 5s Interval erkannt zu haben.

On Request. Ich hab auch wenn ich den mit 1s polle immer neue Daten. 
Schneller lässt das Protokoll das nicht zu.

> Hat schon jemand bei diesem Kommando mit den Parametern experimentiert?
>

> setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms
>

SEHR viel. Hätte ich einen Sketch so oft kompillieren und auf einen ESP 
schreiben müssen, hätte ich einen hohen Chip-Verbrauch gehabt. :D
Die Settings haben bei mir damals son sweet spot getroffen. Scheint aber 
wohl sehr von der Funk-Umgebung abzuhängen wie sich rausstellt.

Gruß,
Jan

[isnoAhoy (Gast)]

Hallo Jan-Jonas,

ich habe mir mal Deine Transmit Pakete angesehen und folgendes Byte >05< 
ist mir dabei aufgefallen:

2022-05-08 15:24:27.553664 Transmit 27                 | 15  72 22 01 43 
78 56 34 12  80  0b 00 62 77 c4 8b 00 00 00>05<00 00 00 00 27 f2  0e

Bei den von martin (Gast) am RX/TX zwischen GD32 und nRF24 
aufgezeichneten Daten seiner DTU Lite wurde hier immer >00< übertragen. 
Hast Du einen Grund an der Stelle einen anderen Wert zu übertragen, bzw. 
bekommst Du hier andere Antworten je nach Anfrage ?

Ich habe auf der Suche nach diesem Byte auch noch folgende Anmerkung und 
Beobachtung von Oliver F. gefunden:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

> Martin (Gast) hatte noch eine Anmerkung:
>> Was mir hier und auch in meinen Daten aufgefallen ist: In den
>> Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer
>> mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun
>> haben, der für die Antwort verwendet werden soll?
>
> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
>
> Turn unit off:
> C2 850194040 00 1946107301 00DA 1B 1  15 73104619 72819005
> 800B00623B5CD8000000>08<0000000013DAD8A73B 3BA7 1
> Turn unit on:
> C2 067083344 00 1946107301 00DE 1B 3  15 73104619 72819005
> 800B00623B5D5A000000>09<00000000B0CEEDD61D 1DD6 1
> Turn unit off:
> C2 055407012 00 1946107301 00DA 1B 1  15 73104619 72819005
> 800B00623B5DC2000000>0A<0000000076413F7EAF AF7E 1
> Turn unit on:
> C2 086582484 00 1946107301 00DA 1B 1  15 73104619 72819005
> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1

Das 0x8y bedeutet m.E. daß die letzten beiden Byte (vor dem letzten 
CRC8) einen CRC_M bzw CRC16 enthalten. 0x8y kann ja sowohl bei Anfragen 
als auch bei Antworten auftauchen.

Das mit dem Kanal/allen Kanälen jammen konnte ich auch in martins Logic 
Analyzer Aufzeichnungen im Excel sehen (Spalte O-Z), dort wird die 
Anfrage insgesamt 12x wiederholt, lediglich der time_t Zeitstempel und 
somit auch die CRC16 & CRC8 werden ggf. angepaßt.

Jetzt müssten wir also die Antworten auf 0x800b, 0x8011 und 0x8003 je 
Wechselrichter Modellreihe, z.B. 1121, 1141 und 1161 dekodieren. Das ist 
für die 0x800b Statusanfrage m.W. auch soweit schon alles funktional.

Es fehlen aber noch das Verständnis für die Antworten auf 0x8011 und 
0x8003 die Einige (martin, Oliver, Hubi & Herbert, etc.) hier vorher 
beobachtet haben. 0x8003 geht dabei sogar von 0x01, 0x02, .., 0x09, 
0x0A, 0x0B bis 0x8C. Diese Anfragen & deren Antworten sind vermutlich 
auch wieder in Abhängigkeit von der Modellreihe zu untersuchen. Anbei 
das Beispiel aus martin's RX/TX Logic Analyser Excel als Screenshot.

[isnoAhoy (Gast)]

Hallo Jan-Jonas,

> SEHR viel. Hätte ich einen Sketch so oft kompillieren und auf einen ESP
> schreiben müssen, hätte ich einen hohen Chip-Verbrauch gehabt. :D

Ich weiß, ziemlich Off-Topic, aber wie macht ihr das eigentlich auf 
Eurem Raspberry Pi die vielen MQTT Daten in eine InfluxDB o.a. zu 
speichern.
Da müsste ja jede SD Karte den Geist aufgeben.
Habt Ihr dafür irgendeine (m)SATA / m.2 SSD eingebaut ?
Wenn ja, welchen Adapter (USB->SATA) verwendet ihr und wie groß bzw. 
welcher Bauart ist die SSD ?

[Jan-Jonas S. (janjonas_s)]

Hallo,

isnoAhoy schrieb:
> Ich habe auf der Suche nach diesem Byte auch noch folgende Anmerkung und
> Beobachtung von Oliver F. gefunden:
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Das. Was genau es bedeutet, keine Ahnung. Zu dem Zeitpunkt habe ich das 
Projekt gejoined und hab das so aus der alten ahoy.py übernommen.
Nein, ich sehe keine Änderung, wenn ich da was anderes übertrage.

>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
05
>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1

Guter Fund!

> Das 0x8y bedeutet m.E. daß die letzten beiden Byte (vor dem letzten
> CRC8) einen CRC_M bzw CRC16 enthalten.

Nicht ganz. Die Adressen, der Frame-Counter und das letzte Byte gehören 
zum ESB-Frame. Die CRC16_M, zufällig in dem ESB-Frame mit Counter größer 
0x80, ist zu diesem Zeitpunkt nur Payload und hat nichts mit dem 
Transport-Layer zu tun.

Die CRC16_M existiert für uns also am besten nur in der Payload, wenn 
sie wieder defragmentiert ist. Ich könnte jetzt natürlich auch mal 
schauen, ob die letzten beiden Byte anderer Payloads auf random Requests 
auch eine CRC16_M ist ... Das würde die Anzahl zu erratener Bytes 
reduzieren :D

> InfluxDB
> Da müsste ja jede SD Karte den Geist aufgeben.
Richtig. SD ist by design kaputt.

> Habt Ihr dafür irgendeine (m)SATA / m.2 SSD eingebaut ?

So habe ich meine 0-Einspeise-Regelung realisiert. Rechenzentrum zu 
Hause. Da steht ein i3 mit Proxmox und NVME. Sicher radiert das da auch 
ganz schön trotz wear leveling (Was die SD nicht hat). Aber ich mag 
bunte Grafiken, wo ich rein zoomen kann und trotzdem keine Auflösung 
verliere. Ich halte die Daten 1 Woche mit voller Auflösung und danach 
reduziert ein CQ das runter auf 10 Minuten. So bleibt das dann ewig. Die 
paar Wechselrichter-Werte sind da aber nur ein ganz kleiner Teil vom 
Rauschen. :)

Gruß,
Jan
mqtt->telegraf->InfluxDB. Beispiel habe ich oben auch schon mal 
gepostet.

Append:
Der incrementierende Counter verrät dem WR im Grunde wieviele Commands 
er hinterher hängt. Wie verhält sich denn das erste Byte der Payload zum 
Command-Counter. Könnte das vielleicht die Differenz angeben, damit die 
verpassten Nachrichten nochmal hinterher geschoben werden können?

[Sorbit (Gast)]

Jan-Jonas S. schrieb:
> So habe ich meine 0-Einspeise-Regelung realisiert.

Wie hast Du diese denn realisiert?
Du benötigst ja einen steuerbaren WR....

[isnoAhoy (Gast)]

Hallo Jan-Jonas,
danke für die Antwort.

Ich habe nochmal den Github Kommentar nachgelesen, in dem ich 
exemplarisch Mal eine 0x8002 Anfrage und Antwort von Dir untersucht 
hatte.

https://github.com/grindylow/ahoy/issues/24#issuecomment-1120237280

Hier mal die Antwort auf die 0x8011 wie von martin im Excel zwischen 
GD32 und nRF24 getraced.

$ xxd 0x8011.bin
00000000: 0001 b001 0001 0d34 0d34 0000 0000 708f  .......4.4....p.
00000010: 0004 0d3c 0d97 0002 07a3 7093 0005 0d3c  ...<......p....<
00000020: 0d97 0000 0000 a00e 0006 0d9c 0d9c 0705  ................
00000030: 0542 708f 0009 0d9c 0dd8 01e2 07a3 7091  .Bp...........p.
00000040: 000a 0d9c 0dd8 0000 12c0 d16a 377f       ...........j7.

Wir haben also nicht nur dei Anfragen 0x800b und 0x8011 gesehen, sondern 
auch wie von Hubi/Herbert berichtet eine 0x8003 und die von Dir geloggte 
0x8002. Die Anfragen sollte man vielleicht auch nach ein paar Tagen 
nochmal wiederholen, da es wohl nicht besonders schnell veränderliche 
Daten sind. Zumindest taucht die Anfrage 0x8011 in martin's DTU Logic 
Analyzer Daten nur einmal auf.

Bzgl. dem RF24 am Raspberry habe ich noch eine weitere Frage:
Warum funktioniert es da auch ohne Interrupt, beim ESP8266 schliessen 
wir extra den Interrupt an. Ich hatte irgendwo ein Issue im RF24 github 
gelesen, das aber schon geschlossen war bzgl. optionaler pigpio 
Unterstützung für Interrupts.

[Jan-Jonas S. (janjonas_s)]

Hallo isnoAhoy,

ich habe mal die Payload aus dem Screenshot abgetippt. Nicht nur, dass 
die ganz anders aussieht als bei mir, die crc stimmt auch nicht.

Dafür habe ich mal 0x11 bei mein HM600 angefragt und ein wenig rum 
probiert. Ich hab fast die Vermutung, dass das eine Daily history von 
energy total von einem String ist. In meiner Payload sieht das sehr nach 
Tabelle von irgendwas aus. Ich hab hier mal kurz die Payload mit 
Linebreaks versehen. Ich sehe da ein Muster.

00 01
80 01 00 06 31 53 31 53 00 00 00 00 
80 02 00 35 a7 fa a7 fa 00 00 00 07 
b0 02 00 36 00 32 00 32 ff ff ff fb 
b0 02 00 37 00 39 00 39 00 00 00 05 
b0 02 00 38 05 c2 05 c2 ff ff ff fa 
b0 02 00 39 05 c6 05 c6 00 00 00 06 
b0 02 00 3a 18 6c 18 6c ff ff ff fb 
b0 02 00 3b 18 6f 18 6f 00 00 00 05 
b0 02 00 3c 23 5a 23 5a ff ff ff fb 
b0 02 00 3d 23 5e 23 5e 00 00 00 05 
b0 02 00 3e 25 de 25 de ff ff ff fb 
b0 02 00 3f 25 e3 25 e3 00 00 00 05 
b0 02 00 40 26 c9 26 c9 ff ff ff fa 
b0 02 00 41 26 ce 26 ce 00 00 00 06 
b0 02 00 42 27 ea 27 ea ff ff ff fb 
39 f2 <- modbus crc

Bei 0x12 habe ich einmal eine ähnliche Antwort bekommen und jetzt kommt 
bei 0x12 nur noch

2022-05-10 18:37:20.973622 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 12 00 62 7a 94 bd 00 00 00 00 00 00 00 00 b2 61 7f
2022-05-10 18:37:21.019035 Received 15 bytes channel 3: 95 72 22 01 43 72 22 01 43 81 00 01 70 c0 a5
2022-05-10 18:37:21.522190 Payload: 00 01 70 c0
 payload has valid modbus crc

Gruß,
Jan

[Herbert K. (avr-herbi)]

Beim Beschiessen der HM350 + HM400 mit 0x11 bekomme ich 2 verschieden 
lange Antworten:
a) 5+1 Telegramme (letztes = 86....)
b) 8+1 Telegramme (letztes = 89....)
c) oder 8114 als Kurztelegramm (Payload=0x14)
Wobei die letzten Telegramme (also 86..., 89...) weniger Lang sind nach 
dem was mir angezeigt wird.
Auf jeden Fall wiederholt sich öfters ...8002... in der Payload.
Entschlüsselt habe ich noch nix.

[Lukas P. (lumapu)]

Jan-Jonas S. schrieb:
> Auf 40 antwortet der WR einiges, wenn man ihn was fragt wo es längere
> Payloads als 4 Frames gibt. Also bei mir bleibt der definitiv drin. ;)
> 8002tttttttt00000500000000 z.B. liefert mir fast immer ein Teil der
> Response auf Ch40 aus.

Ok, du bist da schon weiter - dann nehme ich es wieder auf.

Jan-Jonas S. schrieb:
> Dafür habe ich vom WR noch nie was bekommen, wenn ich auf was anderem
> als 40 anfrage.

Das sehe ich genauso, anfangs habe ich mit 4 Kanälen gearbeitet. Wenn 
man nicht auf 40 sendet, bekommt man nur 0x81 Pakete ohne Payload -> 
Fehlermeldung?

Jan-Jonas S. schrieb:
> On Request. Ich hab auch wenn ich den mit 1s polle immer neue Daten.
> Schneller lässt das Protokoll das nicht zu.

Wegen Zeit setzen und mit Unix-Timestamp? Dürfte auch mehr als genug 
sein.

Sorbit schrieb:
> Jan-Jonas S. schrieb:
>> So habe ich meine 0-Einspeise-Regelung realisiert.
>
> Wie hast Du diese denn realisiert?
> Du benötigst ja einen steuerbaren WR....

Oder man verheizt die Energie einfach kommt auch bei 0 raus, ist halt 
weniger nachhaltig (je nach dem was man mit dem Überschuss anstellt).

[Raik E. (raik85)]

Hallo,
bin noch neu hier aber erstmal meinen Respekt an all die hie reverse 
engeneered haben. Find ich super, da brauch ich mir jetzt die DTU für 
100Euro kaufen.
So ein Mini 8266 von AZDelivery tuts auch mit ein paar Modifikationen.

Kleines Feedback an die Developer von Ahoy:

-Tsun M800 läuft ohne Probleme, im Setup HM600 ausgewählt und 
Seriennummer eingetragen (114173307xxx)
-MQTT funktioniert noch nicht (vielleicht schon bekannt)
-Ich wünsche mir ein JSON file als Alternative zu MQTT

Lukas P. schrieb:
> Sorbit schrieb:
>> Jan-Jonas S. schrieb:
>>> So habe ich meine 0-Einspeise-Regelung realisiert.
>>
>> Wie hast Du diese denn realisiert?
>> Du benötigst ja einen steuerbaren WR....
>
> Oder man verheizt die Energie einfach kommt auch bei 0 raus, ist halt
> weniger nachhaltig (je nach dem was man mit dem Überschuss anstellt).

Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um 
Warmwasserspeicher.

Danke Jungs!

[Jan-Jonas S. (janjonas_s)]

Neue Erkenntnisse:
Die vermeintliche Liste in 80 11 wird länger, wenn man den Stecker 
zieht. Ereignisspeicher seit Einspeisebegin?

Poll inverter 114172220143
2022-05-11 09:47:14.398816 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 11 00 62 7b 69 fe 00 00 00 00 00 00 00 00 47 d7 80
2022-05-11 09:47:14.462357 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 01 00 01 80 01 00 06 32 88 32 88 00 00 00 00 80 0d 9f
2022-05-11 09:47:14.497777 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 00 07 68 3a 68 3a 01 ce 13 54 40 94 00 09 68 3a 97
2022-05-11 09:47:14.533164 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 68 90 09 3d 07 53 80 0d 00 0a 68 c8 68 c8 02 60 eb
2022-05-11 09:47:14.574203 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 12 45 40 94 00 0c 68 c8 69 0f 09 47 08 58 80 02 44
2022-05-11 09:47:14.639077 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 00 0d 6a 25 6a 25 ff ff ff fb 80 02 00 0e 6a 25 5a
2022-05-11 09:47:14.680307 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 6a 25 00 00 00 05 80 02 00 0f 6b 29 6b 29 ff ff 54
2022-05-11 09:47:14.751142 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 ff fb 80 02 00 10 6b 2c 6b 2c 00 00 00 05 80 02 83
2022-05-11 09:47:14.786377 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 00 11 6b 66 6b 66 ff ff ff fa 80 02 00 12 6b 6b 19
2022-05-11 09:47:14.827522 Received 19 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 6b 6b 00 00 00 05 01 69 71
2022-05-11 09:47:15.331532 Payload: 00 01 80 01 00 06 32 88 32 88 00 00 00 00 80 0d 00 07 68 3a 68 3a 01 ce 13 54 40 94 00 09 68 3a 68 90 09 3d 07 53 80 0d 00 0a 68 c8 68 c8 02 60 12 45 40 94 00 0c 68 c8 69 0f 09 47 08 58 80 02 00 0d 6a 25 6a 25 ff ff ff fb 80 02 00 0e 6a 25 6a 25 
00 00 00 05 80 02 00 0f 6b 29 6b 29 ff ff ff fb 80 02 00 10 6b 2c 6b 2c 00 00 00 05 80 02 00 11 6b 66 6b 66 ff ff ff fa 80 02 00 12 6b 6b 6b 6b 00 00 00 05 01 69
 payload has valid modbus crc
80 01 00 06 32 88 32 88 00 00 00 00:
 BBLHl  : (128, 1, 406152, 12936, 0)
 BBBBBHHHB: (128, 1, 0, 6, 50, 34866, 34816, 0, 0)
 12B    : (128, 1, 0, 6, 50, 136, 50, 136, 0, 0, 0, 0)

80 0d 00 07 68 3a 68 3a 01 ce 13 54: 
 BBLHl  : (128, 13, 485434, 26682, 30282580)
 BBBBBHHHB: (128, 13, 0, 7, 104, 14952, 14849, 52755, 84)
 12B    : (128, 13, 0, 7, 104, 58, 104, 58, 1, 206, 19, 84)

40 94 00 09 68 3a 68 90 09 3d 07 53: <-- Netztrennung
 BBLHl  : (64, 148, 616506, 26768, 154994515)
 BBBBBHHHB: (64, 148, 0, 9, 104, 14952, 36873, 15623, 83)
 12B    : (64, 148, 0, 9, 104, 58, 104, 144, 9, 61, 7, 83)

80 0d 00 0a 68 c8 68 c8 02 60 12 45: 
 BBLHl  : (128, 13, 682184, 26824, 39850565)
 BBBBBHHHB: (128, 13, 0, 10, 104, 51304, 51202, 24594, 69)
 12B    : (128, 13, 0, 10, 104, 200, 104, 200, 2, 96, 18, 69)

40 94 00 0c 68 c8 69 0f 09 47 08 58: <-- Netztrennung
 BBLHl  : (64, 148, 813256, 26895, 155650136)
 BBBBBHHHB: (64, 148, 0, 12, 104, 51305, 3849, 18184, 88)
 12B    : (64, 148, 0, 12, 104, 200, 105, 15, 9, 71, 8, 88)

80 02 00 0d 6a 25 6a 25 ff ff ff fb: 
 BBLHl  : (128, 2, 879141, 27173, -5)
 BBBBBHHHB: (128, 2, 0, 13, 106, 9578, 9727, 65535, 251)
 12B    : (128, 2, 0, 13, 106, 37, 106, 37, 255, 255, 255, 251)

80 02 00 0e 6a 25 6a 25 00 00 00 05: 
 BBLHl  : (128, 2, 944677, 27173, 5)
 BBBBBHHHB: (128, 2, 0, 14, 106, 9578, 9472, 0, 5)
 12B    : (128, 2, 0, 14, 106, 37, 106, 37, 0, 0, 0, 5)

80 02 00 0f 6b 29 6b 29 ff ff ff fb: 
 BBLHl  : (128, 2, 1010473, 27433, -5)
 BBBBBHHHB: (128, 2, 0, 15, 107, 10603, 10751, 65535, 251)
 12B    : (128, 2, 0, 15, 107, 41, 107, 41, 255, 255, 255, 251)

80 02 00 10 6b 2c 6b 2c 00 00 00 05: 
 BBLHl  : (128, 2, 1076012, 27436, 5)
 BBBBBHHHB: (128, 2, 0, 16, 107, 11371, 11264, 0, 5)
 12B    : (128, 2, 0, 16, 107, 44, 107, 44, 0, 0, 0, 5)

80 02 00 11 6b 66 6b 66 ff ff ff fa: 
 BBLHl  : (128, 2, 1141606, 27494, -6)
 BBBBBHHHB: (128, 2, 0, 17, 107, 26219, 26367, 65535, 250)
 12B    : (128, 2, 0, 17, 107, 102, 107, 102, 255, 255, 255, 250)

80 02 00 12 6b 6b 6b 6b 00 00 00 05: 
 BBLHl  : (128, 2, 1207147, 27499, 5)
 BBBBBHHHB: (128, 2, 0, 18, 107, 27499, 27392, 0, 5)
 12B    : (128, 2, 0, 18, 107, 107, 107, 107, 0, 0, 0, 5)

2022-05-11 09:47:15.345973 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 7b 6a 02 00 00 00 05 00 00 00 00 96 a1 c7
2022-05-11 09:47:15.409633 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3f 02 e4 09 35 01 40 02 e9 09 48 00 00 9a
2022-05-11 09:47:15.450519 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 ba 0a 00 00 b1 2d 01 53 01 52 08 ed 13 88 11 a8 7d
2022-05-11 09:47:15.485233 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 04 00 c6 03 e8 01 7b 00 12 59 e7 e9
2022-05-11 09:47:15.989314 Payload: 00 01 01 3f 02 e4 09 35 01 40 02 e9 09 48 00 00 ba 0a 00 00 b1 2d 01 53 01 52 08 ed 13 88 11 a8 00 04 00 c6 03 e8 01 7b 00 12 59 e7
2022-05-11 09:47:15.989314 Decoded: 37.9 phase0=voltage:228.5, current:19.8, power:452.0, frequency:50.0 string0=voltage:31.9, current:7.4, power:235.7, total:47.626, daily:339 string1=voltage:32.0, current:7.45, power:237.6, total:45.357, daily:338

Gruß,
Jan

[Martin P. (mpolak77)]

so eine Art Gedächtnis muss es geben. Ich hatte schon beobachtet, dass 
die DTU den HM350 plötzlich nicht mehr sah ... und am nächsten Tag waren 
plötzlich Daten zum Tag da.

Was ich mit meiner SW (Fork vom alten C-Code auf ESP8266) plötzlich 
beobachte (bis vor kurzem funktionierte es ganz passabel) ist, dass der 
etwas weiter entfernte HM350 von der Früh weg Werte schickt und dann 
plötzlich damit aufhört, bzw sehe ich am ESP keine Nachrichten mehr .... 
er verschwindet dann um ca 9:00 auch immer von der DTU .... speist aber 
weiterhin ein und auch die Led blinkt grün.
Am nächsten Tag kommen wieder Nachrichten und nach 1-2h hören sie auf.

Kann es sein, dass es so eine Art "denial of service" Schutz ist, wo der 
WR nach einer größeren Anzahl mit CRC fails oder einfach zu vielen 
Anfragen zu schweigen beginnt? Hat jemand ähnliches beobachten können?

Ich habe viel mit RX Channel hopping und unterschiedlichen Zeiten 
zwischen den ticks experimentiert .... nichts scheint das zu verbessern. 
Der HM700, der näher zu ESP und DTU ist liefert viel mehr Werte pro 
Zeiteinheit. Was sich geändert hat seit Anfang April ist die gesteigerte 
Vegetation zwischen HM350 und ESP ... ich habe aber auch mehrere 
Antennen getestet um das zu kompensieren (bus zu 9dBi omni)

[Jan-Jonas S. (janjonas_s)]

Martin P. schrieb:
> er verschwindet dann um ca 9:00 auch immer von der DTU .... speist aber
> weiterhin ein und auch die Led blinkt grün.
> Am nächsten Tag kommen wieder Nachrichten und nach 1-2h hören sie auf.

Ich vermute eher, da beginnt jemand sein HomeOffice und DDoSed das wlan 
in Teams. Oder verwendet sonst welche Funk-Gadgets. NRF ist da sehr 
empfindlich. Schon mal die Antenne schief angeschaut? Bei Thomas hat das 
wohl geholfen.
Mein WR hat noch nicht aufgehört mir Daten zu schicken und ich hol da 
echt raus, was geht. Aber über die Eventualität habe ich auch schon 
nachgesacht, dass die loggen und irgendwann ihren Flash kaputt 
schreiben? Wer weiß.

Egal. So lange hab ich ein buntes Leben :D

[Sorbit (Gast)]

Raik E. schrieb:
> Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um
> Warmwasserspeicher.

Bitte etwas konkreter.
Wie regelt Ihr das?

Welche Hardware benötigt man dazu?

[Jan-Jonas S. (janjonas_s)]

Sorbit schrieb:
> Wie regelt Ihr das?

Am Verbraucher:
- Shelly
- Sonoff

HomeAssistant übernimmt dabei die Logik, Verbraucher bedarfsgereicht 
ein-/abzuschalten.

Am Wechselrichter garnicht. Wir wissen ja noch nicht wie... Aber bei 600 
Wp habe ich auch nur sehr kurz, sehr wenig, wenn überhaupt Überchuss. 
Wenn ich Energie über hätte, würde ich ein Miner anschmeißen. Das 
Problem hab ich leider nicht.

> Welche Hardware benötigt man dazu?

Energiemessgerät am Hausanschluss, was schon halbwegs Echtzeitdaten 
liefern kann. Ich hab ein Shelly 3EM und polle dessen http api 
sekündlich. EVU-Meter scheinen dazu nicht geeignet zu sein, liefern zu 
selten Daten. Ferrais-Zähler gehen garnicht.
Dann halt irgendein Logik-Element dazwischen was die Daten vergleicht 
und dann, sobald wir endlich wissen wie man den WR steuert, könnte mein 
HASS jetzt schon per mqtt {topic}/command die Steuer-Payload einwerfen.

[Pintopf (Gast)]

Hallo!

Auch ich habe mir vor einigen Wochen ein Mini-Solarkraftwerk mit 2 Stück 
375W Modulen und einem HM600 Inverter in den Garten gestellt.
Da ich unser Haus mit einer Homematic teilautomatisiert habe, benutze 
ich zur Messung des Ertrags ein Schaltmodul mit Energiezähler, welches 
ich "rückwärts" betreibe.
Zum weiteren Erkenntnisgewinn und aus reinem Spieltrieb habe ich das 
Netz auf der Suche nach einer Möglichkeit durchsucht, an die internen 
Daten des Controllers, ohne Cloudzwang, heranzukommen. Auf dieser Seite 
hier bin ich nun fündig geworden.
Einen ESP8266 hatte ich noch in meiner Basteliste, die NRF-Platine habe 
ich von AZ Delivery. Dort habe ich nur noch einen Elko über die 
Versorgungsspannungs-Pins gelötet, beide Platinchen verdrahtet, das 
Git-Repository geclont, das Projekt in den ESP gebrannt, meine gemachten 
Fehler gesucht und behoben....und nun kann ich meinen Wechselrichter 
auslesen.

Herzlichen Dank an alle Beteiligten, welche dieses tolle Projekt 
realisiert haben und viel Zeit und Mühe dort hineingesteckt haben!

Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge 
(YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic 
gemessenen Werte.
Jetzt habe ich mir mal die RF24 Payload über die serielle Schnittstelle 
ausgeben lassen und nach den fehlenden Daten gesucht. In dem Bild im 
Anhang habe ich den vermeindlichen Fundort markiert.
Könnte jemand von euch das verifizieren?

Was ich auch nicht hinbekomme, ist die MQTT-Verbindung. Ich habe mir auf 
der Homematic mit Mosquitto und Node-Red einen Broker gebaut, mit dem 
sich der ESP laut Statusmeldung auch connectet, aber ich bekomme keine 
Daten heraus.
Allerdings bin ich auch totaler MQTT-Anfänger, der Fehler liegt 
sicherlich irgendwo in meiner Konfiguration versteckt.

Vielen Dank noch einmal für die hervorragende Arbeit!
Peter

[Peter L. (leliep)]

Pintopf schrieb:
> Was ich auch nicht hinbekomme, ist die MQTT-Verbindung. Ich habe mir auf
> der Homematic mit Mosquitto und Node-Red einen Broker gebaut, mit dem
> sich der ESP laut Statusmeldung auch connectet, aber ich bekomme keine
> Daten heraus.
> Allerdings bin ich auch totaler MQTT-Anfänger, der Fehler liegt
> sicherlich irgendwo in meiner Konfiguration versteckt.
>
> Vielen Dank noch einmal für die hervorragende Arbeit!
> Peter

Versuch doch mal, einen MQTT-Client wie z.B. MQTT Inspector (iPad) zu 
verwenden, um die Daten des MQTT-Brokers auszulesen. Nach meiner 
Erfahrung hilft das sehr dabei, zu erkennen, welche Namen Deine Werte im 
Broker haben.

Von der Kommandozeile gehts auch mit: mosquitto_sub -u <user> -P <passw> 
-v -t +/#

Dann siehst Du, was rauskommt von dem, was Du reinschickst…

[rosch99 (Gast)]

Pintopf schrieb:
> Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge
> (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic
> gemessenen Werte.

Die beiden Channels (PV-Module) zusammengezählt ergeben doch 45kWh wie 
gemessen, das passt doch eh.

@MQTT kontrolliere genau die / in den jeweiligen Topics, oft hakt es 
daran ;-)

[pintopf (Gast)]

Ich habe schon einen MQTT-Sniffer laufen, der findet auch mein 
selbsdefiniertes Topic nebst Inhalt, was mir sagt, dass der Broker auf 
der CCU3 wohl läuft.(Screenshot)
Muss ich den Inhalt des vom ESP gesendeten Topics vielleicht irgendwo 
selbst definieren? Steht da zur Zeit nur nichts drin?
Wenn nein, welche Meldungen werden übermittelt? Als String?

Viele Grüße,
Peter

[pintopf (Gast)]

rosch99 schrieb:
> Die beiden Channels (PV-Module) zusammengezählt ergeben doch 45kWh wie
> gemessen, das passt doch eh.

Das ist wohl war, jedoch wird auf der vom ESP generierten Webseite nur 
der Wert des zweiten Channels als Gesamt-Energiemenge angezeigt.

Da stand beim meiner obigen Messung eben 23,3 kWh Gesamtertrag.


Gruß, Peter

[Jan-Jonas S. (janjonas_s)]

Hi,

neues von 0x11 und 0x12 Requests. Siehe Logfile. Sieht wohl so aus, als 
währe ich da auf der richtigen Fährte. Die a_text's sind die a_codes aus 
der DTU-Modbus und User manual [1]. a_code 1 und 2 sind geraten. Sonst 
ist noch ne Menge unbekannt. Bei der Uptime bin ich mir auch 
unschlüssig. Ginge um ne Stunde falsch und scheint irgendwann 
übergelaufen zu sein? Aber mit long statt short dekodieren gibt an der 
Stelle keinen sinnvollen Output.

Wo ist der Unterschied zwischen 0x11 und 0x12? Glaube die Art des 
Fehlers.
0x11 scheint ein allgemeines Log zu sein, 0x12 Grid related?

[1] 
https://www.hoymiles.com/wp-content/uploads/2021/11/User-manual_HMS-160018002000-4T-NA_EN_V202201.pdf
--
Gruß,
Jan

[Thomas B. (tbnobody)]

Konnte Jans Erkenntnis bzgl. 0x80 0x11 nachvollziehen.
mit seinem letzten Source bekommt man folgendes dekodiert:

2022-05-11 19:17:29.045241 Payload: 00 01 80 01 00 06 30 62 30 62 00 00 00 00 00 d4 00 07 30 6a 00 00 00 00 00 00 b0 02 00 48 4c f7 4c f7 00 00 00 05 b0 02 00 49 55 da 55 da ff ff ff fb b0 02 00 4a 55 ed 55 ed 00 00 00 05 b0 02 00 4b 56 72 56 72 ff ff ff fb b0 02 00 4c 56 72 56 72 00 00 00 06 b0 02 00 4d 56 79 56 79 ff ff ff fb b0 02 00 4e 56 82 56 82 00 00 00 05 b0 02 00 4f 56 e7 56 e7 ff ff ff fb b0 02 00 50 56 f3 56 f3 00 00 00 05 b0 02 00 51 57 1d 57 1d ff ff ff fb b0 02 00 52 57 23 57 23 00 00 00 05 b0 02 00 53 57 4f 57 4f ff ff ff fb b0 02 00 54 57 51 57 51 00 00 00 05 05 ab
 payload has valid modbus crc
80 01 00 06 30 62 30 62 00 00 00 00:
 uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0)
00 d4 00 07 30 6a 00 00 00 00 00 00:
 uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input
 BBHHHHH: (0, 212, 7, 12394, 0, 0, 0)
b0 02 00 48 4c f7 4c f7 00 00 00 05:
 uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5)
b0 02 00 49 55 da 55 da ff ff ff fb:
 uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531)
b0 02 00 4a 55 ed 55 ed 00 00 00 05:
 uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5)
b0 02 00 4b 56 72 56 72 ff ff ff fb:
 uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531)
b0 02 00 4c 56 72 56 72 00 00 00 06:
 uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6)
b0 02 00 4d 56 79 56 79 ff ff ff fb:
 uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531)
b0 02 00 4e 56 82 56 82 00 00 00 05:
 uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5)
b0 02 00 4f 56 e7 56 e7 ff ff ff fb:
 uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531)
b0 02 00 50 56 f3 56 f3 00 00 00 05:
 uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5)
b0 02 00 51 57 1d 57 1d ff ff ff fb:
 uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531)
b0 02 00 52 57 23 57 23 00 00 00 05:
 uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5)
b0 02 00 53 57 4f 57 4f ff ff ff fb:
 uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531)
b0 02 00 54 57 51 57 51 00 00 00 05:
 uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5)

Bei 0x80 0x12 schaut kommt

2022-05-11 19:09:10.888401 Transmit 27 | 15 71 60 35 46 78 56 34 12 80 12 00 62 7b fb c4 00 00 00 00 00 00 00 00 52 59 c0
2022-05-11 19:09:10.951495 Received 27 bytes channel 3: 95 71 60 35 46 71 60 35 46 81 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb 36
2022-05-11 19:09:11.454623 Payload: 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb
 payload has valid modbus crc
00 d4 00 07 30 6a 00 00 00 00 00 00:
 uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input
 BBHHHHH: (0, 212, 7, 12394, 0, 0, 0)

Ich hätte das so interpretiert, dass 0x11 ein allgemeines Log ist und 
0x12 nur kritische Dinge anzeigt. Aber ist nur eine vermutung.

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
> Hi,
>
> neues von 0x11 und 0x12 Requests. Siehe Logfile. Sieht wohl so aus, als

Hallo Jan, 0x11 habe ich seit Mittag am Laufen für 350 + 400. Hab aber 
noch keine Zeit gehabt, mir das anzuschauen. Hab nur gesehen, das einer 
schon bei den Antworten bei ..8C... angekommen ist, so auf die Schnelle. 
"C" wären ja 12 Payloads zum zusammensetzen ?

[rosch99 (Gast)]

pintopf schrieb:
> Muss ich den Inhalt des vom ESP gesendeten Topics vielleicht irgendwo
> selbst definieren? Steht da zur Zeit nur nichts drin?
> Wenn nein, welche Meldungen werden übermittelt? Als String?

Ok, du verwendest NodeRed, damit ist es einfach.
Versuch mal /inverter/# zu subscriben und einen debug node dranzuhängen, 
das  # entspricht im MQTT einem *. Du bekommst dann alle Topics und 
Werte als String im debug fenster und kannst dir die passenden 
raussuchen.

Ich schicke es dann in einen change node und mache aus dem string eine 
number und anschliessend noch einen smooth node zum runden der Werte.
Kann man natürlich auch mit einem function node lösen.

[Raik E. (raik85)]

Sorbit schrieb:
> Raik E. schrieb:
>> Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um
>> Warmwasserspeicher.
>
> Bitte etwas konkreter.
> Wie regelt Ihr das?
>
> Welche Hardware benötigt man dazu?
Ein wenig Off-topic:

Ich habe in meiner Unterverteilung direkt hinter dem Hauptzähler ein 
Eastron SDM72M installieren lassen, dieser wird mittels einem ESP32 
ausgelesen und übermittelt den Verbrauch/Einspeisung wattgenau an einen 
Thyristor Leistungssteller (Schwingungspaketsteuerung) an dem dann ein 
Heizstab im Warmwasserspeicher hängt.

Auf diese weise kann ich den Heizstab genau steuern (dimmen) und so fast 
jedes erzeugte Watt nutzen.

[Heinz R. (heijz)]

Raik E. schrieb:
> Ich habe in meiner Unterverteilung direkt hinter dem Hauptzähler ein
> Eastron SDM72M installieren lassen, dieser wird mittels einem ESP32
> ausgelesen und übermittelt den Verbrauch/Einspeisung wattgenau an einen
> Thyristor Leistungssteller (Schwingungspaketsteuerung) an dem dann ein
> Heizstab im Warmwasserspeicher hängt.

sorry, falsches Topic, bitte kapere nicht den Thread
Mach gerne einen Neuen auf - genau das was Du hier beschreibst - 
Schwingungspaketsteuerung - funktioniert nämlich so überhaupt nicht

[isnoAhoy (Gast)]

Hallo Jan-Jonas,

das sieht ja schon sehr vielversprechend aus mit den Logfiles vom 
Hoymiles WR!

Ich habe zwar noch nicht nachvollziehen können wie man auf die uptime 
Werte kommt, aber dazu muß ich wohl mal in den Python code schauen. Und 
für a_count und opcode existiert bisher noch keine Erklärung. Aber Deine 
Erklärung und Übersetzung von a_code erscheint mir plausibel. Das könnte 
man ggf. auch mal mit einem Schaltnetzteil am Eingang nachprüfen, indem 
man z.B. die Über- und Unterspannungsfehler 215..222 provoziert.

>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1
> Guter Fund!

Das ist ja in einem 0x80 Request (hier 0x0B) Zeitsetzen und Status 
abfragen.

Kann man bei den beiden Statuslog 0x11 und Errolog 0x12 Requests evtl. 
darüber einen Offset mitgeben, damit man nur die letzten X-Meldungen 
geschickt bekommt ?

[Jan-Jonas S. (janjonas_s)]

isnoAhoy schrieb:
> noch nicht nachvollziehen können wie man auf die uptime
> Werte kommt

ich bin mir auch unsicher. Hab lange probiert das mit unterschiedlichen 
typen-mappings zu dekodieren und Muster zu erkennen. Hab ja selber auch 
0 Dokumentation dazu, was ich da überhaupt erwarten könnte. Hab ja auch 
keine S-Cloud oder DTU zum probieren. Glaube dann währe das Protokoll 
schon fertig analysiert. :D
> für a_count und opcode existiert bisher noch keine Erklärung.

a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass 
das letzte byte payload[40:42] in der 800b response den aktuellen 
Zählerstand angibt. So kann die DTU ein 8011 initiieren, wenn er 
incrementiert um den neuen Log-Eintrag abzurufen. Würde Sinn machen, 
muss ich aber noch genauer beobachten. Das es den Zählerstand irgendwie 
gibt steht in der DTU-Pro Modbus Tech-Note [1] und der Manual von den 
jeweiligen Invertern drin.

> Erklärung und Übersetzung von a_code erscheint mir plausibel.

Zufallsfund.

> man ggf. auch mal mit einem Schaltnetzteil am Eingang nachprüfen, indem
> man z.B. die Über- und Unterspannungsfehler 215..222 provoziert.

Freiwillige vor :D

>>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
>>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
>>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1
>> Guter Fund!

Stehen die Schaltaktionen im 8011 Log? Ist die Zahl vielleicht ein 
message ack von der DTU?

> Das ist ja in einem 0x80 Request (hier 0x0B) Zeitsetzen und Status
> abfragen.

Ich würde generell sagen Poll. "Zeit setzen" scheint bei vielen (allen?) 
Commands außer re-transmit mit dabei zu sein. Weil ich vermute, dass der 
WR keine RTC besitzt, sondern die Zeit mit jedem Kommando mit bekommt.

> Kann man bei den beiden Statuslog 0x11 und Errolog 0x12 Requests evtl.
> darüber einen Offset mitgeben, damit man nur die letzten X-Meldungen
> geschickt bekommt ?

Gibt nix gutes, außer man tut es. :)

Müsste man mal mehr Mitschnitte von einer DTU haben um die Bedeutung der 
bytes hinter der Zeit zu erraten. Weil die 18 byte zu brute-forcen, wenn 
man nichtmal weiß wonach man sucht, ist aussichtslos. VOr allem über die 
Zeit mal so beobachten, was die da noch so kommuniziert.
Vor allem währe interessant, ob die modbus-Abfragen direkt an den WR 
durchgereicht werden oder aus dem DTU cache kommen. Wenn die direkt 
durch gehen dürfte es sehr leicht sein das nach zu bauen. Zudem hätte 
man Referenzwerte, dass man wenigstens weiß wonach man in den riesen 
random dekodierten Zahlenhaufen ausschau halten muss.

Gurß,
Jan

[1] 
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

[Pintopf (Gast)]

rosch99 schrieb:
> Ok, du verwendest NodeRed, damit ist es einfach.
> Versuch mal /inverter/# zu subscriben und einen debug node dranzuhängen,
> das  # entspricht im MQTT einem *. Du bekommst dann alle Topics und
> Werte als String im debug fenster und kannst dir die passenden
> raussuchen.

Hallo Rosch, genauso habe ich es jetzt gemacht, mein MQTT Sniffer zeigt 
jetzt auch alle Daten an.


Ich fand hier:
https://www.hivemq.com/mqtt-essentials/
die entscheidenden Hinweise.
Allerdings steht dort auch, dass der Slash (/) nicht an erster Stelle im 
Topic stehen sollte.

Allerdings werden die Daten sekündlich aktualisiert, der Parameter auf 
dem Web-UI hat bei mir auf die Aktualisierungsrate keinen Einfluss.

Viele Grüße,
Peter

[Jan-Jonas S. (janjonas_s)]

Jan-Jonas S. schrieb:
> a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass
> das letzte byte payload[40:42] in der 800b response den aktuellen
> Zählerstand angibt

Confirmed

2022-05-12 08:56:31.787164 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 11 00 62 7c af 9c 00 00 00 00 00 00 00 00 72 99 58
2022-05-12 08:56:31.847991 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 00 01 80 01 00 06 31 e3 31 e3 00 00 00 00 80 02 90
2022-05-12 08:56:31.883198 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 00 07 3b 9c 3b 9c ff ff ff fa 80 02 00 08 3b 9c b8
2022-05-12 08:56:31.917849 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 3b 9c 00 00 00 06 80 02 00 09 60 b1 60 b1 ff ff bc
2022-05-12 08:56:31.987761 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 ff fb 80 02 00 0a 60 c2 60 c2 00 00 00 05 80 02 9a
2022-05-12 08:56:32.028280 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 00 0b 60 d9 60 d9 ff ff ff fb 80 02 00 0c 60 dd ac
2022-05-12 08:56:32.092314 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 60 dd 00 00 00 05 80 02 00 0d 61 79 61 79 ff ff a4
2022-05-12 08:56:32.132800 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 87 ff fb 80 02 00 0e 61 81 61 81 00 00 00 05 cd 30 62
2022-05-12 08:56:32.637981 Payload: 00 01 80 01 00 06 31 e3 31 e3 00 00 00 00 80 02 00 07 3b 9c 3b 9c ff ff ff fa 80 02 00 08 3b 9c 3b 9c 00 00 00 06 80 02 00 09 60 b1 60 b1 ff ff ff fb 80 02 00 0a 60 c2 60 c2 00 00 00 05 80 02 00 0b 60 d9 60 d9 ff ff ff fb 80 02 00 0c 60 dd 60 dd 00 00 00 05 80 02 00 0d 61 79 61 79 ff ff ff fb 80 02 00 0e 61 81 61 81 00 00 00 05 cd 30
 payload has valid modbus crc
80 01 00 06 31 e3 31 e3 00 00 00 00: 
 uptime=3:32:51 a_count=6 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 6, 12771, 12771, 0, 0)
80 02 00 07 3b 9c 3b 9c ff ff ff fa: 
 uptime=4:14:20 a_count=7 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 7, 15260, 15260, 65535, 65530)
80 02 00 08 3b 9c 3b 9c 00 00 00 06: 
 uptime=4:14:20 a_count=8 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 8, 15260, 15260, 0, 6)
80 02 00 09 60 b1 60 b1 ff ff ff fb: 
 uptime=6:52:33 a_count=9 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 9, 24753, 24753, 65535, 65531)
80 02 00 0a 60 c2 60 c2 00 00 00 05: 
 uptime=6:52:50 a_count=10 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 10, 24770, 24770, 0, 5)
80 02 00 0b 60 d9 60 d9 ff ff ff fb: 
 uptime=6:53:13 a_count=11 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 11, 24793, 24793, 65535, 65531)
80 02 00 0c 60 dd 60 dd 00 00 00 05: 
 uptime=6:53:17 a_count=12 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 12, 24797, 24797, 0, 5)
80 02 00 0d 61 79 61 79 ff ff ff fb: 
 uptime=6:55:53 a_count=13 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 13, 24953, 24953, 65535, 65531)
80 02 00 0e 61 81 61 81 00 00 00 05: 
 uptime=6:56:01 a_count=14 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 14, 24961, 24961, 0, 5)
2022-05-12 08:56:32.645194 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 12 00 62 7c af 9c 00 00 00 00 00 00 00 00 71 9a 5b
2022-05-12 08:56:32.702398 Received 15 bytes channel 75: 95 72 22 01 43 72 22 01 43 81 00 01 70 c0 a5
2022-05-12 08:56:33.204835 Payload: 00 01 70 c0
 payload has valid modbus crc
Poll inverter 114172220143
2022-05-12 08:56:33.206615 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 7c af a1 00 00 00 05 00 00 00 00 39 42 ea
2022-05-12 08:56:33.258071 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 8c
2022-05-12 08:56:33.293355 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 ec
2022-05-12 08:56:33.363660 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 03 00 a1 03 e8 01 6c 00 0f 42 e7 98
2022-05-12 08:56:33.866489 Payload: 00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 00 03 00 a1 03 e8 01 6c 00 0f 42 e7
2022-05-12 08:56:33.866489 Decoded: 36.4 phase0=voltage:229.1, current:16.1, power:369.6, frequency:49.99 string0=voltage:32.2, current:5.98, power:192.7, total:49.378, daily:211 string1=voltage:32.4, current:6.01, power:194.3, total:47.099, daily:215

wobei

~ # python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.unpack('>HHHHHHLLHHHHHHHHHHH', bytes.fromhex('00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 00 03 00 a1 03 e8 01 6c 00 0f 42 e7')[:42])
(1, 322, 598, 1927, 324, 601, 127336448, 3236036608, 47099, 211, 215, 2291, 4999, 3696, 3, 161, 1000, 364, 15)

Oben sind doch erst 14 Fehler im Speicher? Richtig. Dazwischen ist aber 
noch der 8012-Request (leer). Der setzt einen zusätzlichen Fehler (code 
2). 15.

Gruß,
Jan

[rosch99 (Gast)]

Pintopf schrieb:
> Ich fand hier:
> https://www.hivemq.com/mqtt-essentials/
> die entscheidenden Hinweise.
> Allerdings steht dort auch, dass der Slash (/) nicht an erster Stelle im
> Topic stehen sollte.

Ja, im Gegensatz zu filesystemen ist das bei MQTT nicht üblich.
Dazu muss aber der Default-Eintrag in der setup page geändert werden, 
ich habe das bei mir angepasst. Ebenso sollte am Ende kein / stehen, das 
wird aut. angehängt. Ich habe das auch erst mit dem Sniffer bemerkt weil 
nix "angekommen" ist ;-)

[Hubi (Gast)]

Hallo zusammen
ich logge nun seit mehreren Wochen die Werte meines HM-600 alle 5 
Minuten pro Tag mit. Wenn ich mir die Tagesendezahlen ansehe fällt mir 
folgendes auf:
1) Ertrag Woche steigt permanent an; das sollte doch eigentlich immer in 
etwa gleich sein.
2) Die Differenz von 2 Tagen Ertrag Woche und 2 Tagen Ertrag gesamt 
passt nie.
3) die Differenz Tagesanfang zu Tagesende von Ertrag Woche und Ertrag 
Gesamt sollte doch gleich sein, aber passt auch nie; da gibt da 
Differenzen bis über 100 Wh.
4) Ertrag Total kann nicht stimmen, denn wenn ich meine Dachanlage von 
3,87 KWp runterrechne auf 0,6 KWp müsste der Gesamtertrag mindestens 
doppelt so hoch sein.

Hat schon jmd ähnliches beobachtet oder sind die beiden Werte was ganz 
anderes?

[Thomas B. (tbnobody)]

Hubi schrieb:
> Hat schon jmd ähnliches beobachtet oder sind die beiden Werte was ganz
> anderes?

Hallo Hubi,

ich gehe davon aus du nutzt die ESP8266 Version aus [1]?

In dieser Version stimmt die Byte Zuordnung vmtl. nicht. Dies hängt auch 
damit zusammen, dass hier wohl noch keine Fragmentübergreifenden 
Datenwerte unterstützt werden (diese kommen laut aktuellem Stand wohl 
nur beim HM-600 vor).

Die Python Version implementiert dies bereits.

Hintergrund ist, dass der Wert der beim HM-600 als Weekly Wert angegeben 
wird in Wahrheit der Total Wert für den 2. Kanal ist. Dieser läuft aber 
ggf. wöchentlich über. Der Überlauf wird in einem anderen Datenfragment 
übertragen (man müsste wie im Python Code alle übertragenen Fragmente 
zusammenfügen und Auswerten)

[1] https://github.com/grindylow/ahoy

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
> Jan-Jonas S. schrieb:
>> a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass

Hallo Jan,
leider kann ich kein py.
So wie ich es verstehe, ergibt sich z.B. bei mir folgender zerlegter 
Block (Hand bearbeitet):

W1   W2   W3   W4   W5   W6
B1 2  3 4  5 6  7 8 9 10 11 12
0001                             Hex    Dez
8001 0006 1698 1698 0000 0000 ; 1698 > 5784 /60 = 96 /60=1:36:xx ;
8002 0007 4F16 4F16 FFFF FFDF ; 4F16 > 20246/60 = 337/60=5:37:xx ;
8002 0008 5CC9 5CC9 FFFF F261 ; 5CC9 > 23753/60 = 395/60=6:35:xx ;F2=242
8002 0009 5D0E 5D0E FFFF FFA7 ; 5D0E > 23822/60 = 397/60=6:37:xx ;
8002 000A 641D 641D FFFF F8F1 ; 641D > 25629/60 = 427/60=7:07:xx ;F8=248
8002 000B 64DE 64DE FFFF FF3F ; 64DE > 25822/60 = 430/60=7:10:xx ;
8002 000C 657D 657D FFFF FF61 ; 657D > 25981/60 = 433/60=7:13:xx ;
8002 000D 6679 6679 FFFF FF18 ; 6679 > 26233/60 = 437/60=7:17:xx ;
8002 000E 754A 754A FFFF F12F ; 754A > 30026/60 = 500/60=8:00:xx ;F1=241
34E7

a) Nur was sollen mir die Worte W1 bis W6 sagen ?
Ich habe gegen 12:41 Uhr mit der Aufzeichnung begonnen.
Der WR arbeitet aber schon sehr viel früher.
Also "Uptime" in der Zeile 8001 mit 1:36:xx kann nicht sein.

b) Welches Wort/Byte (W1 bis W6/B1 bis B12) soll Bitte der Alarmcode 
sein?

[Pintopf (Gast)]

Zu deiner Feststellung:
Hubi schrieb:
> 4) Ertrag Total kann nicht stimmen, denn wenn ich meine Dachanlage von
> 3,87 KWp runterrechne auf 0,6 KWp müsste der Gesamtertrag mindestens
> doppelt so hoch sein.

zitiere ich mich mal selber:

Pintopf schrieb:
> Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge
> (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic
> gemessenen Werte.
> Jetzt habe ich mir mal die RF24 Payload über die serielle Schnittstelle
> ausgeben lassen und nach den fehlenden Daten gesucht. In dem Bild im
> Anhang habe ich den vermeindlichen Fundort markiert.
> Könnte jemand von euch das verifizieren?


Danke für die Mitteilung, dass es bei dir genauso ist.
In meinem Originalbeitrag habe ich auch die Stelle im Datenfeld 
markiert, wo ich den Gesamtertrag des ersten Moduls vermute.


Gruß
Peter

[Jan-Jonas S. (janjonas_s)]

Herbert K. schrieb:
> b) Welches Wort/Byte (W1 bis W6/B1 bis B12) soll Bitte der Alarmcode
> sein?

Hier 
https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py#L310 
ist die zeile, wo ich zuordne.

Lass mich versuchen das ein wenig zu veranschaulichen

opcode, a_code, a_count, uptime, u, u, u = struct.unpack('>BBHHHHH', chunk)

B   B   H      H      H      H      H
00  d4  00 07  30 6a  00 00  00 00  00 00
|   |   |      |
|   |   |      \_ uptime seconds(?) 
|   |   \_ a_count
|   \__ a_code
\_ opcode

Das schöne an python ist, geht auch interaktiv.

Auf der Konsole am Beispiel von Thomas die Payload von "Port 4 no input"

~ # python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.unpack('>BBHHHHH', bytes.fromhex('00 d4 00 07 30 6a 00 00 00 00 00 00'))
(0, 212, 7, 12394, 0, 0, 0)
>>>

Alle Zeilen mit ">>>" sind manuelle Eingaben. So kann man recht fix und 
effektiv an den Payloads rum doktorn. `import struct` macht das Modul 
struct verfügbar.
struct.unpack string '>' endian-big, 'B' sind 2 byte (unsigned char), 
'H' sind 4 byte (unsigned short)

chunk = bytes.fromhex('00 11 22 33 44 55')
wandelt einen schön lesbaren byte string in ein byte array um, mit dem 
struct arbeiten kann.

Gruß,
Jan

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
> Herbert K. schrieb:
...
> B   B   H      H      H      H      H
> 00  d4  00 07  30 6a  00 00  00 00  00 00
> |   |   |      |
> |   |   |      \_ uptime seconds(?)
> |   |   \_ a_count
> |   \__ a_code
> \_ opcode

DANKE Jan !

[Jan-Jonas S. (janjonas_s)]

Noch schöner ist, man kann die Decoder auch so auf der Konsole 
ausprobieren

Im Verzeichnis tools/rpi/ python3 ausführen:

root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hoymiles
>>> hoymiles.decoders.HM1200_Decode11(bytes.fromhex('00 01 80 01 00 06 30 62 30 62 00 00 00 00 00 d4 00 07 30 6a 00 00 00 00 00 00 b0 02 00 48 4c f7 4c f7 00 00 00 05 b0 02 00 49 55 da 55 da ff ff ff fb b0 02 00 4a 55 ed 55 ed 00 00 00 05 b0 02 00 4b 56 72 56 72 ff ff ff fb b0 02 00 4c 56 72 56 72 00 00 00 06 b0 02 00 4d 56 79 56 79 ff ff ff fb b0 02 00 4e 56 82 56 82 00 00 00 05 b0 02 00 4f 56 e7 56 e7 ff ff ff fb b0 02 00 50 56 f3 56 f3 00 00 00 05 b0 02 00 51 57 1d 57 1d ff ff ff fb b0 02 00 52 57 23 57 23 00 00 00 05 b0 02 00 53 57 4f 57 4f ff ff ff fb b0 02 00 54 57 51 57 51 00 00 00 05 05 ab'))
 payload has valid modbus crc
80 01 00 06 30 62 30 62 00 00 00 00: 
 uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0)
00 d4 00 07 30 6a 00 00 00 00 00 00: 
 uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input
 BBHHHHH: (0, 212, 7, 12394, 0, 0, 0)
b0 02 00 48 4c f7 4c f7 00 00 00 05: 
 uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5)
b0 02 00 49 55 da 55 da ff ff ff fb: 
 uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531)
b0 02 00 4a 55 ed 55 ed 00 00 00 05: 
 uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5)
b0 02 00 4b 56 72 56 72 ff ff ff fb: 
 uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531)
b0 02 00 4c 56 72 56 72 00 00 00 06: 
 uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6)
b0 02 00 4d 56 79 56 79 ff ff ff fb: 
 uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531)
b0 02 00 4e 56 82 56 82 00 00 00 05: 
 uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5)
b0 02 00 4f 56 e7 56 e7 ff ff ff fb: 
 uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531)
b0 02 00 50 56 f3 56 f3 00 00 00 05: 
 uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5)
b0 02 00 51 57 1d 57 1d ff ff ff fb: 
 uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531)
b0 02 00 52 57 23 57 23 00 00 00 05: 
 uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5)
b0 02 00 53 57 4f 57 4f ff ff ff fb: 
 uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531)
b0 02 00 54 57 51 57 51 00 00 00 05: 
 uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5)

import hoymiles # läd das Modul hoymiles
# hoymiles.decoders korrespondiert zu hoymiles/decoders/__init__.py
hoymiles.decoders.HM1200_Decode11(bytes payload)

HM1200_Decode11 erwartet als Argument die payload bytes. Die kann man 
sich wieder mit bytes.fromhex() aus dem lesbaren String aus den Logs hin 
konvertieren und mit einer Payload so oft wie man will verschiedene 
Änderungen am Code ausprobieren.

[Siggi U. (sude)]

Moin,
ich habe seit gestern auch einen HM-1500 im Einsatz, es sollen noch ein 
paar weitere folgen.
Ich nutze einen ESP8266 mit dem Funkmodul und der Ahoi-Software.

Das Auslesen und Anzeigen der Werte per Weboberfläche hat auf Anhieb 
geklappt, ich bin begeistert.

Danke an die Community für dieses starke Projekt.

Ich versuche auch meinen Teil beizutragen, falls es irgendwie möglich 
ist.

Im MQTT war mir aufgefallen, dass die Werte trotz Einstellung von 10s 
Intervall im Sekundentakt gesetzt wurden. Ich habe den Wert dann mal 
höher gesetzt, aber nach einiger Zeit war der 1s Intervall wieder da.

In der Datei
\tools\esp8266\app.cpp
sollte es in der Zeile 181 wahrscheinlich

mMqttTicker = 0;

statt

mMqttInterval = 0;

sein, damit klappt es bei mir jedenfalls.
Leider wird mir im Git-Commit die ganze Datei als Änderung angezeigt 
statt nur der einen Zeile, ich versuche zu klären warum und mache dann 
einen PullRequest wenn gewünscht. Aber die kleine Änderung könnte ja 
auch jemand anderes schnell übernehmen.

Gruß, sude

[ST2 (Gast)]

Hallo, erst einmal vielen Dank für die tolle Software, sie funktioniert 
ausgezeichnet mit meinem HM-400.

Nun eine Frage an die Experten:

Ich habe an meinem Smart-Meter bereits einen Energieverbrauchsmanager 
von Iungo (www.iungo.nl) angeschlossen, der kann auch Solaranlagen über 
einen Modbus Energiezähler monitoren, dazu kann mann z.B. einen Standard 
RS485 Modbus/USB Adapter verwenden und ihn in den USB Port vom Iungo 
verbinden. Ich frage mich nun ob ich nicht den Wemos D1 mini in den USB 
Port stöpseln könnte um einen Modbus Energiezähler und USB Adapter zu 
emulieren. Würde das funktionieren und was müsste ich grob dafür 
implementieren?

Vielen Dank für die Hilfe.

Grüße,
Stefan

[Daniel R. (daniel92)]

Hallo zusammen,

ich habe seit heute auch einen HM-1500. =)

Würde hier beim reenginering mit Unterstützen.
Gibt es hier zufällig jemand der auf Github etwas voran getragen hat was 
man alles braucht?

Ich habe bei mir noch mehrere ESP8266 und irgendwo in der schublade 3x 
NRF24LE1E.

Um hier zwecks logging zu helfen, wie wird es miteinander verdrahten und 
auf welcher Basis wird das ganze in das ESP geflasht?

Ich würde mir heute wenn ich dazu komme die App decompilen und mir 
schauen ob man weitere Interessante Infos rausziehen kann.

PS: Wie wäre es mit einem IRC-Chat und/oder Discord, dann könnte man 
doch mal ein Abend damit verbringen sich zusammen das anzuschauen. Was 
sagt ihr dazu?

Beste Grüße.

[Daniel R. (daniel92)]

Hallo,

kleiner Fortschritt (weiß nicht inwieweit das vom Nutzen her hilft):

this.memoizedIsInitialized = (byte) -1;
this.pvSn_ = 0L;
this.pvPort_ = 0;
this.pvVol_ = 0;
this.pvCur_ = 0;
this.pvPower_ = 0;
this.pvEnergyTotal_ = 0;
this.gridVol_ = 0;
this.gridVolMax_ = 0;
this.gridFreq_ = 0;
this.gridP_ = 0;
this.gridQ_ = 0;
this.gridI_ = 0;
this.gridPf_ = 0;
this.pvTemp_ = 0;
this.pvRunStatus_ = 0;
this.pvFaultNum_ = 0;
this.pvFaultCnt_ = 0;
this.pvWarnningCnt_ = 0;
this.pvLinkStatus_ = 0;
this.pvSendP_ = 0;
this.pvRevP_ = 0;
this.pvTime_ = 0;
this.pvEnergy_ = 0;
this.miSignal_ = 0;

So bin später wieder aktiv da.

[isnoAhoy (Gast)]

Hallo Stefan,
das mit dem Modbus Energiezähler der dann an den ESP angeschloßen wird 
klingt interessant. Ob das an dem Modell von Dir so einfach geht kann 
ich nicht sagen, da ich keine Ahnung habe was der für Kommandos über 
Modbus absetzt, oder ob der nur abgefragt werden kann ?
Auf der anderen Seite der ESP8266 mit Ahoy Software ist aktuell auch 
noch nicht so weit, daß er bereits Kommandos an die Hoymiles 
Wechselrichter senden könnte. Wir können m.W. bisher nur lesen, die 
aktuellen Leistungsdaten 0x0B und den Ereignis- 0x11 bzw. Fehlerspeicher 
0x12.
Die Modbus Kommandos, die z.B. die Hoymiles DTU Pro versteht und 
unterstützt kann unsere Software (Python oder ESP) bisher auch noch 
nicht.

Hallo Daniel,
die ESP Verdrahtung ist im Verzeichnis doc/getting-started-ESP8266:

https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Viel Erfolg beim basteln und kompilieren. Was die Liste der Definitionen 
von Dir angeht, hab ich keine Ahnung wie uns das so weiterhelfen soll, 
vielleicht kannst Du noch ein bisschen mehr dazu schreiben. Andererseits 
sind in tools/esp8266/hmDefines.h die entsprechenden Felder der Payloads 
bereits hinterlegt. Lukas arbeitet aktuell daran die Frames/Pakete 
einzeln zu verifizieren und dann die gesamte Payload auf einmal zu 
lesen. Da steht ja auch nochmal eine CRC16/CRC_M Prüfsumme am Ende (0x8y 
Paket).

https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h#L59

[isnoAhoy (Gast)]

Hallo Stefan,
hier ist die Anleitung zum Modbus Adapter Deiner iungo Anlage:
https://www.iungo.nl/images/pdf/handleiding_modbus_16012019.pdf
Die Anleitung habe ich nur auf niederländisch gefunden. Maar meijn 
Nederlands is nit prittig.
Auf dem Titelbild ist ein Eastron SDM630/Modbus V2 abgebildet. Hast Du 
den auch ?

[Daniel R. (daniel92)]

Moin zusammen,

@isnoAhoy: vielen dank für die Info mit der Verdrahtung. Das werde ich 
mir anschauen und das ganze mal in Ruhe Aufbauen. :)

Zu meiner Infos von weiter oben, da gebe ich dir recht und hole noch 
etwas weiter aus.
Ich habe in der Vergangenheit auch bei anderen Programmen reingeneering 
durchgeführt (Haupts. nur C# decompiliert).

Nun da ich kein Programm habe um es mir am PC anzuschauen, habe ich 
einfach die App im Google Appstore angeschaut. Da ich mit Java kaum was 
am Hut habe, ist es für mich hier etwas schwierig passende Infos raus zu 
ziehen.

Die Infos oben ist ein Schnipsel von der App "S-Miles Endbenutzer". - 
Das ist doch die App?

Es bringt denke ich soweit uns an Infos was alles damit ausgelesen 
werden kann. Natürlich fehlen bestimmt weitere Dinge (Volt, Ampere, 
Watt, Blindleistung, Leistungsfaktor (Pf.), ...).

Im Anhang mal ein Screenshot. Ich muss noch schauen wie die App genauer 
Aufgebaut ist.
Oder gibt es ein PC Programm wo man es Runterladen kann? :)

[isnoAhoy (Gast)]

Hallo Daniel,

jetzt hast Du mich neugierig gemacht, ich habe zwei Apps von Hoymiles 
gefunden:
S-Miles Enduser und S-Miles Installer. Welche hast Du denn runtergeladen 
und vor allem wie ? Ich finde keinen Link zum Download auf dem PC.

https://play.google.com/store/apps/developer?id=Hoymiles+Converter+Technology+Co.,+Ltd.&gl=US

Welchen Decompiler hast Du verwendet ? Ich habe meist gute Ergebnisse 
mit jd-gui von Emmanuel Dupuy gehabt. Auch der Support ist Klasse, falls 
mal was nicht geht, so wie Lambda Functions, dann hatte er das innerhalb 
von wenigen Tagen eingebaut!

https://github.com/java-decompiler/jd-gui/

Das Ganze ist dann zwar nur die Mobile App, die mit der DTU kommuniziert 
und vermutlich nicht alles abdeckt, was z.B. die DTU Pro über den Modbus 
einstellen kann, aber es wäre immerhin eine gute Option herauszufinden, 
was die App mit den ersten vier Stellen der Seriennummer macht, bzw. wie 
die Datenpakete von der DTU zur App übertragen werden...

[Sorbit (Gast)]

https://youtu.be/5m5caOjApVw

[J.Rasper (Gast)]

Hallo zusammen. Wenn es nur um das Monitoring des Ertrags geht, waere 
das Shelly Plug hier nuetzlich 
(https://www.gartenkraftwerke.de/c/unsere-pakete/zubehoer). Das Teil 
baut sein eigenes WLAN auf und bietet eine Webseite, von der man dann 
mit z.B. wget die Daten von Interesse auslesen kann. Das habe ich mit 
einem Kostal 10.1 so gemacht und habe z.B. fuer jede volle Stunde den 
Tagesertrag und den Gesamtertrag ueber die Lebensdauer des WR.

Hoffe, das hilft dem einen oder andern.

[Sorbit (Gast)]

Netsgp ?

https://github.com/atc1441/NETSGPClient

[Daniel R. (daniel92)]

Moin,

richtig es existieren zwei Apps. Die Version "Installer" ist für den 
Techniker für großen Anlagen gedacht (leite ich jetzt mal so heraus).

Für den Endbenutzer gibt es die andere App. Diese konnte ich (wie weiter 
oben beschrieben) mit den Zugangsdaten einloggen und Daten auslesen.

Jetzt muss ich hier jedoch sagen, ich weiß natührlich nicht ob die App 
mit einer DTU direkt kommuniziert (hab keine DTU) und/oder ob es mit der 
Cloud sich verbindet. Die Endbenutzer-App funtioniert bei mir 
anscheinend mit der Cloud.

Ich habe die App bei mir Installiert (direkt aus der Google PlayStore) 
und danach mittels einer weiteren App als apk exportiert (App 
Extractor).

Diese apk, habe ich auf meinem PC übertragen und nutze aktuell JADX-GUI 
(https://github.com/skylot/jadx).

Java ist nicht mein Favorit, da muss ich ehrlich sein.
Jedoch gibt es leider meines wissens nach nur die Weboberfläche und die 
Mobile Variante um die Daten auszuwerten.

-----------------------------------------------

Die Apps sind teils obfuskiert (namen von variabeln sind umbenannt). Das 
Tool JADX leistet hier aber soweit ich das einschätzen kann gute Arbeit 
beim deobfuskieren (Tools -> Deobfuskierung).

Die Hauptstruktur ist von der Baumstruktur so:
/com/hoymiles/... da liegen ganze classen, methoden und co ab.
p000 besitzt auch hier Teils Interessante Daten.

Was mich stutzig macht: Wenn man eine globale Textsuche startet (Info: 
Am Anfang wird die ganze APK dann Dekompiliert. Dauert bevor man eine 
Suche starten kann), dann kam mir auch Methoden/Classen entgegen mit dem 
Namen "Miner". Ich dachte erstmal, wird die App als Miner im Hintergrund 
verwendet? O.o - Naja habe das aber nicht weiter beachtet.

Info: Es gibt ein Indiz das auch die Cloud bei Alibaba gehostet wird.
Einerseits da es als Klasse benammt wird und zweitens die hinterlegten 
Domain:

>ping m.hoymiles.com
Ping wird ausgeführt für m.hoymiles.com [119.3.31.20] mit 32 Bytes 
Daten:
Antwort von 119.3.31.20: Bytes=32 Zeit=312ms TTL=37

Die IP-Adresse zeigt nach China 
(https://ipinfo.io/AS55990/119.3.0.0/19-119.3.31.0/25)

Gruß

[Martin P. (mpolak77)]

Also ich würde mir da nicht zuviel versprechen von den Apps .... ich 
denk' mir, die kommunizieren sicher nur der Hoymiles Cloud .....

a) die App funktioniert ja überall, also muss sie mit der Hoymiles Cloud 
in Verbindung stehen

b) was sollte die App mit der DTU direkt zu bereden haben, wenn die 
Cloud bereits alle Funktionen abbildet.

[Daniel R. (daniel92)]

Moin Martin,

ein Stückweit gebe ich dir hier recht. Jedoch können wir uns doch über 
die App Informationen gewinnen, was für Daten übertragen werden können 
und somit später bei der Indentifizierung uns dabei helfen? - Können die 
App auch gern vorerst beiseite legen und erstmal weiter mit der 
Auswertung kümmern. :)

Idee: Hat schon jemand die den WR ausseinander genommen und mittels 
einem LogicAnalyzer kurz vor dem TX die Daten mitgelauscht und 
gleichzeitig beim Empfänger nach dem RX die Daten verglichen?

[isnoAhoy (Gast)]

Hallo Daniel,

bitte lies erstmal die vorangegangenen 4 Seiten dieses Threads, da steht 
nämlich u.a. wie Martin seine DTU zerlegt und genau am RX/TX zwischen 
GD32 MCU und nRF24 Radio die ersten Mitschnitte gemacht hat. Andere 
haben mit einem HackRF Mitschnitte des Funkverkehrs gemacht. Darauf 
basiert auch der aktuelle Code für ESP (Lukas) als auch die noch 
aktuellere Version für Python (Jan-Jonas)

Aktuell fehlen weitere Mitschnitte für Kommandos die die DTU an den 
Wechselrichter sendet, z.B. aktiv/disabled, Limit setzen, Zero Export 
Control, etc. Die alten Hoymiles String-Wechselrichter hießen MI (= 
MicroInverter), daher stammt vielleicht auch das Präfix Mi in den 
Klassen, Methoden und Variablennamen der App ? Aber Ausschließen will 
ich nichts an der Stelle.

@Sorbit,

ja ich habe Aaron (atc1441) schon gefragt was er von den aktuellen 
Versuchen der Hoymiles Inverter hier im Forum hält. Er hat leider keinen 
HM Wechselrichter und kann daher wenig zur Entwicklung beitragen, obwohl 
ihn das Thema BLE speziell mit nRF52 etc. nach wie vor interessiert. 
Wenn jemand will, kann er ihn ja in Hamburg kontaktieren, vielleicht hat 
er ja ein bißchen Zeit neben seinem neuen Job und schaut mal in einen 
Hoymiles Wechselrichter rein.
Ich habe versucht meinen aufzuschrauben bin aber an den 
Kabelzugentlastungen und der Verklebung der Metallplatte gescheitert. Da 
ich meinen auf dem Balkon installieren möchte sollte er auch weiter 
wasserdicht bleiben. Beim "Freundlichen Händler" meines Vertrauens hat 
man mir auch gesagt, dieser hätte bisher keine Rückläufer mit Defekt, 
die man mal aufschrauben könnte.

[Daniel R. (daniel92)]

Ich habe zwar alle Seiten mir angeschaut, aber bin bei den großen 
Mitschnitten via HackRF nicht komplett durchgegangen. ^^

Cool ist es aufjedenfall was ihr schon alles herausgefunden habt.
Da kann ich definitiv euch nur loben!

Die fehlenden Kommandos die die DTU an den Wechselrichter senden, könnte 
man doch nur mit der DTU-Pro version herausbekommen oder?

Dein Ansatz mit dem Präfix kann gut möglich sein.
Ich bin mir am überlegen so ein Pro zu Organisieren, aber aktuell nicht 
ganz einfach.

https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html

PS: Die Login Daten im Shop kann man auch mit der App nutzen, aber das 
wisst ihr bestimmt schon.

[Peter L. (leliep)]

Meine Prototype mit ESP8266 im Gehäuse. Trotz der dichten Packung 
funktioniert die Kommunikation mit dem WR.

[Daniel R. (daniel92)]

Hallo zusammen,

habe nun alles zusammengebaut...
Leider bekomme ich folgende Meldung:

Warn: your settings are not valid! check [IP]/setup
Was ist denn falsch?

Edit: Hat sich erledigt, ich komme drauf und bin alles am Eintragen.
Die Frage, woher bekomme ich die SNr. habe ein 1500.

[Herbert K. (avr-herbi)]

Daniel R. schrieb:
> Die Frage, woher bekomme ich die SNr. habe ein 1500.

Steht auf der glatten Seite / Rückseite auf 2 Aufklebern.

[Daniel R. (daniel92)]

Danke, boa darauf muss man erstmal kommen. Aber stimmt, wenn ich die 
ersten Zeichen hier Suche gibt es überschneidungen. :)

Mercii!

PS: Spannung kommt von meinem Labornetzteil. Solarmodule brauchen noch 
bis sie da sind. :)

Erste Log:

Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 6D AD 39
Solarkraftwerk/ch3/U_DC: 22.000 V
Solarkraftwerk/ch3/I_DC: 0.010 A
Solarkraftwerk/ch3/P_DC: 0.200 W
Solarkraftwerk/ch4/I_DC: 0.050 A
Solarkraftwerk/ch4/P_DC: 1.200 W
Solarkraftwerk/ch0/Temp: 25.100 °
Solarkraftwerk/ch4/U_DC: 22.000 V
0 (0000) 1 (0001) 2 (0002) 2 (0020)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
AP will be closed in 152 seconds
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FA 00 13 AD FC A9
0 (0000) 1 (0001) 1 (0001) 3 (0030)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 6D AD 39
Solarkraftwerk/ch3/U_DC: 22.000 V
Solarkraftwerk/ch3/I_DC: 0.010 A
Solarkraftwerk/ch3/P_DC: 0.200 W
Solarkraftwerk/ch4/I_DC: 0.050 A
Solarkraftwerk/ch4/P_DC: 1.200 W
Solarkraftwerk/ch0/Temp: 25.100 °
Solarkraftwerk/ch4/U_DC: 22.000 V
0 (0000) 1 (0001) 2 (0002) 2 (0020)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
AP will be closed in 142 seconds
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 6D AD 39
0 (0000) 6 (3003) 2 (0020) 2 (0200)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DD 00 
01 00 05 00 02 4C
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 FD B1 B5
Solarkraftwerk/ch3/U_DC: 22.100 V
Solarkraftwerk/ch3/I_DC: 0.010 A
Solarkraftwerk/ch3/P_DC: 0.200 W
Solarkraftwerk/ch4/I_DC: 0.050 A
Solarkraftwerk/ch4/P_DC: 1.200 W
Solarkraftwerk/ch0/Temp: 25.100 °
Solarkraftwerk/ch4/U_DC: 22.100 V
0 (0000) 5 (2003) 3 (0030) 2 (0200)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
AP will be closed in 132 seconds
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
F9 00 13 AD 0C 5A

[Socke (Gast)]

“Danke, boa darauf muss man erstmal kommen.”

Handbuch lesen sollte wohl möglich sein;-(
Auch mit Schreib- und Leseschwäche…

[isnoAhoy (Gast)]

Hallo Daniel,

wo Du doch schon den Source Code der App decompiliert hast. Wir haben 
eine Liste mit Status / alarm_codes von den Wechselrichtern. Kannst Du 
mal schauen ob Du die auch irgendwo im App Code findest ?

https://github.com/Sprinterfreak/ahoy/commit/e473583a5536b4f8ffb7099d3510912db84928a1

[Daniel R. (daniel92)]

Hallo Ahoy,

ich schau mal fix drauf. Rest mach ich morgen. :)
Wenn ich gleich noch was finde, gebe ich eine Rückmeldung.

Gibt es die möglichkeit die Logs irgendwo gesammelt zusammen zu tragen?
Vielleicht können auch andere Infos herauslesen die Interessant sind, 
was denkt ihr?

Edit: --------------------------------

Folgendes konnte ich auf anhieb finden (code gekürzt):

private APPDtuInfoMO(CodedInputStream input, ExtensionRegistryLite 
extensionRegistry) throws InvalidProtocolBufferException {
            this();
            boolean z = false;
            while (!z) {
                try {
                    try {
                        int readTag = input.readTag();
                        switch (readTag) {
                            case 0:
                                break;
                            case 8:
                                this.deviceKind_ = input.readInt32();
                                continue;
                            case 16:
                                this.dtuSw_ = input.readInt32();
                                continue;
                            case 24:
                                this.dtuHw_ = input.readInt32();
                                continue;
                            case 32:
                                this.dtuStepTime_ = input.readInt32();
                                continue;
                            case 40:
                                this.dtuRfHw_ = input.readInt32();
                                continue;
                            case 48:
                                this.dtuRfSw_ = input.readInt32();
                                continue;
                            case 56:
                                this.accessModel_ = input.readInt32();
                                continue;
                            case 64:
                                this.communicationTime_ = 
input.readInt32();
                                continue;
                            case 72:
                                this.signalStrength_ = 
input.readInt32();
                                continue;
                            case 82:
                                this.gprsVsn_ = input.readBytes();
                                continue;
                            case 90:
                                this.wifiVsn_ = input.readBytes();
                                continue;
                            case 98:
                                this.kaNub_ = input.readBytes();
                                continue;
                            case 104:
                                this.dtuRuleId_ = input.readInt32();
                                continue;
                            case 112:
                                this.dtuErrorCode_ = input.readInt32();
                                continue;
                            case 120:
                                this.dtu485Mode_ = input.readInt32();
                                continue;
                            case 128:
                                this.dtu485Addr_ = input.readInt32();
                                continue;
                            case 136:
                                this.sub1GFqband_ = input.readInt32();
                                continue;
                            case 144:
                                this.sub1GChtnum_ = input.readInt32();
                                continue;
                            case 152:
                                this.sub1GChnum_ = input.readInt32();
                                continue;
                            case Opcodes.IF_ICMPNE /* 160 */:
                                this.sub1GRp_ = input.readInt32();
                                continue;
                            case 168:
                                this.sub1GChtotal_ = input.readInt32();
                                continue;
                            case Opcodes.GETSTATIC /* 178 */:
                                this.gprsImei_ = input.readBytes();
                                continue;
                            default:
                                if (!input.skipField(readTag)) {
                                    break;
                                } else {
                                    continue;
                                }
                        }
                        z = true;
                    } catch (InvalidProtocolBufferException e) {
                        throw e.setUnfinishedMessage(this);
                    } catch (IOException e2) {
                        throw new 
InvalidProtocolBufferException(e2).setUnfinishedMessage(this);
                    }
                } finally {
                    makeExtensionsImmutable();
                }
            }
        }

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> Erste Log:
>
> Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00
> 01 00 05 00 02 4D
> Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 9A
> Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00
> FB 00 13 6D AD 39

Die Payload währe:
( 16 byte fehlen ) 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 FB 00 13 6D AD

Wobei 6D AD die Modbus CRC ist. Natürlich falsch, weil die Payload nicht 
vollständig ist. Irgendwie fehlt da immer das erste Fragment. Aus den 
Logs lassen sich so keine korrekten Daten lesen.

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> Gibt es die möglichkeit die Logs irgendwo gesammelt zusammen zu tragen?

Gute Idee.

Man müsste sich dann noch auf das Format einigen.
Den Output, wie es das python-script macht kann ich jederzeit wieder 
parsen.

Zeilen mit
- "Transmit" beginnen eine Transaktion oder sind ein Re-Transmit
- "Received" werden als Fragment gelesen und der zuvor gestarteten 
Transaktion appended
- "Payload" (mit crc) werden statt den Received-Fragmenten anhand der 
Transmit-Payload direkt dekodiert

gefolgt von den byte hexlified rohdaten dahinter.

> private APPDtuInfoMO(CodedInputStream input, ExtensionRegistryLite
> ...

sieht sehr nach den technischen Daten der DTU aus und ist damit eher 
uninteressant. Wir wollen ja den WR und nicht die DTU abfragen.

Trotzdem währe es aber interessant ob die App Rohdaten über die DTU zum 
WR senden kann. Wenn es also irgendwelche tx payloads gäbe könnte man 
das mal an die WR senden und gucken was passiert.

Gruß,
Jan

[isnoAhoy (Gast)]

Hallo Lukas P.,
kannst Du den Feature Request noch aufnehmen, d.h. die Daten mit 
Transmit und Received per Serial (ggf. auch WebSerial oder MQTT o.a.) 
im "Unified Format" mitzuloggen, damit man die Daten auch mit dem Python 
Code nachverarbeiten könnte ?
Es gibt zwar ein paar Zeilen, die bereits die "sent packet: #" und "RAW 
/ CMD" im entsprechenden Format ausgeben.
Diese sind jedoch meist inaktiv und ich muss die immer von Hand 
einschalten vor dem Kompilieren, damit ich die Rohdaten sehe.

Transmit
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L239-L240
Received
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L142-L151

Bzgl. der blauen LED auf dem NodeMCU / Wemos D1 mini ist es evtl. keine 
so gute Idee gewesen den Anschluss D4 (GPIO2) für CE des nRF24 Moduls zu 
verwenden. Sobald CE low wird leuchtet die blaue LED. Das passiert wohl 
auch im Falle eines TX per Serial IO.

Soll ich die Fritzing Layouts nochmal anpassen und gibt es eine 
empfohlene Verdrahtung, bzw. sollten noch andere GPIOs evtl. nicht / 
anders verwendet werden ?

https://www.computerhilfen.de/info/esp8266-blaue-led-ausschalten-oder-blinken-lassen.html

Aktuell ist die Belegung in der getting started ESP8266 Dokumentation:

https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Wire Connections

    +-----------+          +-----------+
    |  ESP8266  |--colour--| nRF24L01+ |
    |           |          |           |
    |       GND |---black--|[GND]      |
    |     +3.3V |----red---| VCC       |
    |        D4 |---grey---| CE        |
    |        D8 |--purple--| CSN       |
    |        D5 |---blue---| SCK       |
    |        D7 |---green--| MOSI      |
    |        D6 |---brown--| MISO      |
    |        D3 |--yellow--| IRQ       |
    +-----------+          +-----------+

[Daniel R. (daniel92)]

Also cool wäre es, wenn man in das Webinterface von ESP drauf 
zugreift... das man dort aktzeptiert die Logs irgendwo gesammelt 
hochzuladen.
Dann könnte man mittels Datenbank, das ganze super analysieren.

Problem nur: Datenschutz... aber die meisten, die das Projekt 
Unterstützen wollen würden das Freiwilig ja machen. :) Mich 
eingeschlossen.

Habe ich richtig gelesen, du betreibst das NRF24L01+ direkt am Raspi?
Würde ich dann nähmlich bei mir auch umbauen und direkt alles auf dem Pi 
ablegen und verwalten. Aktuell habe ich alles auf einem Breadboard am 
Tisch.

Wenn ich heute Zuhause bin, kann ich mal weiter decompilen und schauen 
ob ich was finde.

Nachtrag: Gern kann ich zusätzlich später mit meinem gebastelten DVB-T 
mal die Frequenzen anschauen, ob sich da was auffäliges verhält. Bzgl. 
Channel Hopping oder ob vlt sogar auf mehrere Kanälen gleichzeitig 
gefunkt wird? (nur eine Mutmassung)

[David (Gast)]

Hallo Zusammen,
ist das RF module von Kuman nRF24L01+PA+LNA ist dafür auch zu nutzen?
Gruss
david

[Daniel R. (daniel92)]

Hallo David,

sollte soweit ich weiß auch gehen. Die Endungen sagen soweit ich weiß 
nur aus das es mit einer extra Antenne versehen ist, statt einer auf dem 
PCB.

Korrigiert mich wenn ich falsch liege. :)

[David B. (mystisch)]

Hallo Daniel,

gut danke Dir. Im Moment bekomme ich keine Verbindung zum Inverter, 
nicht dass ich weiter den Fehler suche und dabei ist das RF Modul das 
Falsche ;)

Grad war ich irgendwie nicht angemeldet.

david

[Daniel R. (daniel92)]

Wie verwendest du es denn?
Arduino, ESP, Raspberry Pi,... ?

Im falle vom ESP (wie ich) und du alles schon geflasht hast, musst du 
mit einem Endgerät mit WLAN dich darauf verbinden und kannst die WLAN 
Daten und co anpassen...

Das schafst du schon. :)

An die Experten, was könnte das bedeuten (gestern stand missing, statt 
all):

das hier > 2 (0002) 3 (0003) 2 (0002) 3 (0030)  -> all
Payload 95 74 40 33 29 74 40 33 29 01 00 01 00 00 00 01 00 01 00 00 00 
00 00 00 00 00 95
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 
01 00 03 00 02 BA
Payload 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 9F
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
DC 00 09 BB 71 0E
das hier > 2 (0002) 3 (0003) 1 (0010) 3 (0030)  -> all
Payload 95 74 40 33 29 74 40 33 29 01 00 01 00 00 00 01 00 01 00 00 00 
00 00 00 00 00 95
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 
01 00 03 00 02 BA
Payload 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 9F
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
DC 00 09 BB 71 0E

[David B. (mystisch)]

Habe ein ESP-8266, darauf läuft die Ahoy Version 0.4.0.
Noch kommt kein Bit vom Inverter ...
Das denke ich auch, dass ich es hinbekomme ;) werde

[Lukas P. (lumapu)]

Das sieht doch super aus, du bekommst Daten vom WR. Ich würde empfehlen, 
die ganz aktuelle Version 0.4.1 zu verwenden, die jetzt wie die Python 
Version die gesamte Payload sammelt + prüft und erst dann 
weiterverarbeitet.

[Daniel R. (daniel92)]

Hab mal was angehängt, könnte das eine heiße Spur sein?

Ich habe noch die 0.3.9, OTA Update wird wie gemacht?
Möchte keine EInstellung verlieren.^^

Hat sich erledigt, selbst gefunden. :P

[David B. (mystisch)]

Problem:
inverter type can't be detected!

In der Beschreibung ist angegeben, dass man den Inverter Typ angeben 
muss. Ist damit das Feld Name unter dem Adress gemeint?
dort hab ich MI-600 eingetragen, adresse startet mit 1041...

[Daniel R. (daniel92)]

So ich habe es nun auch geupdated auf 0.4.1. Danke :)

Man muss den Typ nicht mehr Eintragen.
@lumapu: Gebe dir hierfür recht, der 1500 hat nur zwei Spannungen und 4 
Ströme. - https://github.com/grindylow/ahoy/issues/38

Inverter #0 no Payload received!
Requesting Inverter SN xxxxxxxxxxx (ersetzt)
Transmit 27 | 15 74 40 33 29 78 56 34 12 80 0B 00 62 83 DE 4B 00 00 00 
05 00 00 00 00 A4 95 F8
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Error while retrieving data: Frame 1 missing: Request Retransmit
Transmit 11 | 15 74 40 33 29 78 56 34 12 81 B2
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Payload (62): 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 01 2C 00 01 00 03 00 02 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A
Balkonkraftwerk/ch1/U_DC: 0.200 V
Balkonkraftwerk/ch1/I_DC: 0.010 A
Balkonkraftwerk/ch2/U_DC: 0.200 V
Balkonkraftwerk/ch2/I_DC: 0.010 A
Balkonkraftwerk/ch3/U_DC: 30.000 V
Balkonkraftwerk/ch3/I_DC: 0.010 A
Balkonkraftwerk/ch3/P_DC: 0.200 W
Balkonkraftwerk/ch4/U_DC: 30.000 V
Balkonkraftwerk/ch4/I_DC: 0.030 A
Balkonkraftwerk/ch4/P_DC: 0.800 W
Balkonkraftwerk/ch4/YieldTota: 0.001 kWh
Balkonkraftwerk/ch0/Temp: 23.100 °
Balkonkraftwerk/ch0/YieldTota: 0.001 kWh
Transmit 27 | 15 74 40 33 29 78 56 34 12 80 0B 00 62 83 DE 50 00 00 00 
05 00 00 00 00 54 2B AD
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Payload (62): 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 01 2C 00 01 00 03 00 02 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A
Balkonkraftwerk/ch1/U_DC: 0.200 V
Balkonkraftwerk/ch1/I_DC: 0.010 A
Balkonkraftwerk/ch2/U_DC: 0.200 V
Balkonkraftwerk/ch2/I_DC: 0.010 A
Balkonkraftwerk/ch3/U_DC: 30.000 V
Balkonkraftwerk/ch3/I_DC: 0.010 A
Balkonkraftwerk/ch3/P_DC: 0.200 W
Balkonkraftwerk/ch4/U_DC: 30.000 V
Balkonkraftwerk/ch4/I_DC: 0.030 A
Balkonkraftwerk/ch4/P_DC: 0.800 W
Balkonkraftwerk/ch4/YieldTota: 0.001 kWh
Balkonkraftwerk/ch0/Temp: 23.100 °
Balkonkraftwerk/ch0/YieldTota: 0.001 kWh

[Lukas P. (lumapu)]

David B. schrieb:
> Problem:
> inverter type can't be detected!

Sorry mein Fehler, ich werde das später noch fixen, habe wohl die Liste 
der Inverter zu schnell gelesen.
Passe doch bei dir temporär mal in hmSystem.h:40 die 0x11 auf 0x10 an.

[David B. (mystisch)]

Ok, das mit dem Fehler
inverter type can't be detected!

ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht.

ändere ich die S/N auf 1141..., ist der Fehler weg, aber Daten werden 
noch immer nicht empfangen.
@lumapu: Codestelle korrigiert, der error trace ist auch mit regulärer 
S/N weg. Aber der Inverter bleibt stumm.

[Lukas P. (lumapu)]

David B. schrieb:
> ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht.

Soweit ich weiß haben wir es noch nicht geschafft einen Inverter der 
MI-Serie auszulesen. Daher werden egal welche Veränderungen gemacht 
werden auch weiterhin keine Daten rauskommen.
Auf der 3ten Seite dieses Threads hat Ziyat T. (toe_c) schon einiges zu 
MI-1500 geschrieben:

Ziyat T. schrieb:
> Hallo
> Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?

[Daniel R. (daniel92)]

Ich habe schwierigkeite bei der App was zu finden, was für uns wichtig 
seien könnte.

Ich durchsuche quasi alles, was Interessant für uns seien könnte. Das 
näheste was ich gefunden habe ist im Anhang zu finden.

Zeile 5506, 6760

Kennt sich jemand noch mit dem ... aus? ^^
Mein wissen stößt langsam bei Java an meine grenzen.

[David B. (mystisch)]

Lukas P. schrieb:
> David B. schrieb:
>> ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht.
>
> Soweit ich weiß haben wir es noch nicht geschafft einen Inverter der
> MI-Serie auszulesen. Daher werden egal welche Veränderungen gemacht
> werden auch weiterhin keine Daten rauskommen.
> Auf der 3ten Seite dieses Threads hat Ziyat T. (toe_c) schon einiges zu
> MI-1500 geschrieben:
>
> Ziyat T. schrieb:
>> Hallo
>> Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?

achso, ja dann, das hab ich dann wohl überlesen.
Hier wäre dann noch einer im Besitz eines WR der MI Serie ;)

[Lukas P. (lumapu)]

Was haltet ihr davon wenn wir zur Dokumentation ähnlich wie Tasmota eine 
Github.io Seite einrichten. Das geht so wie es gelesen habe direkt im 
Repository zu aktivieren, wäre also eine Aufgabe für Martin G. 
(petersilie)

Hat jemand Erfahrungen mit Github-Actions? Habe mal kurz bei Tasmota 
gespickt und gesehen, dass hier platformio installiert wird und damit 
gebaut wird.

[Daniel R. (daniel92)]

Gute Idee, dann könnte man ein FAQ einrichten und und und...  =)

[isnoAhoy (Gast)]

> Ich habe Schwierigkeiten bei der App was zu finden, was für uns wichtig
> seien könnte.
> Ich durchsuche quasi alles, was Interessant für uns seien könnte. Das
> näheste was ich gefunden habe ist im Anhang zu finden.
> Zeile 5506, 6760

Ja das habe ich auch gesehen in Deinem DevConfigSMLPE.txt Anhang.

Ich fand die folgende MO (Message Objekte?) sehr interessant, da hat man 
alles nochmal in einer Zeile.
Die sind jeweils kurz vor den dazugehörigen Checksum Berechnungen mit 
`int hashcode` und den von Dir z.B. ab Zeile 5506 gefundenen und jeweils 
zugehörigen writeTo/getSerializedSize Methoden.
U.a. scheint es darin auch eine acPSf (?) und die invSwAddr zu geben.

Ob das Ganze aber für die Kommunikation mit der Hoymiles Cloud oder 
direkt mit der DTU gedacht ist kann ich nicht sagen.
Vielleicht können wir ja später mehr Sinn darin sehen, wenn wir noch ein 
paar Ergebnisse aus der DTU Pro Analyse haben ?

            PDbusConfigMO pDbusConfigMO = (PDbusConfigMO) obj;
            return (((((((((((((((((((((((((((((((((((((((((getSysType() == pDbusConfigMO.getSysType()) && getSysCfg() == pDbusConfigMO.getSysCfg()) && getDevNum() == pDbusConfigMO.getDevNum()) && getStrNum() == pDbusConfigMO.getStrNum()) && getReserve1() == pDbusConfigMO.getReserve1()) && getSmlpeAdVer() == pDbusConfigMO.getSmlpeAdVer()) && getCmdInterval() == pDbusConfigMO.getCmdInterval()) && getHbsInterval() == pDbusConfigMO.getHbsInterval()) && getTBd() == pDbusConfigMO.getTBd()) && getDataSampMode() == pDbusConfigMO.getDataSampMode()) && getPdbusComErrCnt() == pDbusConfigMO.getPdbusComErrCnt()) && getSmlpeComErrCnt() == pDbusConfigMO.getSmlpeComErrCnt()) && getDayModeCheckTm() == pDbusConfigMO.getDayModeCheckTm()) && getDayModeSmlpePercent() == pDbusConfigMO.getDayModeSmlpePercent()) && getReserve2() == pDbusConfigMO.getReserve2()) && getEnexSearchCnt() == pDbusConfigMO.getEnexSearchCnt()) && getEnSearchHbsCnt() == pDbusConfigMO.getEnSearchHbsCnt()) && getClearSearchDataCnt() == pDbusConfigMO.getClearSearchDataCnt()) && getSearchHostErrCnt() == pDbusConfigMO.getSearchHostErrCnt()) && getSearchSlaveCnt() == pDbusConfigMO.getSearchSlaveCnt()) && getSearchHostTout() == pDbusConfigMO.getSearchHostTout()) && getCompeteHostReceiptnone() == pDbusConfigMO.getCompeteHostReceiptnone()) && getSearchHost1ReciptnoneCnt() == pDbusConfigMO.getSearchHost1ReciptnoneCnt()) && getSearchHost2RecipterrCnt() == pDbusConfigMO.getSearchHost2RecipterrCnt()) && getRegMasterRssiTh() == pDbusConfigMO.getRegMasterRssiTh()) && getRegMasterReplyErrCnt() == pDbusConfigMO.getRegMasterReplyErrCnt()) && getSlaveRegMasterRssiTh() == pDbusConfigMO.getSlaveRegMasterRssiTh()) && getRegMasterCnt() == pDbusConfigMO.getRegMasterCnt()) && getCloseStrCnt() == pDbusConfigMO.getCloseStrCnt()) && getCancelMasterRegCnt() == pDbusConfigMO.getCancelMasterRegCnt()) && getTurnOnStrCnt() == pDbusConfigMO.getTurnOnStrCnt()) && getTurnOnStrHbsCnt() == pDbusConfigMO.getTurnOnStrHbsCnt()) && getSearchSlave1Reciptnone() == pDbusConfigMO.getSearchSlave1Reciptnone()) && getSearchSlave2SeciptsrrCnt() == pDbusConfigMO.getSearchSlave2SeciptsrrCnt()) && getRegSlaveCnt() == pDbusConfigMO.getRegSlaveCnt()) && getSeedNum() == pDbusConfigMO.getSeedNum()) && getReserve3() == pDbusConfigMO.getReserve3()) && getReserve4() == pDbusConfigMO.getReserve4()) && getReserve5() == pDbusConfigMO.getReserve5()) && getReserve6() == pDbusConfigMO.getReserve6()) && getReserve7() == pDbusConfigMO.getReserve7()) && getReserve8() == pDbusConfigMO.getReserve8();

            InvInfoAddrMO invInfoAddrMO = (InvInfoAddrMO) obj;
            return (((getEn() == invInfoAddrMO.getEn()) && getFc() == invInfoAddrMO.getFc()) && getStartAddr() == invInfoAddrMO.getStartAddr()) && getLength() == invInfoAddrMO.getLength();

            InvRealAddrMO invRealAddrMO = (InvRealAddrMO) obj;
            return (((getEn() == invRealAddrMO.getEn()) && getFc() == invRealAddrMO.getFc()) && getStartAddr() == invRealAddrMO.getStartAddr()) && getLength() == invRealAddrMO.getLength();

            PvStrAddrMO pvStrAddrMO = (PvStrAddrMO) obj;
            return (getVAddr() == pvStrAddrMO.getVAddr()) && getIAddr() == pvStrAddrMO.getIAddr();

            InvConfigMO invConfigMO = (InvConfigMO) obj;
            return ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((getInvVer() == invConfigMO.getInvVer()) && getDs().equals(invConfigMO.getDs())) && getModel().equals(invConfigMO.getModel())) && getFBoost() == invConfigMO.getFBoost()) && getFInv() == invConfigMO.getFInv()) && getMpptNum() == invConfigMO.getMpptNum()) && getStrNumMax() == invConfigMO.getStrNumMax()) && getPvSampCfg() == invConfigMO.getPvSampCfg()) && getAcMode() == invConfigMO.getAcMode()) && getEsReady() == invConfigMO.getEsReady()) && getLoadMonitorMode() == invConfigMO.getLoadMonitorMode()) && getComMode() == invConfigMO.getComMode()) && getEndian() == invConfigMO.getEndian()) && getInvInterval() == invConfigMO.getInvInterval()) && getStartDelay() == invConfigMO.getStartDelay()) && getRefreshDelayTm() == invConfigMO.getRefreshDelayTm()) && getInvDataSafetyMode() == invConfigMO.getInvDataSafetyMode()) && getComErrDelay() == invConfigMO.getComErrDelay()) && getNightModeDetectTm() == invConfigMO.getNightModeDetectTm()) && getDayModeCheckTm() == invConfigMO.getDayModeCheckTm()) && getBatteryEn() == invConfigMO.getBatteryEn()) && getLoadMonitorEn() == invConfigMO.getLoadMonitorEn()) && getLinkMode() == invConfigMO.getLinkMode()) && getInvSlaveAddr() == invConfigMO.getInvSlaveAddr()) && getInvIp().equals(invConfigMO.getInvIp())) && getInvPort() == invConfigMO.getInvPort()) && getInvBd() == invConfigMO.getInvBd()) && getInvParity() == invConfigMO.getInvParity()) && getInvStart() == invConfigMO.getInvStart()) && getInvStop() == invConfigMO.getInvStop()) && getInvInfoAddrList().equals(invConfigMO.getInvInfoAddrList())) && getInvRealAddrList().equals(invConfigMO.getInvRealAddrList())) && getAcPSf() == invConfigMO.getAcPSf()) && getAcEhSf() == invConfigMO.getAcEhSf()) && getLoadPSf() == invConfigMO.getLoadPSf()) && getGridPSf() == invConfigMO.getGridPSf()) && getLoadEhSf() == invConfigMO.getLoadEhSf()) && getBatSocSf() == invConfigMO.getBatSocSf()) && getBatPSf() == invConfigMO.getBatPSf()) && getPvStrVSf() == invConfigMO.getPvStrVSf()) && getPvStrISf() == invConfigMO.getPvStrISf()) && getPvStrPSf() == invConfigMO.getPvStrPSf()) && getPvStrEhSf() == invConfigMO.getPvStrEhSf()) && getAcPAddr() == invConfigMO.getAcPAddr()) && getAcPFc() == invConfigMO.getAcPFc()) && getAcPNum() == invConfigMO.getAcPNum()) && getAcEhAddr() == invConfigMO.getAcEhAddr()) && getAcEhFc() == invConfigMO.getAcEhFc()) && getAcEhNum() == invConfigMO.getAcEhNum()) && getLoadPAddr() == invConfigMO.getLoadPAddr()) && getLoadPFc() == invConfigMO.getLoadPFc()) && getLoadPNum() == invConfigMO.getLoadPNum()) && getLoadEhAddr() == invConfigMO.getLoadEhAddr()) && getLoadEhFc() == invConfigMO.getLoadEhFc()) && getLoadEhNum() == invConfigMO.getLoadEhNum()) && getPvPAddr() == invConfigMO.getPvPAddr()) && getPvPFc() == invConfigMO.getPvPFc()) && getPvPNum() == invConfigMO.getPvPNum()) && getGridPAddr() == invConfigMO.getGridPAddr()) && getGridPFc() == invConfigMO.getGridPFc()) && getGridPNum() == invConfigMO.getGridPNum()) && getBuyPAddr() == invConfigMO.getBuyPAddr()) && getBuyPFc() == invConfigMO.getBuyPFc()) && getBuyPNum() == invConfigMO.getBuyPNum()) && getSailPAddr() == invConfigMO.getSailPAddr()) && getSailPFc() == invConfigMO.getSailPFc()) && getSailPNum() == invConfigMO.getSailPNum()) && getBatSocAddr() == invConfigMO.getBatSocAddr()) && getBatSocFc() == invConfigMO.getBatSocFc()) && getBatSocNum() == invConfigMO.getBatSocNum()) && getBatPAddr() == invConfigMO.getBatPAddr()) && getBatPFc() == invConfigMO.getBatPFc()) && getBatPNum() == invConfigMO.getBatPNum()) && getPvStrTotalPAddr() == invConfigMO.getPvStrTotalPAddr()) && getPvStrTotalPFc() == invConfigMO.getPvStrTotalPFc()) && getPvStrTotalPNum() == invConfigMO.getPvStrTotalPNum()) && getPvStrTotalEhAddr() == invConfigMO.getPvStrTotalEhAddr()) && getPvStrTotalEhFc() == invConfigMO.getPvStrTotalEhFc()) && getPvStrTotalEhNum() == invConfigMO.getPvStrTotalEhNum()) && getPvStrRealAddrList().equals(invConfigMO.getPvStrRealAddrList())) && getInvSwAddr() == invConfigMO.getInvSwAddr()) && getInvSwFc() == invConfigMO.getInvSwFc()) && getInvSwNum() == invConfigMO.getInvSwNum()) && getPdSwAddr() == invConfigMO.getPdSwAddr()) && getPdSwFc() == invConfigMO.getPdSwFc()) && getPdSwNum() == invConfigMO.getPdSwNum()) && getOpenVal() == invConfigMO.getOpenVal()) && getCloseVal() == invConfigMO.getCloseVal()) && getPdValType() == invConfigMO.getPdValType()) && getPdValSf() == invConfigMO.getPdValSf()) && getReserve9() == invConfigMO.getReserve9()) && getReserve10() == invConfigMO.getReserve10()) && getReserve11() == invConfigMO.getReserve11()) && getReserve12() == invConfigMO.getReserve12()) && getReserve13() == invConfigMO.getReserve13()) && getReserve14() == invConfigMO.getReserve14()) && getSInterval() == invConfigMO.getSInterval()) && getReserve15() == invConfigMO.getReserve15()) && getDevMode() == invConfigMO.getDevMode()) && getDevAddr() == invConfigMO.getDevAddr()) && getBaudBd() == invConfigMO.getBaudBd()) && getParity() == invConfigMO.getParity()) && getStart() == invConfigMO.getStart()) && getStop() == invConfigMO.getStop()) && getReserve16() == invConfigMO.getReserve16();

            int acPSf = (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((hashCode * 37) + 33) * 53) + getAcPSf()) * 37) + 34) * 53) + getAcEhSf()) * 37) + 35) * 53) + getLoadPSf()) * 37) + 36) * 53) + getGridPSf()) * 37) + 37) * 53) + getLoadEhSf()) * 37) + 38) * 53) + getBatSocSf()) * 37) + 39) * 53) + getBatPSf()) * 37) + 40) * 53) + getPvStrVSf()) * 37) + 41) * 53) + getPvStrISf()) * 37) + 42) * 53) + getPvStrPSf()) * 37) + 43) * 53) + getPvStrEhSf()) * 37) + 44) * 53) + getAcPAddr()) * 37) + 45) * 53) + getAcPFc()) * 37) + 46) * 53) + getAcPNum()) * 37) + 47) * 53) + getAcEhAddr()) * 37) + 48) * 53) + getAcEhFc()) * 37) + 49) * 53) + getAcEhNum()) * 37) + 50) * 53) + getLoadPAddr()) * 37) + 51) * 53) + getLoadPFc()) * 37) + 52) * 53) + getLoadPNum()) * 37) + 53) * 53) + getLoadEhAddr()) * 37) + 54) * 53) + getLoadEhFc()) * 37) + 55) * 53) + getLoadEhNum()) * 37) + 56) * 53) + getPvPAddr()) * 37) + 57) * 53) + getPvPFc()) * 37) + 58) * 53) + getPvPNum()) * 37) + 59) * 53) + getGridPAddr()) * 37) + 60) * 53) + getGridPFc()) * 37) + 61) * 53) + getGridPNum()) * 37) + 62) * 53) + getBuyPAddr()) * 37) + 63) * 53) + getBuyPFc()) * 37) + 64) * 53) + getBuyPNum()) * 37) + 65) * 53) + getSailPAddr()) * 37) + 66) * 53) + getSailPFc()) * 37) + 67) * 53) + getSailPNum()) * 37) + 68) * 53) + getBatSocAddr()) * 37) + 69) * 53) + getBatSocFc()) * 37) + 70) * 53) + getBatSocNum()) * 37) + 71) * 53) + getBatPAddr()) * 37) + 72) * 53) + getBatPFc()) * 37) + 73) * 53) + getBatPNum()) * 37) + 74) * 53) + getPvStrTotalPAddr()) * 37) + 75) * 53) + getPvStrTotalPFc()) * 37) + 76) * 53) + getPvStrTotalPNum()) * 37) + 77) * 53) + getPvStrTotalEhAddr()) * 37) + 78) * 53) + getPvStrTotalEhFc()) * 37) + 79) * 53) + getPvStrTotalEhNum();

            int invSwAddr = (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((acPSf * 37) + 81) * 53) + getInvSwAddr()) * 37) + 82) * 53) + getInvSwFc()) * 37) + 83) * 53) + getInvSwNum()) * 37) + 84) * 53) + getPdSwAddr()) * 37) + 85) * 53) + getPdSwFc()) * 37) + 86) * 53) + getPdSwNum()) * 37) + 87) * 53) + getOpenVal()) * 37) + 88) * 53) + getCloseVal()) * 37) + 89) * 53) + getPdValType()) * 37) + 90) * 53) + getPdValSf()) * 37) + 91) * 53) + getReserve9()) * 37) + 92) * 53) + getReserve10()) * 37) + 93) * 53) + getReserve11()) * 37) + 94) * 53) + getReserve12()) * 37) + 95) * 53) + getReserve13()) * 37) + 96) * 53) + getReserve14()) * 37) + 97) * 53) + getSInterval()) * 37) + 98) * 53) + getReserve15()) * 37) + 99) * 53) + getDevMode()) * 37) + 100) * 53) + getDevAddr()) * 37) + 101) * 53) + getBaudBd()) * 37) + 102) * 53) + getParity()) * 37) + 103) * 53) + getStart()) * 37) + 104) * 53) + getStop()) * 37) + 105) * 53) + getReserve16()) * 29) + this.unknownFields.hashCode();

            LoggerConfigMO loggerConfigMO = (LoggerConfigMO) obj;
            return ((((((((((((((((getWorkMode() == loggerConfigMO.getWorkMode()) && getCommMode() == loggerConfigMO.getCommMode()) && getDhcpSw() == loggerConfigMO.getDhcpSw()) && getIp().equals(loggerConfigMO.getIp())) && getNetmask().equals(loggerConfigMO.getNetmask())) && getGw().equals(loggerConfigMO.getGw())) && getDns().equals(loggerConfigMO.getDns())) && getApSsid().equals(loggerConfigMO.getApSsid())) && getApPwd().equals(loggerConfigMO.getApPwd())) && getSpApn().equals(loggerConfigMO.getSpApn())) && getSpName().equals(loggerConfigMO.getSpName())) && getSpPwd().equals(loggerConfigMO.getSpPwd())) && getGprsNo().equals(loggerConfigMO.getGprsNo())) && getReserve19() == loggerConfigMO.getReserve19()) && getSvrPort() == loggerConfigMO.getSvrPort()) && getSvrHost().equals(loggerConfigMO.getSvrHost())) && getReserve20() == loggerConfigMO.getReserve20();

            ConfigParaMO configParaMO = (ConfigParaMO) obj;
            return ((getPdbusCfgList().equals(configParaMO.getPdbusCfgList())) && getInvCfgList().equals(configParaMO.getInvCfgList())) && getLogCfgList().equals(configParaMO.getLogCfgList());

            WriteHRegResDTO writeHRegResDTO = (WriteHRegResDTO) obj;
            return (((((((getOffset() == writeHRegResDTO.getOffset()) && getTime() == writeHRegResDTO.getTime()) && getAction() == writeHRegResDTO.getAction()) && (getGwSn() > writeHRegResDTO.getGwSn() ? 1 : (getGwSn() == writeHRegResDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > writeHRegResDTO.getLogSn() ? 1 : (getLogSn() == writeHRegResDTO.getLogSn() ? 0 : -1)) == 0) && getAp() == writeHRegResDTO.getAp()) && getCp() == writeHRegResDTO.getCp()) && getCfgParaList().equals(writeHRegResDTO.getCfgParaList());

            WriteHRegReqDTO writeHRegReqDTO = (WriteHRegReqDTO) obj;
            return ((((((getOffset() == writeHRegReqDTO.getOffset()) && getTime() == writeHRegReqDTO.getTime()) && getAction() == writeHRegReqDTO.getAction()) && (getGwSn() > writeHRegReqDTO.getGwSn() ? 1 : (getGwSn() == writeHRegReqDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > writeHRegReqDTO.getLogSn() ? 1 : (getLogSn() == writeHRegReqDTO.getLogSn() ? 0 : -1)) == 0) && getCp() == writeHRegReqDTO.getCp()) && getErrCode() == writeHRegReqDTO.getErrCode();

            ReadHRegReqDTO readHRegReqDTO = (ReadHRegReqDTO) obj;
            return (((((((getOffset() == readHRegReqDTO.getOffset()) && getTime() == readHRegReqDTO.getTime()) && getAction() == readHRegReqDTO.getAction()) && (getGwSn() > readHRegReqDTO.getGwSn() ? 1 : (getGwSn() == readHRegReqDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > readHRegReqDTO.getLogSn() ? 1 : (getLogSn() == readHRegReqDTO.getLogSn() ? 0 : -1)) == 0) && getAp() == readHRegReqDTO.getAp()) && getCp() == readHRegReqDTO.getCp()) && getCfgParaList().equals(readHRegReqDTO.getCfgParaList());

            ReadHRegResDTO readHRegResDTO = (ReadHRegResDTO) obj;
            return ((((getOffset() == readHRegResDTO.getOffset()) && getTime() == readHRegResDTO.getTime()) && getAction() == readHRegResDTO.getAction()) && (getGwSn() > readHRegResDTO.getGwSn() ? 1 : (getGwSn() == readHRegResDTO.getGwSn() ? 0 : -1)) == 0) && getLogSn() == readHRegResDTO.getLogSn();

[Olaf A. (Gast)]

Ich habe folgendes im Netz gefunden.

Bedienungsanleitung MI-1000/MI-1200/MI-1500
Version 2.0 (Juni 2020)

6. Fehlersuche
Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems 
Mitte 2020 aktualisiert.
Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" 
verwenden, so beziehen
Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den 
Mikrowechselrichter mit
Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen 
Sie sich bitte auf
Abschnitt 6.2 und Abschnitt 6.4.


*Anmerkung: Der Mikrowechselrichter 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

[Olaf A. (Gast)]

Hier im Forum gibt es unter

nRF24L01+ und PA Kombi gibt kein Acknowledge

Hinweise zu Inkompatibilitäten zwischen Orginal-Chip's und Nachbauten.

Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"

[Daniel R. (daniel92)]

Hallo zusammen,

@isnoAhoy: das ist mir auch aufgefallen, jedoch war das ganze schon sehr 
lang. Das müsste man sich nochmal anschauen. In erster linie war mir 
wichtig etwas "pregnantes" zu finden. Was uns direkt weiterhelfen 
könnte.

@Olaf A: Danke für die Info, ich habe nämlich beim decompilen 
herausgefunden das es tatsächlich Geräte hinterlegt sind mit einer 
bestimmten Kennung.
Wobei ich diese eher als Test entnommen habe und nicht dachte das diese 
eventuell was für uns aussagt.

Siehe Zeile ab 38 im Anhang.

Gruß Daniel

Nachtrag: Ich meine diese Einträge sagen aus, wie die App mit der DTU zu 
arbeiten hat. Da jedes Produkt eine eigene Kennung besitzt und diese im 
ganzen System Automatisch hinterlegt wird.

Beispiel: Mikrowechselrichter mit Batterie und einem Energiemessgerät 
zusammen in einer App... und welcher DTU im System ist, handelt es sich 
um eine Pro oder um eine Lite Version.

Im Handbuch steht im Punkt 4.1 was Interessantes: 
https://www.hoymiles.com/wp-content/uploads/2021/05/BENUTZERHANDBUCH_HM-100012001500_Global_DE_V202203.pdf 
- Ich glaube man muss hier nur denn Wert definitiv irgendwie ändern. Das 
Suchen wir ja aktuell. Aber mehr steht dort auch nicht.

Kopfschmerzen habe ich beim Thema 0 Einspeisung, da hier der WR 
irgendwie mit einem Messgerät zusammen Kommunizieren muss. Damit der WR 
regeln kann.

Generell die Leistung vom WR auf einem festen Wert zu regeln, erlese ich 
aber dort leider nicht. :( Das wäre für uns ja fundamental, damit wir 
diese automatisiert regeln können.

[Mel Yoshi (Gast)]

Grüezi mitenand,

hier sind ein paar Videos und Bilder zum Hoymiles Wechselrichter 
(MI-1200 und HM-800):
 - zum Thema Nulleinspeisung:
   https://www.youtube.com/watch?v=BVWrG8nCMPQ

 - zum Innenleben des Wechselrichters:
   https://www.youtube.com/watch?v=Ho02aQxyX20
   https://www.youtube.com/watch?v=AtOjcIZpGKI
   https://www.youtube.com/watch?v=cgw11fTxhH8
   https://www.youtube.com/watch?v=Tu75J9IIhUg
   https://www.photovoltaikforum.com/thread/171257-hoymiles-hm800-leistungssteuerung-per-pwm/

[Daniel R. (daniel92)]

Sehr cool, vielen dank!
Dann kann man sich heute nach der Arbeit mal alles durch arbeiten und 
weiter schauen. :) Besten Dank Yoshi

[Jan-Jonas S. (janjonas_s)]

Hi,

das letzte Paket kann wohl nicht zum re-transmit angefragt werden. Wenn 
das fehlt ist wohl zwingend eine neue Transaktion nötig.

Lukas P. schrieb:
> Was haltet ihr davon wenn wir zur Dokumentation ähnlich wie Tasmota eine
> Github.io Seite einrichten. Das geht so wie es gelesen habe direkt im
> Repository zu aktivieren, wäre also eine Aufgabe für Martin G.
> (petersilie)
Wird spaßig, weil wir 2 Softwaren in dem repo haben. Ich glaube wir sind 
mit Markdown besser bedient.

> Hat jemand Erfahrungen mit Github-Actions? Habe mal kurz bei Tasmota
> gespickt und gesehen, dass hier platformio installiert wird und damit
> gebaut wird.

Pipelines. Spätestens da macht es dann Sinn das Projekt in die einzelnen 
Implementierungen zu splitten. Ich arbeite normal mit Drone oder Gitlab 
Runner. Sehr praktisch, aber Entwicklungsaufwand mal 2.

Daniel R. schrieb:
> Kopfschmerzen habe ich beim Thema 0 Einspeisung, da hier der WR
> irgendwie mit einem Messgerät zusammen Kommunizieren muss. Damit der WR
> regeln kann.

Eher wenig Kopfschmerzen. Aber da brauchen wir noch sehr viel 
Protokoll-Analyse. Ich meine damit, Tage an Rohdatenmittschnitten vom 
Original im Idealfall unter verschiedenen Betriebsbedingungen. Natürlich 
muss dem Wechselrichter irgendwo ein Bit gesetzt werden, dass die DTU 
die Leistungsvorgabe setzen muss (der WR damit ohne Kommunikation 
abschaltet) und dann muss die DTU die Leistungsanforderung eben 
regelmäßig in der WR schreiben. Die DTU fragt das dann wohl via Modbus 
vom Energiezähler ab und provisierniert mit dem Einspeisebudget alle 
paar Sekunden die Wechselrichter.

Ich denke dabei gerade daran das Einspeisebudget aus den 
Zählerinformationen via Mqtt zu lesen bzw. die nötigen Payloads via HASS 
generieren zu lassen und dann via Command-Topic an den WR zu relayen.

Gruß,
Jan

[Daniel R. (daniel92)]

Moin Jan,

zu deiner letzten Passage, da gebe ich dir recht. Habe mir im Nachhinein 
die YT-Videos die Yoshi hinterlegt hat angeschaut und wird sehr sauber 
beschrieben:

- zum Thema Nulleinspeisung: https://www.youtube.com/watch?v=BVWrG8nCMPQ

Das ist genau so wie du beschrieben hast, nur das hier zwischen DTU und 
Messzähler eine RS485 zum Einsatz kommt (3:35min). - Whatever, es geht 
aufjedenfall weiter. =)

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> nur das hier zwischen DTU und Messzähler eine RS485 zum Einsatz kommt

Jan-Jonas S. schrieb:
> Die DTU fragt das dann wohl via Modbus vom Energiezähler ab

[Tobi D. (tobidd)]

Ich nutze einen shelly3em zur aktuellen energiemessung meines 
Haushaltes. Wäre prima wenn die Nulleinspeisung auf zb Werte die per 
Mqtt kommen weiterverarbeitet werden, so ist es für viele Systeme offen 
und nicht auf den energiemesser den hoymiles vorgibt beschränkt.

[Marcel A. (a-marcel)]

Das wäre doch alles viel zu langsam, wenn die DTU jetzt was von einem 
Messgerät ließt und das dann dem Wechselrichter zukommen lässt und das 
auch noch over the air. Da wird ja man ja an Strahlung gegrillt ;). In 
der Preisklasse der Wechselrichter gehe ich davon aus, das man a) einen 
festen Leistungswert oder b) einen prozentualen leistungswert an den 
Wechselrichter übermittelt.

Alles andere sehe ich nicht in diesem Preisbereich und muss selber 
gebaut werden. Deswegen wäre es eben cool wenn wir mal Mitschnitte haben 
wo die DTU mit dem WR kommuniziert und man mehrfach die Leistungswerte 
ändert.

Marcel

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Ich habe eine DTU-Pro

Hallo Ziyat, bist du hier noch aktiv?
Wäre es möglich uns hierbei einige Infos über das teil zukommen zu 
lassen?

Oder wäre es möglich es auszuleihen um weitere Recherchen daran zu 
betreiben?

Wer hat noch so ein DTU-Pro?

@Jan: Sorry ^^

Gruß Daniel

Edit: Ich bin nun aktiv dabei weiter die Logs mal auszuwerten.
Nur das ich auf dem richtigen weg bin, habe ich dazu eine Frage:

Ich vergleiche aktuell die Logs untereinander und versuche durch die 
Logs eine Symmetrie zu finden. Dazu habe ich auch Logs mir erstellt, wo 
ich versuche die Werte manuell zu ändern. Zb: "kein PV Spannung", PV 
Spannung, kein AC Spannung und wieder AC Spannung habe, um zum Beispiel 
eine Inkrimierte Variabel zu finden. Oder den aktuellen Status des WR zu 
erlesen ist.  - Was haltet ihr von der vorgehensweiße?

[Daniel R. (daniel92)]

Moin zusammen,

könnte man in der Log das ganze bisschen ausbauen?

Aktuell muss ich mühsehlig alles ausseinander ziehen und schauen welches 
Bit noch undefiniert ist. Oder hat jemand eine Excel geschrieben, wo ich 
das reinhauen kann um zu sehen was übrig bleibt?

Danke

[Lukas P. (lumapu)]

Daniel R. schrieb:
> könnte man in der Log das ganze bisschen ausbauen?

Baue dir am besten eine Firmware oder noch besser verwende Jan's Python 
Code als  Basis und lass dir die Roh-Daten ausgeben. Ich denke in Python 
geht das fixer, Code umbauen und sofort testen, nicht erst kompilieren 
und updaten. Nach und nach kannst du dann einen Parser für die Daten 
entwickeln.
Die entgültige Erkenntnis kannst du dann wieder in den ESP portieren 
sofern er dir dann noch zusagt ;-)

[Daniel R. (daniel92)]

Hi Lukas,

danke, ja aktuell mach ich das über ESP. Muss das echt mal auf den 
Raspberry portieren...

hmm alles klar, so kann man das auch machen. Danke. :)

[Daniel R. (daniel92)]

Morgen,

hab was neues entdeckt in einer Anleitung.
Auf dieser Seite https://www.shinetech-power.de/en/inverter/hoymiles/ 
werden Produkte anscheinend verkauft. Unter dem Punkt "Hoymiles DTU-Pro" 
sind auch Anleitung in PDF hinterlegt.

Darunter auch Modbus Protokoll mit einer riesen Tabelle.
Ich bin heute nach der Arbeit beim Grillfest, vielleicht kann es sich 
jemand von euch mal anschauen?

https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

Gruß Daniel

[Lukas P. (lumapu)]

ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze) 
behoben

[Markus (Gast)]

Hi tbnobody,
wäre es möglich, dass du hier einen Export(json) deines Grafana Boards 
zur Verfügung stellst?

Danke dir.

Viele Grüße

[isnoAhoy (Gast)]

Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c):

Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und 
speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz 
vollständige Liste der DTUs im Besitz von Foren Teilnehmern. Auch ein 
Salea Logic Analyzer habe ich mal ausprobiert und anhand den von martin 
(Gast) in seiner DTU-Lite aufgenommenen Daten (RX/TX) Testpunkt 
dokumentiert, wie man dabei zu den entsprechenden Logfiles kommt. Es 
gibt da sog. Analyzer (speziell Async Serial funktioniert) und dann kann 
man einen Export ins CSV Format machen.

Jetzt bräuchten wir nur noch einen Freiwilligen DTU-Pro Besitzer, der 
das große Kästchen mal aufschraubt und an den RX/TX Punkten mißt was 
passiert, wenn man per ModBus ein paar Kommandos gibt. Wenn die DTU 
Besitzer ihre Geräte nicht aufschrauben wollen gäbe es immer noch andere 
Methoden (NRF24_Sniffer, Ahoy zum Sniffen anpassen) die eventuell etwas 
minimal-invasiver sind, jedoch wäre das vermutlich mit mehr Aufwand und 
weniger Erkenntnisgewinn verknüpft, da die Pakete nicht so sicher 
belauscht werden können wie am RX/TX Testpunkt auf der Platine.

Die Salea Logic Analyzer bzw. Clones gibt es übrigens für ca. 13,- Euro 
aus der Bucht:

      https://www.ebay.de/itm/255283244102

* Trace / Sniffer Software:

  - Salea Logic / Clone

    + Sigrok Software (Pulseviwew)

      https://sigrok.org/
      https://sigrok.org/wiki/Downloads
      http://marcusjenkins.com/saleae-logic-analyser-clone-with-ubuntu/

    + Salea Logic

      https://www.saleae.com/downloads/
      chmod +x Logic-2.3.53-master.AppImage
      ./Logic-2.3.53-master.AppImage

        <1F> Analyzer (right side toolbar)
        Analyzers (+)
          Async Serial
            Input Channel: 00. Channel 0
            Bit Rate (Bits/s): 125000
            Bits per Frame: 8 Bits per Transfer (Standard)
            Stop Bits: 1 Stop Bit (Standard)
            Parity Bit: No Parity Bit (Standard)
            Significant Bit: Least Significant Bit Sent First (Standard)
            Signal Inversion: Non Inverted (Standard)
            Mode: Normal
            [x] Show in Protocol Results Table
            [x] Stream to terminal
          Save
        Analyzers (+)
          Async Serial
            Input Channel: 01. Channel 1
            Bit Rate (Bits/s): 125000
            Bits per Frame: 8 Bits per Transfer (Standard)
            Stop Bits: 1 Stop Bit (Standard)
            Parity Bit: No Parity Bit (Standard)
            Significant Bit: Least Significant Bit Sent First (Standard)
            Signal Inversion: Non Inverted (Standard)
            Mode: Normal
            [x] Show in Protocol Results Table
            [x] Stream to terminal
          Save
          Rename the two Async Serial Analyzers to RX / TX
          Data ... Export Table
            Export Table Data
              Columns: (*) All
              Data: (*) All
              Export Format: (*) CSV
              [x] Use ISO8601 Timestamps
            Export

  - NRF24_Sniffer

      git clone https://github.com/Yveaux/NRF24_Sniffer
      ./nrf24-sniffer.py -a 90:65:23:74:01

  - Wireshark

* Python  ESP Variante zum Mitschneiden anpassen  konfigurieren
* Pakete einer DTU und eines Wechselrichters (hier MI-1500) mit der 
ESP/Raspberry Pi Variante mitschneiden.
* Kommandos per Modbus an die DTU-Pro senden und diese mit einem 
LogicAnalyzer an den RX/TX Testpunkten in der DTU mitschneiden
* Payload und Kommandos aus den Datenpaketen extrahieren und analysieren



DTU Besitzer / Nutzer
---------------------

DTU-Pro: Sascha D. (bandit7311), Ziyat T. (toe_c)
DTU-Lite: martin (Gast), Oliver F. (of22), Martin G. (petersilie)
DTU-W100: Arnaldo G. (arnaldo_g), Sergey S. (sergey_s632), Mike (Gast)
DTU ?: Daniel M. (daniel_m821), Martin P. (mpolak77)

DTU-Pro    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
Sascha D. (bandit7311)
DTU-Pro    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Ziyat 
T. (toe_c)

DTU-Lite  xxxx72818832 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  martin 
(Gast)
DTU-Lite  xxxx72819005 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Oliver F. 
(of22)
DTU-Lite    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
Martin G. (petersilie)
DTU-Lite  10D972xxxxxx 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  10D9  martin 
(Gast)

DTU-W100  10D373114359 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  10D3  Sergey S. 
(sergey_s632)
DTU-W100  xxxx70535453 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Arnaldo G. 
(arnaldo_g)
DTU-W100  10D373114359 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  10D3  Sergey S. 
(sergey_s632)
DTU-W100    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Mike 
(Gast)

DTU    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Daniel M. 
(daniel_m821)
DTU basic ?    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
Martin P. (mpolak77)


Exoten MI & TSUN Wechselrichter:

MI-1500  xxxxxxx14456 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Arnaldo G. 
(arnaldo_g)
MI-1500  xxxxxxx36590 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Arnaldo G. 
(arnaldo_g)
MI-1500    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Ziyat 
T. (toe_c)

MI-600  1041xxxxxxxx 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  1041  David B. 
(mystisch)
TSUN TSOL-M800  104163500316 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  1041  Daniel M. 
(Gast)


---

Diskussionsausschnitte zum Thema DTU-Pro und Modbus Ansteuerung
---------------------------------------------------------------

Da ich meiene DTU-Pro über Modbus-RTU selber ansteuere, könnte ich  den
WR gezielt ansteueren, ich waere bereit sie zu sniffen aber brauche
HW-maessig hilfe wie ich es machen soll.

Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen  :-)
MOSI, MISO, usw.
https://www.az-delivery.de/products/saleae-logic-analyzer
Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom
LA klar kommst, dann die PINs im DTU-Lite :-)  so ist das gemeint von
mir.
Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als
Hex anzeigen.

Den LA gibts natürlich auch bei anderen Anbietern.

Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner
DTU festgestellt hatte:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
handelt, der einen eigenen Controller drin hat.

Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für
RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal
anbei.

Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit
Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet.

Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in
zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten
und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was
angefragt wurde, um die Payload dekodieren zu können.

Wir sollten zukünftig also von:
Fragmenten, Paketen, und Payloads sprechen.
Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das
Paket enthält die Payload.

Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment
+ 1 byte crc
Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc
Jede Payload kann demnach max 2046 byte haben.
Vermutung, abgeleitet aus den bisher bekannten Umständen.

In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure
Daten rankommt, aber leider auch nicht identisch ist), sind Register zu
sehen, die dafür zuständig sind:
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über
ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit
dem Protokoll zum WR aussieht, aber es muss ja alles über NRF
funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70%
Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in
jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer
wieder zyklisch das aktuelle Limit geschrieben.
Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur
da das möglich bzw. freigegeben ist.

Nach Inbetriebnahme kann ich gerne auch Daten beisteuern.
Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu
unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion
zu "entschlüsseln".

Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie
Hat die HMT-Serie ein geändertes Protokoll?

Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern:
HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500  1200-4T HMS-1000
900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.

[Jan-Jonas S. (janjonas_s)]

isnoAhoy schrieb:
> Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie
> Hat die HMT-Serie ein geändertes Protokoll?

Good point. Das ist mir auch schon aufgefallen, dass die HM's bei der 
serial von der DTU recht picky sind. Die 10F... aus dem Excel sheet 
gehen z.B. garnicht.

[Daniel R. (daniel92)]

Hallo isnoAhoy ,

vielen Dank für die tolle zusammenfassung.
Ich habe gestern Abend einige Lieferanten angeschrieben bezügl. DTU-Pro, 
um sein Teil zu erhalten. Bis jetzt noch keine Antwort erhalten.

Wenn ich eins habe, könnte ich es ohne Probleme ausseinander nehmen.
Zum Analysieren habe ich ein "Salea Logic 16 clone", der wunderbar mit 
der Software von Salea funktioniert.

Der einzige Punkt wo ich stutzig bin: Denn WR ausseinander zu nehmen, 
würde ich ungern tun (zwecks Dichtung und co.). Wieso sollte es hier 
nicht ausreichen, direkt am DTU (hinter dem NRF) TX & RX zu belauschen? 
Da sollten ja keine Packete vom NRF modifiziert sein?

Wäre nicht auch die SPI NRF <-> MCU Übertragung mitzusniffen sinnvoll?

Gruß

[Herbert K. (avr-herbi)]

Daniel R. schrieb:

Hallo Daniel,

ich schätze Deine Mitarbeit sehr.
ABER
Du hast Dich irgendwann hier eingeklingt, ohne alle Beiträge zu lesen.
Das Du sie nicht gelesen hast - oder vergessen hast - oder wie auch 
immer ist eindeutig an Deinen Äußerungen zu sehen.

Nach dem nRF24L01+ brauchst zu Equipment für 2,4 GHz ! Das ist HF ! Da 
nutzt Dir der SALEA LA. gar nix.

In den DTU´s sitzt nach unseren bisherigen Erkenntnissen ein 
Kombi-Baustein nämlich ein nRF24 inkl. 80x51 CPU = NRF24LE1E. LE1E ist 
was anderes als LE1+ ! Dazwischen wirst Du kaum Sniffen können.
Alles kalter Kaffee wenn Du alles gelesen hättest.

ModBus sniffen nutzt auch niemand was.

Einzig ein oder mehrere nRF24L01+ die auf allen Kanälen mithören und in 
zeitlich korrekter Reihenfolge Telegramme mithören nutzen etwas.
Ausgelöste Aktionen über ein DTU-Pro oder/und die Cloud, die wir ja 
umgehen wollen.

Es wäre sehr schön, wenn Du uns mit Deiner Erfahrung in dieser Richtung 
weiter unterstützen würdest. Danke schon mal.

Viele Grüße Herbert

[Daniel R. (daniel92)]

Hallo Herbert,

ich verstehe dich sehr gut. Ich gebe dir auch recht das ich mich hier 
relativ spät eingeklingt habe. Dennoch bin ich nicht auf die Nase 
gefallen. - Vorschlag: Alle Fortschritte und Todos in Github zu 
hinterlegen (Wiki)?

Ich habe weder ein Spectrum Analyzer, noch ein Oszi um HF messen zu 
können. Das habe ich alles auf der Arbeit, kann es aber dort schlecht 
privat nutzen. ;) - Via DVB-T und einem SDR, das ist bei mir aber 
aktuell irgendwie nicht möglich (Treiber problem? -> zuletzt vor über 1 
Jahr benutzt).

Um kurz mein Gedanke nochmal neu zu Formulieren, damit ihr wisst wie ich 
gerne euch Unterstützen kann und möchte:

Ich habe Zuhause aktuell ein HM-1500 und einen "NRF24L01+" der an einem 
ESP32 angebunden ist. Wenn ich später einen DTU-Pro haben sollte, wird 
sich auch später zeigen was im inneren steckt.

Aufjedenfall meine ich mit dem oberen Post, das man auf dem PCB (wird ja 
nach der Antenne, mit Filter, etc... auch irgendwo ein IC sein der die 
Signale in Pakete umwandelt) mitlauschen kann. Sei es Seriel oder 
anderweitig.
Da ich den WR ungern ausseinander nehmen möchte und auch nicht so auf 
die schnelle die fliegende Pakete in der Luft aufnehmen kann (ohne 
Equipment nicht möglich, höhö), bleibt mir aktuell nur die Möglichkeit 
hinter dem NFR-IC am DTU mit zu lauschen.

Ich weis, am besten were Zeitgleiche protokolierung auf beiden Seiten WR 
+ DTU um beide Pakete vergleichen zu können, um die genaue reihenfolge 
zu erkennen und und und...

Aber danke Herbert.

PS: Die Funktion "Bearbeiten" nutze ich um nicht Unnötig denn Thread zu 
spamen. Wenn ich Neuinformation habe die für jemand Hilfreich seien 
können, schreibe ich es eben nachträglich rein. =)

[Ralf B. (ralf_b210)]

Lukas P. schrieb:
> ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze)
> behoben

Moin,
hm...
funtzt bei mir leider nicht.
Hatte vorher die 0.3.6 am laufen.

[Lukas P. (lumapu)]

Ralf B. schrieb:
> funtzt bei mir leider nicht.

Schöne Fehlerbeschreibung =) bitte auf Github und mit mehr Details:
- Serielle Konsole, kommt was?
- Visualisierung von ESP, ist alles Null?
- Wechselrichter 1,2 oder 4 Kanäle?
- Pinout in der Setup nochmal gegengecheckt?
- woran machst du fest, dass es nicht geht?

[Ziyat T. (toe_c)]

isnoAhoy schrieb:
> Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c):
>
> Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und
> speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz
> vollständige Liste der DTUs im Besitz von Foren Teilnehmern.

Hallo isnoAhoy
Da ich der einzige mit einem MI1500 bin, und hier alles um den HM dreht, 
hab mal "aufgehört" weiter zu bohren, aber ich werde bald einen HM1500 
bekommen..
Ich habe mit der NRF24_Sniff/wireshark von Ivo Pullens gespielt, kam 
aber  nicht weiter. Das Protokoll für MI ist chaotisch;-)


> 0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über
> ein Relais lösen könnte).

Was ich bisher über Modbus gefunden habe, für MI series:
- 0xC000 on/off geht bei MI nicht
- 0xC001 nur bis 10% der angeschlossene PV-Nennleistung limitierbar, 
darum zero export (ich meine eine NULL) mit dem MI nicht machbar
- 0xC006x/0xC007x Steuerungen der Ports gehen nicht

Grüsse, Ziyat

[isnoAhoy (Gast)]

Hallo Ziyat T. und Daniel R.,

die Aufnahmen mit dem Salea Logic Analyzer sind auf der Platine der DTU 
/ DTU-Pro an den RX/TX Testpunkten. Hier nochmal das Bild von martin 
(Gast) der das bei seiner DTU-Lite sehr schön dokumentiert hat.
Die Aufnahme ist bei 115200 Baud mit dem Salea sehr gut möglich und hat 
sowohl senden als auch empfangen, inklusive evtl. vorhandener Retransmit 
Requests.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ziyat T. schrieb:
>> Ich habe eine DTU-Pro
>
> Hallo Ziyat, bist du hier noch aktiv?

Hallo Daniel
Ich pausiere mal, da ich einen MI1500 habe und nicht weiter gekommen 
bin, bald bekomme ich einen HM1500, hoffe ich mal, dann gehts weiter.

Ich konnte den MI nicht ansprechen, aber wenn die DTU eingeschaltet ist 
konnte ich mithören und aufschlüsseln, siehe Anhang. Die Werte stimmen 
exact.

Meine DTU-Pro kann ich nicht ausleihen, da sie im Betrieb ist und ich 
bin ca. 2000km weit weg..
Grüsse

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:

> @Ziyat willst Du,,,,,,,, uns Bilder schicken ?

Guck mal

[Robert Bleumer (Gast)]

Hatte das gleiche Problem, dann erstmal alle libraries geupdated.

Nochmals kompiliert und upload. Danach funktioniert es wieder 
problemlos.

[Hans W. (hans_w801)]

Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die 
Möglichkeit, die Daten per JSON String zu übermitteln ?

[Lukas P. (lumapu)]

Robert Bleumer schrieb:
> Hatte das gleiche Problem, dann erstmal alle libraries geupdated.
>
> Nochmals kompiliert und upload. Danach funktioniert es wieder
> problemlos.

Das wusste ich nicht, habe eigentlich nichts verändert was neue 
Versionen braucht -zumal ich die genauen Abhängigkeiten gar nicht kenne.

[Lukas P. (lumapu)]

Hans W. schrieb:
> Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die
> Möglichkeit, die Daten per JSON String zu übermitteln ?

Auch bei JSON String würden wir auf eine externe Library setzen. Was 
haben wir dann gewonnen? Wer sagt und das es stabiler ist? Wir können es 
als Option vorsehen, genauso wie MQTT auch eine Option und kein Muss 
ist.
Wenn du sowas implementierst kannst du es gerne per Pull Request 
beitragen.

Schau mal auf GitHub, da hat @isnoAhoy aka stefan123t unter issue #24 
einiges zu abstürzen geschrieben.
Ich bin der Meinung, das sehr viel auch von der Powerversorgung abhängt. 
Evtl. sollen wir alle den Code um den MQTT Bereich nochmal genau 
reviewen.

[Hans W. (hans_w801)]

Lukas P. schrieb:
> Wenn du sowas implementierst kannst du es gerne per Pull Request
> beitragen.

Ich bin leider kein Coder, sondern eher Copy & Paste'er...

[Martin G. (petersilie)]

Komme gerade echt mit dem Hoymiles nicht hinterher. Habe das Projekt 
aber nicht vergessen. Meine DTU liegt noch unbenutzt im Schrank. Toll, 
was wir schon alles rausgefunden haben. Sobald ich ein bisschen mehr 
Zeit habe, mache ich nochmal einen Anlauf. Liebe Grüße - Martin 
(petersilie)

[Andi (Gast)]

@ Ziyat T. (toe_c)
Danke für die Bilder, ich habe mir die mal auf die schnelle angeschaut 
und dabei ist mir aufgefallen, dass in der DTU-Pro das gleiche NRF Modul 
aufgelötet wurde wie in den HM Wechselrichtern selbst verbaut ist(siehe 
HM800 Zerlegtbilder). Ich konnte allerdings auch nach einer halben 
Stunde im Netz suchen dieses Modul nicht finden, da das Pinout natürlich 
interessant wäre. Auf dem Abschirmdeckel scheint leider auch kein Typ 
aufgedruckt zu sein (die HM800 Bilder waren dafür eh zu unscharf).
Da das Modul aber anscheinend HMRF-SMD-V1.1.0 heißt, gehe ich mal stark 
davon aus, dass Hoymiles die Module für sich selbst fertigen lässt(darum 
HMRF) und es keine vergleichbaren NRF Module auf dem freien Markt gibt.

Die Rückseite der Platine(vorallem zwischen STM und NRF Modul) wäre 
sicherlich auch interessant ;-)

Jetzt kommen die Vermutungen von mir (bin kein Platinenexperte, werden 
andere hier sicher noch besser herausfinden, aber um einen Anfang zu 
haben):

erstmal das wohl wichtigste: auf dem NRF Modul sind zum Glück 3 Pins 
beschriftet, diese scheinen für mich recht eindeutig zu sein:
G - Ground
R - Rx
T - Tx
ob die direkt zum NRF Sender gehen ist derzeit noch unbekannt, auch ob 
sich auf der Rückseite Lötpads dazu befinden oder vielleicht mit dem 
nachfolgenden Connector(gegenüber) verbunden sind

P201_NC geht ja offensichtlich zu einer kompletten Seite des NRF Moduls, 
eventuell steckt da mehr darunter, als nur ein NRF-Chip, da so viele 
Pins entweder auf Debug oder programmierbar hindeuten. Wenn wir Pech 
haben ist da noch ein extra Mikrokontroller auf der Platine und die 
Kommunikation zum STM findet über ein eigenes Protokoll statt, nicht 
direkt die NRF Datenkommunikation.

CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn 
unteranderem zu Programmieren oder Debuggen.

Wer es sich zutraut und überhaupt machen möchte/kann, von den DTU-Pro 
Besitzern, kann gern die Abschirmhaube ablöten, dann wäre ein Geheimnis 
mehr gelüftet, muss aber nicht unbedingt sein, da wir auch andere Wege 
haben an die Daten zu kommen.

[Herbert K. (avr-herbi)]

vielleicht so ähnlich  :-)

[Daniel R. (daniel92)]

Guten Abend zusammen,

ich melde mich erst jetzt. Huii die Bilder sind Interessant, aber 
nochmal von Anfang an.

@ Ziyat T.: Alles klar, ist doch kein Problem. Wenn wir es geschaft 
haben, könne wir bestimmt an diesem 2000km weiten Ort Urlaub machen? :P 
- Spaß hehe

Die Bilder sind schonmal sehr gut, könntest du in Zukunft eine komplette 
Aufnahme vom Board (Vorder und Rückseite) machen? Dann kann man sich 
auch besser vorstellen wo was ist. Muss aber nicht sein, die Bilder 
sollten auch so schon reichen. :)

@Martin G(petersilie): Kein Ding, ich bin dabei alles auch aufzuholen 
und das ist wahnsinnig was hier schon geleistet wurde.

@ Andi: Da gebe ich dir recht, die Schnittstelle P201_NC könnte uns 
vielleicht helfen... wer weiß vielleicht auch ein Terminal zum lesen und 
schreiben? Anyway, die PINS auf dem Modul mit  G R T sind Goldwert (wenn 
es nicht intern deaktiviert wurde).

Ich gehe mal davon aus das sie auch nicht rausgeführt wurde.
Oder es geht unter dem Modul weiter.

Hätte ich eine DTU-Pro würde ich das machen, hab alles hier bei mir zum 
Ablöten. ^^

Edit: Gerade was geschrieben, schon eine neue Nachricht.
@ Herbert K: Super! Es geht weiter, sieht sehr ähnlich aus.
Laut Tabelle ist CN201_NC eine SPI Schnittstelle.

[Herbert K. (avr-herbi)]

und noch eines aus dem MI-1200

[Ziyat T. (toe_c)]

Herbert K. schrieb:
> vielleicht so ähnlich  :-)

Genau A6! Super :-)

[martin (Gast)]

Andi schrieb:
> und dabei ist mir aufgefallen, dass in der DTU-Pro das gleiche NRF Modul
> aufgelötet wurde wie in den HM Wechselrichtern selbst verbaut ist

Das ist ein von Hoymiles entwickeltes und FCC freigegebenes Modul, wie 
auf Seite 1 des Threads schon verlinkt wurde:
https://fcc.report/FCC-ID/2ARNB-HM2401/
Macht es sicher einfacher mit der Zulassung, das als Modul auszulagern, 
sonst müssten sie vermutlich jeden Inverter einzeln zertifizieren 
lassen...

Im Endeffekt ist es aber immer die gleiche Funkschnittstelle. Die DTU 
(Lite) hat es nicht als Modul sondern direkt onboard.
Bei der DTU Lite kommt über SPI vom NRF24LE1E keine Kommunikation - ich 
gehe davon aus, dass es bei den Modulen nicht anders ist. Jemand hatte 
mal vorgeschlagen, den NRF24LE1E Flash auszulesen und den Code zu 
reassemblieren, um so evtl. einen Hinweis auf die darin laufende 
Software und das Channel-Hopping zu bekommen. Was bräuchte ich denn 
dazu?

[Ziyat T. (toe_c)]

Herbert K. schrieb:
> und noch eines aus dem MI-1200

Hallo Herbert, konntest du den MI1200 schon ansprechen?

[Herbert K. (avr-herbi)]

Ziyat T. schrieb:
> Hallo Herbert, konntest du den MI1200 schon ansprechen?
Hallo Ziyat, ich habe selbst den MI1200 nicht. Ich habe HM350/400.

[isnoAhoy (Gast)]

Hallo martin (Gast),

das mit dem einen Standard nRF24 Modul von Hoymiles HM2401 klingt 
logisch. Da spart man sich sicher einen Haufen Papierkram auf diese Art 
und Weise. Deswegen ist das Modul wahrscheinlich auch mit einer Platte 
abgeschirmt, damit es eben ein Standardtestobjekt für die EMV Messungen 
ist.
Hier die anderen FCC Reports von Hoymiles:
https://fcc.report/company/Hoymiles-Converter-Technology-Co-L-T-D

Der Microprozessor auf der Platine ist ein STM32F402/STM32F407 und ich 
nehme auch an der Port CN201_NC ist ein SWD / JTAG Port.

@Ziyat T., ich konnte die letzte Ziffer der MCU auf der DTU-Pro nicht 
lesen, kannst Du diese bitte nochmal mit Adleraugen erspähen und ggf. 
bestätigen ? Auch eine FCC-ID der DTU-Pro wäre hilfreich um diese ggf. 
in den einschlägigen Datenbanke zu finden. Danke!


Auf der Suche nach der FCC ID der DTU-Pro habe ich auch noch ein Projekt 
von Arek Kubaki gefunden mit dem man die DTU-Pro per Modbus steuert:
https://github.com/ArekKubacki/Hoymiles-Plant-DTU-Pro


Für das Auslesen des Flash Speichers brauchst Du im Prinzip OpenOCD und 
einen Debugger, z.B. ein bluepill STM32 oder eines der üblichen 
USB-Dongles STLinkV2 / JLink ab 6 Euro oder direkt mit dem Raspberry Pi 
als Interface.

Dann bringt man den nRF24 oder auch den STM32F4x in den JTAG / SWD Modus 
und kann ihn dann anhalten bzw. den Flash langsam auslesen.

OpenOCD startet man mit mehreren Config Files, hier eines für das 
Interface, mein STLinkV2 USB Dongle und als zweites die Zielarchitektur 
/ CPU, die man steuern / debuggen möchte:

openocd -f interface/stlink.cfg -f target/stm32f4x_stlink.cfg

https://www.openocd.org/doc/html/Flash-Commands.html

Den Flash Speicher selbst kann man dann mit Ghidra (OpenSource aus dem 
Sonder-Programm der CIA) zurück zu C dekompilieren, wenn man kein IDA 
Pro sein Eigen nennt.

CAVE CANEM: Zu beachten ist dass evtl. auch die Read Out Protection 
aktiviert sein kann. I.d.R. machen das die Produzenten aber m.W. aus den 
selben Gründen nicht wie wir, es ist einfacher den Code überzubügeln 
ohne die ganze Security =^/

https://stackoverflow.com/questions/32509747/stm32-read-out-protection-via-openocd

[isnoAhoy (Gast)]

Prima, hier (https://fccid.io/2ARNB) gibt es neben den bekannten drei 
Prüfberichten auch noch das Sub-1G Modul HMS10.

* 2ARNB-HMS10 Sub-1G Module
* 2ARNB-HM2401 2.4G RF Module
* 2ARNB-MI1200 Microinverter
* 2ARNB-DTUW100 Data Logger

Mit einem kompletten UserGuide und den Pin Belegungen:
https://fccid.io/2ARNB-HMS10/User-Manual/User-manual-5204741

2.2   Pin Definition
This Table 1 describes the interface pins.

Table 1 HM2401 interface pins

NO.   Symbol   I/O Type   Function
1     Gnd      P          Power supply reference ground pin
2     NC       I          Null pin, no internal connection
3     P1.5     I/O        RESERVED, P1.5, which is connected to P1.5 on 
the IC
4     P1.6     I/O        RESERVED, P1.6, which is connected to P1.6 on 
the IC
5     P0.1     I/O        RESERVED, P0.1, which is connected to P0.1 on 
the IC
6     P0.6     I/O        RESERVED, P0.6, which is connected to P0.6 on 
the IC
7     NC       I/O        Serial peripheral interface clock pin
8     GND      P          Power supply reference ground pin
9     RXD      I/O        UART_RX, which is connected to P0.4 on the IC
10    TXD      Output     UART_TX, which is connected to P0.3 on the IC
11    GND      P          Power supply reference ground pin
12    VCC      P          Power supply pin
13    PRG      I/O        Set high to enter flash programming mode
14    SCK      I/O        Serial peripheral interface clock pin
15    RST      I/O        Hardware reset pin (active at a low level)
16    GPIO     I/O        Reserved
17    MI       I/O        Reserved
18    SCN      I/O        Reserved
19    GND      P          Power supply reference ground pin
20    GND      P          Power supply reference ground pin

4.1 NRF Channel List
Depending on the program, the module can work on 915MHz for North 
America and 868MHz for Europe. Unless necessary, it’s forbidden to 
change the module program.

sic

[isnoAhoy (Gast)]

Sorry for spamming, das HMS2401 enthält ebenfalls die gesuchte Pin 
Belegung, nur leicht geändert. Selbst die Tabellenüber/-unterschrift 
scheint prinzipiell beides mal "HM2401 interface pins" zu sein:

UserGuide und den Pin Belegungen:
https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285

2.2 Pin Definition
This Table 1 describes the interface pins.

Table 1 HM2401 interface pins

NO.   Symbol   I/O Type   Function
1     Gnd      P          Power supply reference ground pin
2     NC       I          Null pin, no internal connection
3     P1.5     I/O        RESERVED, P1.5, which is connected to P1.5 on 
the IC
4     P1.6     I/O        RESERVED, P1.6, which is connected to P1.6 on 
the IC
5     P0.1     I/O        RESERVED, P0.1, which is connected to P0.1 on 
the IC
6     P0.6     I/O        RESERVED, P0.6, which is connected to P0.6 on 
the IC
7     SCK      I/O        Serial peripheral interface clock pin
8     GND      P          Power supply reference ground pin
9     RXD      I/O        UART_RX, which is connected to P0.4 on the IC
10    TXD      Output     UART_TX, which is connected to P0.3 on the IC
11    GND      P          Power supply reference ground pin
12    VCC      P          Power supply pin
13    PRG      I/O        Set high to enter flash programming mode
14    SCK      I/O        Serial peripheral interface clock pin
15    MO       O          Serial peripheral interface data output pin
16    MI       I          Serial peripheral interface data input pin
17    SCN      I/O        Serial peripheral interface Chip selection pin
18    RST      I/O        Hardware reset pin (active at a low level)
19    GND      P          Power supply reference ground pin
20    GND      P          Power supply reference ground pin

3.2 Summarize the specific operational use conditions
**This module can be used in DTU, micro-converter and other equipment**. 
The input voltage to the module should be nominally 1.9~3.6 VDC and the 
ambient temperature of the module should not exceed 80°C. HM2401 uses a 
PCB antenna with max antenna gain 2 dBi. If the antenna needs to be 
changed, the certification should be re-applied.

4. Basic Operation
4.1 NRF Channel List
Depending on the program, the module can work on 2403, 2423, 2440, 2461 
or
2475MHz. Unless necessary, it’s forbidden to change the module program.

6. Technical Data
Model             HM2401
Type              2.4G RF
Channel List      2403, 2423, 2440, 2461, 2475MHz
Modulation Type   GFSK
Antenna Gain      2dBi
Working Voltage   1.9~3.6V
Power Consumption 40mW typical

[Heinz R. (heijz)]

Ich bekomme merkwürdigerweise die Ahoy-Software nicht zum laufen

Auf der Konsole kommt nur

Requesting Inverter SN 116474903203
Transmit 27 | 15 74 90 32 03 78 56 34 12 80 0B 00 62 87 96 11 00 00 00 
05 00 00 00 00 09 81 AC
Error while retrieving data: last frame missing: Request Retransmit
Transmit 27 | 15 74 90 32 03 78 56 34 12 80 0B 00 62 87 96 11 00 00 00 
05 00 00 00 00 09 81 AC
Error while retrieving data: last frame missing: Request Retransmit

Merkwürdigerweise funktioniert das Ganze mit Hubis NRFSendRcv - einen 
Hardwarefehler kann ich somit eigentlich ausschließen?

Das Thema IRQ an D1 oder D3 ist mir bekannt, auch ein flashen einer 
blank.bin brachte nichts

Hat jemand zufällig ähnliche Erfahrungen und eine Lösung gefunden?

[Daniel R. (daniel92)]

Hallo Heinz R,

dieses Problem hatte ich auch. Prüf mal ob im Webinterface auch die 
S.Nr. hinterlegt ist vom WR.

Danach sollte es gehen. :)

[Harald (Gast)]

Daniel R. schrieb:
> Hallo Heinz R,
>
> dieses Problem hatte ich auch. Prüf mal ob im Webinterface auch die
> S.Nr. hinterlegt ist vom WR.
>
> Danach sollte es gehen. :)


Was glaubst Du was das wohl bedeutet Du Quasselstrippe:
Requesting Inverter SN 116474903203

[Daniel R. (daniel92)]

Joa bei so einer patzigen Antwort kann ich auch nicht viel sagen.

Kann ja sein das ein Zahlendreher drinnen ist. Hatte auch mal zum Testen 
123456 geschrieben und wurde im Log angezeigt.

[Jan-Jonas S. (janjonas_s)]

Heh, Harald. Trollen ist meine Aufgabe !!1!

Ist denn 1164... richtig? Sollte das nicht 1161 sein?

Was noch merkwürdig ist, wenn kein Frame empfangen wurde kann man auch 
kein retransmit anfordern. Weil ein einzelnes Frame bzw. damit auch 
automatisch, und das letzte Frame nicht retransmittet werden kann.

[Harald (Gast)]

> Weil ein einzelnes Frame bzw. damit auch
> automatisch, und das letzte Frame nicht retransmittet werden kann.

Niemand kann diesen Satz verstehen.

[Heinz R. (heijz)]

Jan-Jonas S. schrieb:
> Ist denn 1164... richtig? Sollte das nicht 1161 sein?

Danke Jan-Jonas, das war der entscheidende Tipp, es läuft jetzt

Ich hatte mal mit dem Handy ein Foto vom WR gemacht , die Nummer 
eingegeben
Aber ich hatte vergessen das ich danach auch mal ein Foto von einem 
HMS.2000 gemacht habe :-)

Wollte es gerade hier hochladen - sehe es mir genau an - ich Depp...

Viele Grüße

[S. W. (bd72)]

Guten Abend,

ich habe einen HM-600 und würde gern die Daten auslesen. Hierfür wollte 
ich einen ESP-01 sowie  das Funkmodul NRF24L01+. Nun stehe ich vor der 
Frage, wie verbinde ich beide Module miteinander. Das ESP-01 scheint ja 
den SPI-Bus nicht nach außen zu legen, und das wird für die 
Kommunikation mit dem NRF24L01+ benötigt. Sehe ich das richtig? Also 
bleibt mir nur, einen anderes ESP8266-Modul zu besorgen, welches SPI 
über Pins verfügbar macht?

Viele Grüße

[Lukas P. (lumapu)]

Harald schrieb:
>> Weil ein einzelnes Frame bzw. damit auch
>> automatisch, und das letzte Frame nicht retransmittet werden kann.
>
> Niemand kann diesen Satz verstehen.

Doch ich ;-)
Ich habe es so implementiert, dass beim Fehlen des letzten Pakets 
nochmal alles mit dem gleichen Zeitstempel angefordert wird.

[Daniel R. (Gast)]

S. W. schrieb:
> Sehe ich das richtig? Also bleibt mir nur, einen anderes ESP8266-Modul
> zu besorgen, welches SPI über Pins verfügbar macht?

Moin S.W.,

so sehe ich das auch.
Das sollte ja kein Problem sein, ein neues ESP Kosten ja fast nichts. :)

Ich empfehle dir ein ESP32, dann kannst du für spätere Projekte diesen 
auch weiter verwenden.

[Chris (Gast)]

Kurze Info:
Seit dem Update von Ahoy 0.3.9 auf Ahoy Version 0.4.5 ist die MQTT 
Verbindung viel stabiler. Vorher ist die Verbindung nach max. 5h 
abgebrochen. Aktuell steht die Verbindung seit 31h.

[Jan-Jonas S. (janjonas_s)]

Ich nehm (fast) alles zurück. Von wegen man kann das letzte Paket nicht 
retransmitten...

Poll inverter 114172220143
2022-05-21 18:08:58.192865 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 89 0e 9a 00 00 00 05 00 00 00 00 80 20 5e
2022-05-21 18:08:58.244718 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 41 00 68 01 4e 01 42 00 6a 01 56 00 01 8d
2022-05-21 18:08:58.285863 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 01 60 00 00 f8 70 06 a3 06 82 08 e0 13 8b 02 85 a8
Error while retrieving data: Missing packet: Last packet 2
2022-05-21 18:08:58.788941 Transmit 11 | 15 72 22 01 43 78 56 34 12 83 8c
2022-05-21 18:08:58.832128 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 1c 03 e8 01 19 00 07 18 15 f3
2022-05-21 18:08:59.334726 Payload: 00 01 01 41 00 68 01 4e 01 42 00 6a 01 56 00 01 01 60 00 00 f8 70 06 a3 06 82 08 e0 13 8b 02 85 00 00 00 1c 03 e8 01 19 00 07 18 15
2022-05-21 18:08:59.334726 Decoded: 28.1 phase0=voltage:227.2, current:2.8, power:64.5, frequency:50.03 string0=voltage:32.1, current:1.04, power:33.4, total:65.888, daily:1699 string1=voltage:32.2, current:1.06, power:34.2, total:63.6, daily:1666

Edit. Mistiges Mistforum kann kein Markdown

[Sorbit (Gast)]

Aber sicher Herr Düsentrieb, die sind ja auch binärkompatibel.
> Ich empfehle dir ein ESP32, dann kannst du für spätere Projekte diesen
> auch weiter verwenden.

[Sorbit (Gast)]

Der Akkusativ wäre auch noch passend.
Aber das lernt wohl niemand mehr in der Schule, traurig.


😪😪😪😪

[Thomas H. (thomasm17)]

Hallo,

ich lese hier sonst nur mit und hab mich jetzt angemeldet und komme 
leider mit einer OT Frage

Hat jemand auf dem DTU Pro Board schon eine serielle Schnittstelle oder 
eine Terminalschnittstelle gefunden? Meine DTU ist tot. Weder per IP 
erreichbar, noch spannt sie ein WLAN auf.

Danke

[Daniel R. (daniel92)]

Moin Thomas,

laut einer Excel-Tabelle "Hoymiles-SerialNumbers.xlsx" gibt es nur einer 
der ein DTU-Pro hat (indirekt noch einer).

Die Frage, ist es frisch gekauft oder gebraucht gekauft?
Es gibt Bilder die vom inneren einer DTU zeigen 
"DxTxUxPxRxOinnereien.zip", hier wird auch eine Schnittstelle gezeigt.

Andi schrieb:
> CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn
> unteranderem zu Programmieren oder Debuggen.

- SPI Schnittstelle -

Ob jemand sich da schon reingehängt hat, kann ich aktuell nicht sagen. 
Soweit ich weiß haben wir keine weiteren Infos darüber.

Kannst ja gern mal schauen.

Ansonsten zum Problem:
Erstmal die einfachen Fragen, Liefert das Netzteil die Spannung? Nicht 
das hier der Fehler liegt. :P

2.) Wenn du es am LAN-Port hängst bekommst du ein Link? - LED leuchtet, 
oder die gegenstelle (Switch) blinkt fröhlich?

3.) Netzwerkkabel defekt? - Kann ja sein^^
4.) Sieht man sonst irgendeine Status LED?


Gruß Daniel

[Tobi D. (tobidd)]

hi zusammen,

hab jetzt meine esp version von 4.4 auf 4.8 geupdatet. jetzt gibt es im 
setup die möglichkeit dort die maximale wp vom angeschlossenen modul 
anzugeben. wofür ist das gut? davon abgesehen das ich bei meinem hm-400 
nur 1 modul anschließen kann, habe ich die auswahl von 4 modulen zum 
eintragen.

offtopic.: hat jemand schon nen gehäuse für nen wemos d1mini und dem 
nrf24 modul mit der externen antenne für nen 3d drucker konstruiert? bei 
thingi hab ich nix passendes gefunden mit der kombi

[Thomas H. (thomasm17)]

Daniel R. schrieb:
> Moin Thomas,
>
> laut einer Excel-Tabelle "Hoymiles-SerialNumbers.xlsx" gibt es nur einer
> der ein DTU-Pro hat (indirekt noch einer).
>
> Die Frage, ist es frisch gekauft oder gebraucht gekauft?
> Es gibt Bilder die vom inneren einer DTU zeigen
> "DxTxUxPxRxOinnereien.zip", hier wird auch eine Schnittstelle gezeigt.
>
> Andi schrieb:
>> CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn
>> unteranderem zu Programmieren oder Debuggen.
>
> - SPI Schnittstelle -
>
> Ob jemand sich da schon reingehängt hat, kann ich aktuell nicht sagen.
> Soweit ich weiß haben wir keine weiteren Infos darüber.
>
> Kannst ja gern mal schauen.
>
> Ansonsten zum Problem:
> Erstmal die einfachen Fragen,
  Liefert das Netzteil die Spannung? Nicht: Netzteil hab ich schon 
gewechselt
> das hier der Fehler liegt. :P
>
> 2.) Wenn du es am LAN-Port hängst bekommst du ein Link? - LED leuchtet,
> oder die gegenstelle (Switch) blinkt fröhlich?
  LEDs blinken alle
>
> 3.) Netzwerkkabel defekt? - Kann ja sein^^
Switch zeigt an, das Rx und Tx Pakete drüber gehen und link ist auf 
100Mbit
er holt sich aber keine DHCP Adresse mehr.

Anderer Switch und anderes NIC Kabel erfolglos getestet.

muss mir dann einen Notebook mit Wireshark fertig machen und die 
Kommunikation mit der betreffenden MAC ansehen

> 4.) Sieht man sonst irgendeine Status LED?
Die Status-LEDs zeigen, dass kein Internet und keine Cloud da ist.
Anderer Switch und anderes NIC Kabel getestet

PS:
Das Gerät war ein Neukauf und lief 18 Monate störungsfrei.

>
>
> Gruß Daniel

Dankeschön ..

Gruß Thomas

[Daniel R. (daniel92)]

Hi,

habe meins nun auch geupdated 0.4.4 auf 4.8.
Aktuell habe ich damit nun immense WiFi probleme.

Ping wird ausgeführt für 192.168.10.149 mit 32 Bytes Daten:
Antwort von 192.168.10.149: Bytes=32 Zeit=46ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=85ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=99ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=2ms TTL=255

Ping-Statistik für 192.168.10.149:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 2ms, Maximum = 99ms, Mittelwert = 58ms

Firefox (v100.0.2) lädt sich ins Nimmerleinstag. =(
ESP Serial Verbindung bleibt leer, irgendwann schmeist er mir paar logs 
entgegen.

@Thomas: Uiii, das ist ja Interessant... hmm sag mal bescheid wie weit 
du gekommen bist. Wobei, ich habe die Vermutung (da es länger ohne 
Probleme lief), das hier eventuell am Board probleme gibt.

Ich kenn es nur von einem 48-Port Switch (uralt), das hier ein DC/DC + 
Elkos flöten gegangen sind. Aber da es an sich "Neu" ist, hmm ... :/

Zur Not Werksreset durchführen?

[Andi (Gast)]

Die WLAN Probleme mit der neuesten Version kann ich ebenfalls 
bestätigen.
Ca. 3 Sekunden nach dem ersten Success + Inverter available scheint der 
ESP abzuschmieren(Builtin-LED bleibt aus, Webif/ESP nicht mehr 
erreichbar), dann fliegt er sehr oft aus dem WLAN(scheint hin und wieder 
sehr langsam erreichbar zu sein). Ist am einfachsten zu testen, wenn man 
ihn hochfährt und direkt danach auf der Statusseite bleibt, da sieht man 
das Pairing und danach bleibt die Uptime und alle anderen Zähler stehen.
Ich habe mich jetzt nicht weiter damit rumgeschlagen und bin erstmal 
wieder auf die 0.4.4 zurück.

[Lukas P. (lumapu)]

Andi schrieb:
> Die WLAN Probleme mit der neuesten Version kann ich ebenfalls
> bestätigen.
> Ca. 3 Sekunden nach dem ersten Success + Inverter available scheint der
> ESP abzuschmieren(Builtin-LED bleibt aus, Webif/ESP nicht mehr
> erreichbar), dann fliegt er sehr oft aus dem WLAN(scheint hin und wieder
> sehr langsam erreichbar zu sein).

Sehr schade, könnt ihr mir sagen welchen WR ihr habt. Es genügt 1, 2 
oder 4 Kanäle. Gerne auch über Github issues.
Ich kann keine Abstürze sehen (mehr als 6h Uptime) und habe das 4-Kanal 
Setup.

[Andi (Gast)]

@lumapu
Da ich die Version nur kurz getestet habe, kann ich nur Aussagen aus dem 
Kopf machen und nicht 100% genau Infos liefern, darum habe ich kein 
Issue im Git aufgemacht.
Ich habe einen HM800, also 2 Eingänge.
Ich habe mir den Code noch nicht so genau angesehen, aber rein vom 
Gefühl her ist die LED normalerweise an und beim Rx und/oder Tx flackert 
sie kurz, beim Fehlerfall war sie allerdings dauerhaft aus und im Router 
war der ESP nicht mehr verbunden, also scheint er sich wohl komplett 
aufzuhängen an irgendeiner Stelle nach den ersten Daten. Jetzt weiß ich 
aber nicht mehr genau, ob der nach paar Sekunden wieder langsam 
erreichbar war oder weil ich Resettet habe. Ich hatte auch beim 
rumspielen bei dem Fehler auf einmal alle Daten verloren(macht der ESP 
trotz einfach Stecker ziehen ja normalerweise nicht). Deswegen bin ich 
mir mit der WLAN aussage nicht ganz sicher, eventuell war die LED und 
WLAN auch nach dem Verlorengehen der Daten aus.

Was ich aber sehr sicher sagen kann ist, dass der Zugriff auf das Webif 
grottig bis hin zu nicht erreichbar war, als er noch die gespeicherte 
Konfig hatte und das kurz nachdem der Inverter als available in den paar 
Zeilen auf dem Homescreen war.
Vielleicht kann ich es ja morgen nochmal genauer testen, wenn es bis 
dahin nicht schon behoben ist :-)

[Lukas P. (lumapu)]

Tobi D. schrieb:
> jetzt gibt es im
> setup die möglichkeit dort die maximale wp vom angeschlossenen modul
> anzugeben. wofür ist das gut? davon abgesehen das ich bei meinem hm-400
> nur 1 modul anschließen kann, habe ich die auswahl von 4 modulen zum
> eintragen.

Der ESP berechnet die Einstrahlung in Prozent, sodass man sehen kann wie 
gut die Module ausgerichtet sind / wie klar die Luft ist.
Während man die Wechselrichter einträgt hat man noch keine Möglichkeit 
zu wissen wie viele Kanäle es geben wird, daher immer die Maximale 
Anzahl von 4.

[Daniel R. (daniel92)]

Moin Lukas,

Github Issue ist raus. Hoffe passt, wenn du mehr Infos brauchst einfach 
melden. :)

[Herbert K. (avr-herbi)]

Lukas P. schrieb:
.... wofür ist das gut? davon abgesehen das ich bei meinem hm-400
>> nur 1 modul anschließen kann....

Das ist ja wohl Quatsch !
Natürlich kann man da auch mehr Module anschließen !
Es ist halt nur 1 MPPT Eingang da mit 1 Paar Steckkontakten. Ich habe 
z.B. am HM350 2 Stk. Module. Das kommt ja auf die Daten der Module und 
der WR drauf an, das es zusammenpaßt zu Strömen, Spannungen und 
Leistungen.

[Tobi D. (tobidd)]

Ja natürlich kann ich auch mehrere module in Reihe oder parallel im 
hm-400 anschließen aber dann müssen die Werte von allen Modulen meiner 
Meinung nach dann trotzdem in das erste Feld eingetragen werden, da ja 
nur 1 Eingang da ist

[Daniel M. (daniel_m821)]

Ich meld mich auch mal wieder, nachdem GreenAkku das TSUN-Gateway statt 
mit 1-2 Tagen Lieferzeit dann nach knapp 6 Wochen doch endlich mal 
verschickt hat.

Gut sichtbar ist der Controller STM32F103, danach kommt der UART-WIFI 
Converter und selbstverständlich der NRF 24LE1E.

Das Platinenlayout ist relativ ähnlich zu Hoymiles.
Ich schaue mir die Kommunikation an, wenn ich weiß, wo ich was 
sinnvolles aus der Platine bekomme. Die Rx/Tx Pins sind bei mir 3 
Tastpunkte in etwas anderer Anordnung.

Die ID'S laufen nach dem Muster: 10D573118xxx
Die x sind laufende Nummerierung. Habe mehrere hier.

Ist eher Hyperterminal oder Putty für die serielle Verbindung ratsam?
Gibt es irgendwas, wo ich besonderen Fokus drauflegen sollte?

lg
Daniel M.

edit: Bilder nachgereicht, nachdem es erstmal nicht ging

[Siggi U. (sude)]

Hallo,
gibt es eigentlich einen praktischen Grund für die Beschränkung auf drei 
Geräte im ESP8266? Ich habe 4 HM-1500 und würde die gerne mit einem ESP 
auslesen.

[Jan-Jonas S. (janjonas_s)]

Hi Siggi,
glaube an so viele Inverter in einem Setup hat hier bisher keiner 
gedacht. Ich währe schon froh ein Setup zum testen für 2 gleichzeitig zu 
haben.
Python hat da jedenfalls kein Limit gesetzt, ist aber glaube ich noch 
nie mit mehr als einem gleichzeitig in Betrieb gewesen. Theoretisch 
sollte es gehen.

Hat jemand die rpi-Variante mit mehr als einem am Laufen?

[Daniel R. (daniel92)]

Habe zwar ein rpi, jedoch nur ein WR.

[Lukas P. (lumapu)]

Siggi U. schrieb:
> Hallo,
> gibt es eigentlich einen praktischen Grund für die Beschränkung auf drei
> Geräte im ESP8266? Ich habe 4 HM-1500 und würde die gerne mit einem ESP
> auslesen.

Klar gibt es die Option, schon sehr lange:
https://github.com/grindylow/ahoy/blob/2199d46890ea826a19068253c36e7b4973b65775/tools/esp8266/config.h#L33

Der Code ESP ist theoretisch auch nicht limitiert - nur wird irgendwan 
der Speicher im Chip selbst knapp.

[Herbert K. (avr-herbi)]

Hallo, ich habe per ESP8266 und Hubis Ur-Version 4 WR die ich Seriell 
abfrage wenn mir danach ist. Funktioniert auch schon mal den ganzen Tag 
und schreibt schön ein LOG voll auf´m PC. Reicht mir so erst mal um zu 
sehen, das die WR tun, was sie sollen  :-)

[Siggi U. (sude)]

Alles klar, dann baue ich mir mal eine Version mit 4 WR. Kann dann ja 
berichten ob es klappt.

[Ziyat T. (toe_c)]

Thomas H. schrieb:
> Hallo,
>
> ich lese hier sonst nur mit und hab mich jetzt angemeldet und komme
> leider mit einer OT Frage
>
> Hat jemand auf dem DTU Pro Board schon eine serielle Schnittstelle oder
> eine Terminalschnittstelle gefunden? Meine DTU ist tot. Weder per IP
> erreichbar, noch spannt sie ein WLAN auf.
>
> Danke

Hallo Thomas
DTU-Pro hat noch Ethernet(RJ45) und RS485-Modbus SS

[Peter L. (leliep)]

Tobi D. schrieb:
> offtopic.: hat jemand schon nen gehäuse für nen wemos d1mini und dem
> nrf24 modul mit der externen antenne für nen 3d drucker konstruiert? bei
> thingi hab ich nix passendes gefunden mit der kombi

Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich 
ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls 
jemand Interesse hat, stelle ich die .stl gern zur Verfügung.

[Lars B. (docbmuc)]

Hi Daniel,

Daniel M. schrieb:

>
> Das Platinenlayout ist relativ ähnlich zu Hoymiles.

ich würde mal meinen, dass TSUN und Hoymiles Geräte eher sowas wie 
"bei-der-Geburt-getrennte-Zwillinge" sind. Die Dinger - auch die DTUs - 
fallen sicherlich vom selben Band. ;-)

> Ich schaue mir die Kommunikation an, wenn ich weiß, wo ich was
> sinnvolles aus der Platine bekomme. Die Rx/Tx Pins sind bei mir 3
> Tastpunkte in etwas anderer Anordnung.

Ich weiss nicht, ob Dir die UART Testpoints des STM etwas nützen. Um die 
Kommunikation zwischen STM und Nordic belauschen zu können, musst Du 
Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO 
(Output Nordic) und SCK (Clock der SPI) mit einem entsprechenden Logic 
Analyzer oder SPI Sniffer verbinden und mitloggen... :)

Mich würde es allerdings sehr wundern, wenn das Protokoll was ganz 
anderes wäre als bei den HMs.

LG,
Lars

[martin (Gast)]

Lars B. schrieb:
> Um die
> Kommunikation zwischen STM und Nordic belauschen zu können, musst Du
> Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO
> (Output Nordic) und SCK (Clock der SPI)

Nein, bei der UART bist du schon richtig. Wie schon mehrfach im Thread 
beschrieben, findet über die SPI-Schnittstelle des NRF keine 
Kommunikation statt, die ist nur zur Programmierung des NRF-internen 
Controllers - zumindest bei der HM-DTU. Wird dann hier vermutlich 
genauso sein.

[Herbert K. (avr-herbi)]

Heute gabs 2 neue Videos von hoymiles:

1)
https://www.youtube.com/watch?v=ed7rJvYVuJg
Ich sag da mal lieber nix zu. Kann sich jeder seine Meinung selbst 
bilden. Einzig interessant ist der Unterschied zu den DTU..."S" Modellen 
bei der Reichweite.

2) Anschauen kann man sich auch sparen:
https://www.youtube.com/watch?v=9GbAhf3pU7I

[rosch99 (Gast)]

Peter L. schrieb:
> Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich
> ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls
> jemand Interesse hat, stelle ich die .stl gern zur Verfügung.

Hallo Peter,
ich hätte Interesse an dem .stl :-)
Bitte hier oder auf github hochladen.

Grüße
rosch

[Peter L. (leliep)]

rosch99 schrieb:
> Peter L. schrieb:
>> Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich
>> ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls
>> jemand Interesse hat, stelle ich die .stl gern zur Verfügung.
>
> Hallo Peter,
> ich hätte Interesse an dem .stl :-)
> Bitte hier oder auf github hochladen.
>
> Grüße
> rosch

https://github.com/grindylow/ahoy/pull/59

:-)

[Tom M. (tom_m)]

Hab mal auf die schnelle ein Gehäuse gebastelt für die mit externer 
Antenne.
Bisschen filigran aber lässt sich drucken.
(Sorry, bin leider kein Zeichen-Profi ;-) )

https://www.thingiverse.com/thing:5395556



Grüße
Thomas

[Bernd (Gast)]

sorbit schrieb:
> Hat jemand das schon einmal "angezapft" um ein eigenes Monitoring ohne
> deren Cloudzwang zu realsieren?
>
> Es gibt offensichtlich einen "Adapter", der das "2,4 GhZ Signal umsetzt
> und dann via WLAN an deren Cloudsysteme versendet.

Eine Anmerkung von mir zur Ausgangsfrage:
Mit einer DTU-PRO von Hoymiles für knapp 200 € kann man zwar Daten auch 
in die Cloud senden. Muss man aber nicht. Man kann die DTU-PRO aber über 
MODBUS-TCP lokal auslesen und alle Daten aller angeschlossenen 
Wechselrichter auslesen.

Ein konkretes Beispiel mit iobroker findet ihr unter 
https://forum.iobroker.net/topic/55115/gel%C3%B6st-ben%C3%B6tige-hilfe-modbus-tcp-hoymiles-hm-1500-dtu-pro/6

[Jan-Jonas S. (janjonas_s)]

Hi Bernd,

das ist wohl richtig. Allerdings haben wir Spaß am reverse Engineering 
und wollen die Daten nach Mqtt bzw. Influx exportieren. Kann die DTU-Pro 
das auch?
Spaß bei Seite. Natürlich nicht.

Für 200€ kauft man sich lieber ein Panel mehr, anstatt die 
Wirtschaftlichkeit endgültig zu begraben. Wir machen das mit 20€ :)

Nichts desto Trotz brauchen wir die DTU-Pro um sie zu belauschen. Nicht 
um sie per Modbus-TCP zu befragen. Das kann jeder ^^
Denn wir wollen mehr Daten! ...und besser verstehen, was Hoymiles mit 
ihrem trojanischen Pferd so in unseren Netzen treibt.

Gruß,
Jan

[Lars B. (docbmuc)]

martin schrieb:
> Lars B. schrieb:
>> Um die
>> Kommunikation zwischen STM und Nordic belauschen zu können, musst Du
>> Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO
>> (Output Nordic) und SCK (Clock der SPI)
>
> Nein, bei der UART bist du schon richtig. Wie schon mehrfach im Thread
> beschrieben, findet über die SPI-Schnittstelle des NRF keine
> Kommunikation statt, die ist nur zur Programmierung des NRF-internen
> Controllers - zumindest bei der HM-DTU. Wird dann hier vermutlich
> genauso sein.

richtig - mein Fehler! Der UART zwischen dem GD Controller und dem nRF 
liegt ja IMHO auf den beiden Testpoints beim Knopf der DTU...

Sorry für die Verwirrung,
Lars

[Daniel R. (daniel92)]

Hallo zusammen,

bei der Bucht wird ein DTU-Pro verkauft. Was denkt ihr, macht es Sinn 
darauf zu Bieten? Oder könnte es sein, das die DTU beim Hersteller mit 
einem Account verknüpft ist und diese eventuell probleme aufkommen 
könnte?

Thomas H. schrieb:
> Meine DTU ist tot.

Könnte ich eventuell dein DTU-Pro mir anschauen, vielleicht kann man da 
noch was retten? :)

Gruß Daniel

[Maik R. (bastelbarney)]

Servus,

Martin G. schrieb vor einer ganzen Weile im Beitrag #7016238:
> Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in
> Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier
> unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe
> geschaltet?

Zumindest schaltet der HM-1500  Gen3  H00.04.00 / V01.00.16 seine 4 
Eingänge nicht vor der separaten Messung zusammen, denn in der Cloud und 
S-Miles-App sehe ich separate, leicht unterschiedliche  Leistungsdaten 
meiner 4 identischen Panels. Aber nur als DC-Leistung. DC current und DC 
voltage bekomme ich nicht.

Habe seit gestern endlich meine DTU-Wlite  Gen3  H06.01.01 / 
V00.03.05. Gibt's in Mödling (AT) erheblich günstiger als bei den 
Preußen.

Habe aber (noch) kein Sniffer-Equipment und die Panels nur provisorisch 
auf Holzgestell. Stockschrauben, Bituplan und ein regenfreier Tag fehlen 
noch. Wenn die Mechanik erledigt ist, steige ich mit Eurer Starthilfe 
gerne mit ins Sniffen ein. Erste ESP8266 Erfahrungen mit ArduinoIDE und 
VSCode habe ich schon mit ein paar Mods an Airrohr/DNMS gesammelt.

Aber Warnung: bei HF-Technik bin ich keine Hilfe. Hatte ich zugunsten 
Stromrichterantriebstechnik abgewählt (WPU-ET-m88-sg3) und auch davon 
inzwischen vieles vergessen :-(.

[Maik R. (bastelbarney)]

Daniel R. schrieb:
> bei der Bucht wird ein DTU-Pro verkauft. Was denkt ihr, macht es Sinn
> darauf zu Bieten? Oder könnte es sein, das die DTU beim Hersteller mit
> einem Account verknüpft ist und diese eventuell probleme aufkommen
> könnte?

Wenn Du (wie ich) ein Installateur-Account bei HOYMILES hast und der 
Verkäufer den DTU bei sich austrägt (oder der Verkäufer Dir seine 
Accountdaten überlässt), kannst Du das Ding nehmen. Ob man den DTU auch 
"kapern" kann, nur weil man die Seriennummer weiß? Ich hoffe nicht!
Vermutlich kann man ihn nur übernehmen, wenn man Seriennummer und Zugang 
zum internen WLAN-AP hat. Den spannt er wie viele ESP-Devices auf, wenn 
er seinen bisherigen externen AP nicht findet.
In JEDEM FALL muss die Seriennummer auf dem Gehäuse noch lesbar sein, 
sonst kannst Du ihn nicht übernehmen!

Liegt gerade bei ca. 160€ und läuft noch 11 Stunden. Hatte ich auch in 
Erwägung gezogen, dann kam der W-Lite aber doch noch an. Zwei erlaubt 
die Finanzministerin nicht.

Wenn Du keinen Installateur-Account bei HOYMILES hast: ich könnte den 
DTU zur Not bei mir mit eintragen und Dir ein Kunden-Account darauf 
erstellen. Ich wäre dann quasi Dein Solateur und Du der Besitzer.

Servus,
BastelBarney

[Maik R. (bastelbarney)]

Maik R. schrieb:
> Wenn Du keinen Installateur-Account bei HOYMILES hast: ich könnte den
> DTU zur Not bei mir mit eintragen und Dir ein Kunden-Account darauf
> erstellen. Ich wäre dann quasi Dein Solateur und Du der Besitzer.

Argh! Das ginge natürlich nur, wenn ich einmal physischen Zugriff auf 
Deinen DTU habe!
Kann man im Grunde auch per TeamViewer oder so machen, aber das wird 
dann arg kompliziert, weil das Gerät, das Du mit der DTU per WLAN 
verbindest zusätzlich auch per 2. Netzwerkinterface per TeamViewer aus 
dem Internet erreichbar sein muß. Du willst nicht Deinen PC per TV an 
mich freigeben. Müßtest also erstmal einen separaten PC dafür einrichten 
(oder ein Live-Linux booten), nur zu diesem Zweck. Wenn das für Dich ein 
"kein Problem, mache ich oft" ist, wäre das ein Weg...

Ergo: Du brauchst ein Installateur-Account bei HOYMILES oder jemanden in 
Deiner Nähe, der einen hat.

Servus,
BastelBarney

[Maik R. (bastelbarney)]

Sergey S. schrieb:
> Guten Tag! Ich habe H M 600 114170810815
> und DTU W100 10D 373114359. Kann mir jemand helfen, die
> “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer
> gibt es nicht an, sagt, dass er selbst der Installateur ist.

Du benötigst das Installer-Konto nicht unbedingt. Der Verkäufer sollte 
Dir aber ein User-Account anlegen und geben. Damit greifst Du per 
global.hoymiles.com auf Deine Daten zu. Oder per "S-Miles-User App".

HTH,
BastelBarney

[Daniel R. (daniel92)]

Guten Morgen bastelbarney,

vielen dank für die Info. Ich verstehe nicht warum der Hersteller das so 
kompliziert macht... Oh mann. Naja an sich wäre es kein Problem, würde 
es sogar einfach zu dir schicken wenn es einfacher wäre, dann könntest 
du es später wieder zurück schicken (Wenn ich dich zwekcs Einrichtung 
richtig verstanden habe).

Ich kenne jemand der die WR verkauft, aber er hat bisher kein DTU-Pro im 
Sortiment.

Edit: Aktuell liegt der Preis in der Bucht bei EUR 157,00 (S.Nr lautet 
10f874435634, wie auf dem Bild zu sehen).

Da kann ich mir es gleich aus AT bestellen. - 
https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html

Gruß Daniel

[Daniel M. (daniel_m821)]

Guten Morgen zusammen,

wie erwartet, kochen TSUN und Hoylmiles ein ähnliches Süppchen.
Die Tastpunkte auf der Platine sind Rx/Tx zwischen dem NRF und meinem 
STM. Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein.
Die Verbindung läuft ebenfalls mit 125000 BAUD, war nicht so einfach, 
ein Programm zu finden, dass mir das unter Windows 10 auch in Hex 
ausgibt. Nutze dafür Realterm.

Die Requests sehen so aus und sind als capture.txt-Datei noch im Anhang:

7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F

Darauf die Antworten in der capture-rx.txt, allerdings unsortiert zu den 
Requests. Ich konnte noch nicht beides parallel anschauen, da mir die 
USB-Schnittstellen ausgegangen sind:

7E8963500316635003160157000E0961138601CB005900AE117F                                                                                                  
7E9163500316635003160157000E0962138601C1005300AE0A7F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160158000E0962138601CB005900AE1D7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160157000E0962138601C1005300AF0B7F                                                                                                  
7E8963500316635003160158000F0962138601CB005900AF1D7F                                                                                                  
7E9163500316635003160157000E0962138601C1005300AF0B7F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160158000F0962138601CB005900AE1C7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160158000F0962138601C1005300AE047F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160159000F0963138601EF005900AD3B7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160159000F0963138601E4005300AD227F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160159000F0963138601EF005900AD3B7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160159000F0963138701E4005300AE207F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E896350031663500316015900100963138701EF005900AE267F

7E896350031663500316014F00360960138806EB00A300DC917F

63500316 ist meine WR-ID. Auch hier wird diese 2x hintereinander 
aufgeführt, jedoch nicht in umgekehrter Reihenfolge.

Greife ich mir die letzten beiden Zeilen:
7E896350031663500316 0159 0010 0963 1387 01EF 00 5900 AE 26 7F
früh   Dezimal       345  16   2403 4999 495          174
7E896350031663500316 014F 0036 0960 1388 06EB 00 A300 DC 91 7F
später Dezimal       335  54   2400 5000 1771         220

7E916350031663500316 0159 000F 0963 1387 01E4 00 5300 AE 20 7F
früh  Dezimal        345  15   2403 4999 484          174
7E916350031663500316 0155 0036 0960 1388 06EE 00 9B00 DC AE 7F
später Dezimal       341  54   2400 5000 1774         220
DC V/10 | DC I/10 | AC V/10 | AC Frequenz/100 | AC Power/10 | ??? | 
Temperatur/10 | Daily Production/1000?

Modul 1 und 2 jeweils identifiziert über die 89 und 91 am Anfang. 7E ist 
der Beginn der Übertragung, 7F das Ende.
Eine CRC habe ich so nicht entdeckt, außer die vorletzten beiden Byte.

Von Abends habe ich zu den 88 und 92 noch diese Infos:
7E88635003166350031600020000000000008A7F
7E9263500316635003160002000000000000907F

Tagsüber:
7E88635003166350031600030000000000008B7F
7E9263500316635003160003000000000000917F

die 02 bzw. 03 Tagsüber ist der Modulstatus. Diese Nummer taucht auch in 
der Cloud auf:
Spekulation! - wird beobachtet
02 - MPPT inaktiv, Modul verbunden und arbeitet
03 - MPPT aktiv, Modul verbunden und arbeitet
05 - ? Modul liefert zu wenig Leistung
00 - Modul aus

Ich habe den Netzwerkverkehr zwischen DTU und Server aufgefangen. 
Mobiler Hotspot und Wireshark, Datei raw.txt:

a55600104291f008881173d510020001010116051c0910067800020a160350634110014f01350060098713bc069c009e0e0000d7000300000000000100000000000a160350634110025601340061098713bf0694008e0e0000d7000300000000000100000000001415

Hier haben wir meine DTU: 08881173d510 in umgekehrter Reihenfolge
Datum und Uhrzeit YYMMDDhhmmss: 16051c091006
Die WR-ID: 16035063 in umgekehrter Reihenfolge
DC- und AC-Daten, Produktion tägl. und gesamt sowie Modulstatus, 
Modulfehler-Zähler, Verbindungsstatus (Module?), Temperaturen.

Die Zeile oben ist etwa im gleichen Zeitraum übertragen worden als ich 
die einzelnen Daten (Zeile "später") abgegriffen habe. Meine Freundin 
hat mir geholfen, ein kleines Python-Script zu schreiben, mit dem ich 
die Daten dekodieren kann.
Das Script analyse.py ist sehr einfach gehalten, es erfüllt seinen 
Zweck, ist allerdings noch nicht auf dem Stand, dass man es groß 
braucht. Es analysiert nur die Daten, die an den Tsun-Server gehen.
Hier passiert automatisch alle 15min eine Übertragung mit allen Daten 
seitens der DTU ohne vorher einen Request des Server, weiterhin jede 
Minute ein Request der DTU nach der Uhrzeit mit passender Antwort vom 
Server.
Request: a500001047c62508881173d510020001013f15
Response: 
a50d001017c72508881173d510000201013f0016051c0a090878000100002715

Das dürfte zugleich eine Art Ping für den Server sein, dass die DTU noch 
online ist.
In der DTU kann ich Server- und Port des Ziel ändern, außerdem die 
Kommunikationseinstellungen zum USR-C210.

Da ich noch keinerlei Datentransfer durch die Luft gesehen habe, 
discover und pretender aus dem ahoy-Repo nichts finden, benötige ich 
hier etwas Starthilfe.
Ich habe noch einen Wemos-D1 mini hier, den ich gerne mit entweder ahoy 
oder dem anderen Prog flashen würde. Könnte mir jemand eine Vorlage 
dafür machen oder erklären, wo ich was ändern muss? Bin mit Arduino noch 
nicht ganz warm.

Vielen Dank für eure Hilfe :)

lg
Daniel M.

[Herbert K. (avr-herbi)]

Daniel M. schrieb:
> Guten Morgen zusammen,...

Guten Morgen Daniel M. !
Super Arbeit von Dir und Deiner Freundin !
Endlich geht es mal mit den Protokollen weiter !
(Bits, Bytes und Status, ...)

[IsnoAhoy (Gast)]

Jan-Jonas,
ich finde die von Bernd vorgeschlagene „Abfrage“ über Modbus TCP nicht 
so falsch. Speziell wenn wir jemand wie Arnaldo G oder Ziyat T. mit 
einer DTU Pro und Modbus Schnittstelle haben dann ist das doch die 
ideale Möglichkeit per Modbus „Kommandos“ an die WR zu stellen und 
parallel an den RX/TX Punkten das MCU/nRF Protokoll abzugreifen. Wenn 
wir also ein klares Testszenario per Modbus vorgeben könnten, wäre uns 
allen doch geholfen da wir dann auch die gwünschten Testdaten bekämen.
Was wäre denn per Modbus möglich und nötig ?
* Werte aller Art abfragen
* WR auf X% Leistung limitieren
* WR wieder unlimitiert betreiben
etc.
Wenn wir die Anforderungen an das Testszenario schon mal definieren und 
ein klares Testprogramm für Modbus haben dann klappt es vielleicht auch 
schneller die gesuchten Daten zu bekommen.

[Daniel R. (daniel92)]

Moin zusammen,

@ Daniel M: Super Arbeit! Hast du zufällig vom Mitschnitt ein *.pcap 
File?
Ich gehe hier jetzt noch davon aus, wie du oben beshrieben hast, das es 
sich um ein "TSUN" handelt?

Daniel M. schrieb:
> Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein.

Konntest du hier mit einem Multimeter das nachprüfen auf einen 
Durchgang?
Wenn es kein GND Verbindung hat, wäre es Interessant füher oder später 
auch zu wissen wo dieser hinführt. :)

Die Frage die sich mir noch stellt (spez. an Arnaldo G & Ziyat T.), 
besitzt Ihr zufällig auch ein DTSU666? - Dann hätte man nähmlich ein 
kompletten Aufbau von einer 0-Einspeisung System. Dann wäre es ja noch 
einfacher alles weiter zu Analysieren. Jedoch gehe ich hier mal davon 
aus das ein DTSU666 noch fehlt?

Gruß Daniel

[Daniel M. (daniel_m821)]

Kleiner Nachtrag:
weiteres Decoding der einzelnen Werte wie folgt:
7E 89 63500316 63500316 014A 002D 0962 1383 04A2 0269   0123  FB  7F
                        330  40   2402 4995 1186 617    291   251
                        DCV  DCI  ACV  ACF  ACP  DProd. Temp.
7E 91 63500316 63500316 014E 0026 0961 1383 049D 0261   0122   D9  7F
                        334  38   2401 4995 1181 609    290  217
DCV=DC Voltage /10
DCI=DC Strom /10
ACV=AC Voltage /10
ACF=AC Frequenz /100
ACP=AC Leistung /10
DProd.= tägliche Produktion /1000
Temp.=Temperatur /10
Die letzten Werte sind Fragezeichen, könnte CRC sein, weiß ich aber 
nicht.


Die Daten an den Server zusammen mit fast passender Abfrage der 
DTU-Daten:
7E 89 63500316 63500316 014D 002E 095A 1386 05A6 02C7 0126 6C 7F
                        333  46   2394 4998 1446 711  294  108
7E 91 63500316 63500316 0151 002B 095A 1386 059D 02BE 0126 2F 7F
                        337  43   2394 4998 1437 702  294  47
-
a55600104254b308881173d510020001010116051c0c1f097800020a160350634110014d 
012b0059098613a605c702c910000025010300000000000100000000000a160350634110 
0251012b00590986139d05be02b810000025010300000000000100000000009a15
DTU id:  08881173d510
WR id:  160350634110
Datum:  28 . 5 . 22  | Zeit:  12 : 31 : 9
Panel: 1
DC Volt:  33.3 V | DC Amp:  4.3 A | AC Volt:  239.3 | Temperatur:  3.7 
C | A02 01 1
AC Freq:  49.98 Hz | AC Power:  144.6 W | P today:  0.711 kWh | P total: 
4.297 MWh
Modulstatus:  3 | Anz. Modulfehler: 0 | Connectionstatus:  1
-
Panel: 2
DC Volt:  33.7 V | DC Amp:  4.3 A | AC Volt:  239.3 | Temperatur:  3.7 
C | A02 01 1
AC Freq:  49.98 Hz | AC Power:  143.7 W | P today:  0.702 kWh | P total: 
4.28 MWh
Modulstatus:  3 | Anz. Modulfehler: 0 | Connectionstatus:  1

Die Temperatur funktioniert offenbar nicht mehr, warum auch immer. Der 
Rest der Daten kommt jedoch hin. Das schwächere Modul 2 liegt leider 
unterhalb des Dachfirst, der zu gerne von Vögeln als Toilette benutzt 
wird, daher ist auch, denke ich, recht gut erkennbar, wie die Zuordnung 
ist:
89 ist Panel 1, 91 ist Panel 2

lg
Daniel M.

Edit: Am Anfang ist eine Zeile zu den Werten verrutscht.

[Daniel M. (daniel_m821)]

Daniel R. schrieb:

> @ Daniel M: Super Arbeit! Hast du zufällig vom Mitschnitt ein *.pcap
> File?
> Ich gehe hier jetzt noch davon aus, wie du oben beshrieben hast, das es
> sich um ein "TSUN" handelt?

Hi, hängt hier dran :)
Ja, ist ein TSUN TSOL-M800 mit 2 MPPT-Trackern.

> Daniel M. schrieb:
>> Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein.
>
> Konntest du hier mit einem Multimeter das nachprüfen auf einen
> Durchgang?
> Wenn es kein GND Verbindung hat, wäre es Interessant füher oder später
> auch zu wissen wo dieser hinführt. :)

Der Tastpunkt ist 3,3V.
Mit dem Durchgangsprüfer hatte ich Verbindung nach VDD, VSS und GND. 
Maximale Verwirrung.

lg
Daniel M.

[Maik R. (bastelbarney)]

Servus,
die Verdrahtung für https://github.com/grindylow/ahoy geht immer(?) von 
einem ESP8266 "Wemos D1mini" aus. Daran mangelt es mir gerade.
Doch habe ich noch paar AZDelivery ESP8266 "NodeMCU v3" herumliegen ... 
weiss jmd von Euch aus dem Stehgreif, ob die PIN-Bezeichnungen bei 
beiden identisch ist?

Muss ich sonst im Source die Pins anpassen?

Merci,
BastelBarney

[Heinz R. (heijz)]

Maik R. schrieb:
> Muss ich sonst im Source die Pins anpassen?

Wemos hat die Dx-Bezeichnungen

Nichts im Code ändern, einfach passend anlöten - die GPIO-Bezeichnungen 
sind die gleichen

https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

[Maik R. (bastelbarney)]

Heinz R. schrieb:
> Wemos hat die Dx-Bezeichnungen
> Nichts im Code ändern, einfach passend anlöten [...]
> https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

Dankeschön! Und guter Link, sehr schnell überblickbar dort.

[IsnoAhoy (Gast)]

Hallo Bastel Barney,
habe auch eine NodeMCU und die selben PINs wie am Wemos verwendet. Wenn 
ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und 
Raspberry Pi hochladen.

[Daniel R. (daniel92)]

Moin Ahoy,

ich glaube das es Sinnvoll ist. Damit andere User am Projekt mitwirken 
wollen, aber nicht das technische "know-how" haben dennoch mitwirken 
können. :)

Fritzing ist ja denke ich schnell gemacht.

[Ziyat T. (toe_c)]

Hallo
Ich habe, wie schon früher gemeldet:
-DTU-Pro
-DTSU666
-MI1500
-Raspi+python(pymodbus+mqtt+nodered)
ausser WR alle mit Modbus verbunden um den zero export zu realisieren, 
DTU-Pro+MI-Series kann den zero export nicht wirklich.

Da ich einen MI1500 habe kann ich euch nicht helfen, da die MI-Serie 
völlig anders funktioniert:
- RF Protokoll komplett anders
- Modbus auf Port/WR Ebene schwach implementiert

Ich werde aber bald einen HM1500 bekommen, dann kann ich weiter

[Misch O. (misch_o)]

Hallo,
suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem 
Link dazu helfen .... den neuesten Code bekomme ich mit der Arduino IDE 
nicht kompiliert warum auch immer .'
im Moment benutze ich die Version 0.4.4 mit einem HM1500, funktioniert 
gut
Danke !!!
Vielen Dank im voraus
misch

[Lukas P. (lumapu)]

Guten Abend,

anbei die neusete Version.
Danke an @Jan-Jonas, diese Version hat jetzt auch den Retransmit des 
letzten Pakets, sobald bekannt ist welches das letzte Paket ist.
Ich hoffe die Stabilität konnte weiter verbessert werden und stellt 
einigermaßen zufrieden.

Durch den last-Paket-Retransmit kommen bei mir deutlich mehr komplette 
Payloads zustande (mit einem 5s Interval). Aktuell funke ich durch 3 
Betondecken vom Keller aufs Dach.

Edit 22:20: 0.4.12 mit Boot-Loop fix
Wir haben 1000 Beiträge =)

Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =)

[rosch99 (Gast)]

Misch O. schrieb:
> suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem
> Link dazu helfen

Hier die brandaktuelle 0.4.11 kompiliert für den Wemos D1 mini

[Lukas P. (lumapu)]

leider nicht mehr brandaktuell, es gibt schon die 0.4.13.

[rosch99 (Gast)]

Lukas P. schrieb:
> Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =)

oh, mein Artikel kam zu spät, lumapu ist so schnell am committen,
ich komme mit dem kompilieren nicht nach ;-)

[Daniel R. (daniel92)]

Moin zusammen,

nach der Arbeit schaue ich mir mal den Code und alles an. :)
Ich nutzte aktuell VS Studio und aktuell für den Arduino, die eigene 
IDE. VSCode läuft bei mir irgendwie nicht rund.

Oder kennt jemand ne gute Anlauf stelle um mit VS Studio direkt zu 
compilieren? - Bitte keine "nutz Google" Antworten.

Aktuell habe ich das gefunden: 
https://marketplace.visualstudio.com/items?itemName=VisualMicro.ArduinoIDEforVisualStudio

Was nutzt ihr denn?

Vielen Dank und den neuen Code teste ich sobald ich heute wieder Zuhause 
bin. :)

1003 Einträge, Mensch haben wir ein neuen Rekord aufgestellt? :D

[Günter H. (gnter_h534)]

Einen Link dazu kenne ich auch nicht.

Bei mir klappt es mit der Arduino IDE 1.8.19 und

- aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4)

sowie den LIBRARIES

- Time 1.6.1
- RF24 1.4.2
- PubSubClient 2.8

ohne Probleme.

Gruß Günter

[Christian P. (pocki)]

Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht.
Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut 
werden kann?

Hardware hätte ich alles schon da: Raspberry Pi, nRF24, ESP8266, 
Arduino-Nano.

LG, Pocki

[isnoAhoy (Gast)]

Hallo Christian P.,
leider gibt es noch keine klare Information zu den älteren MI-Modellen 
von Hoymiles. Es gab bereits einige Foristen mit einem MI- 
Wechselrichter, u.a. Ziyat T. mit einem MI-1500, Arnaldo G. mit zwei 
MI-1500 und Daniel B. mit einem MI-600, Daniel M. mit einem TSUN 
TSOL-M800 vermutlich ein re-brandeter MI-800 und jetzt Du mit einem 
MI-300.
Leider haben wir bisher relativ wenig Informationen über das ältere 
MI-Protokoll. Ziyat. T. hat mal eine Auswertung in Excel als Screenshot 
MI1500data.png und DTUPro.log angehängt und Arnaldo G. hatte sehr zu 
Beginn dieses Threads seine nrf24.txt und nrf24_2.txt Ergebnisse vom 
mitsniffen ihrer DTU Pro bekannt gegeben.
Vielleicht wollt Ihr auch mal ein Issue auf github aufmachen um den 
aktuellen Wissensstand zur MI-Serie zusammenzutragen. Da könnte dann 
z.B. Ziyat noch mal erklären wie er zu den Ergebnissen bei seiner 
Auswertung gekommen ist. M.E. sah das was die Spannung und sonstigen 
Werte angeht schon sehr vielversprechend aus ...
Das fehlende Glied sind die Aufforderungen zum Tanz die die DTU-Pro den 
MI-Wechselrichter schickt. Hier müsste man am besten und einfachsten an 
den RX/TX Testpunkten in der DTUPro den Verkehr mit einem Logic Analyzer 
mitschneiden. Anleitung für eine DTU-Lite hatte martin (Gast) hier 
bereits geliefert:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Du kannst auch einfach nochmal auf der Single Page Ansicht nach "MI-", 
"MI1500", "Salea" etc. suchen.

Ziyat & Arnaldo, do you have an Logic Analyzer at hand or would you get 
one for a dozen bucks to make those traces ?
I have given you a short summary for the Software Decoding / Analysis 
under Linux in a recent post, where I documented my approach to 
successfully decode the files DTU_Captures.zip from martin:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[isnoAhoy (Gast)]

@Ziyat & Arnaldo, I believe Sigrok / Pulseview may be even able to read 
raw data from Raspberry Pis GPIO pins, just in case you do not have a 
Logic Analyzer at hand.

Read here for two projects with the same goal and helpful input on how 
to best secure the GPIO Pins against overvoltage / current.
https://github.com/superzerg/logic-analyzer
https://github.com/richardghirst/Panalyzer

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht.
> Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut
> werden kann?

Hallo Christian P. und  @isnoAhoy
Bisher funktionieren alle SW-Versionen nur mit der HM-Serie, MI-Serie 
werden (imho) nicht unterstützt.

Meine Motivation um den MI zu analysieren (zur Zeit) ziemlich klein 
geworden:
- Hoylimoly hat die Produktion der MI's abgestellt
- Die MI's als 2.gen haben wenige Funktionen, vor allem man kann sie 
nicht unter 10% limitieren, das passt mir überhaupt nicht (zero import? 
wenn kein load)
- MI-Ports können nicht einzeln limitiert oder ein/ausgeschaltet werden

Ich habe bisher durch meine DTU-Pro Hilfe (wenn sie eingeschaltet ist 
konnte ich die WR-RF-Messages mitlesen) alle Werte in MI-Messages 
entschlüsseln, den MI konnte nicht ansprechen, bisher das ist alles.

Ich werde weiter machen wenn ich den HM bekomme, sorry.

[Christian P. (pocki)]

Ja, ist nachvollziehbar. Die MI Serie ist schwierig zu knacken.

Ich habe mich soweit durch die 1000+ Postings gearbeitet, speziell die 
Logfiles nrf24.txt bis hin zu nrf24_5.txt und weitere. Scheint als fehle 
noch das initiale Aktivierungskommando der DTU. Schon versucht, die DTU 
abzustecken, abzuwarten bis die Inverter verstummen und dann beim 
Wiedereinschalten der DTU dessen Init-Kommando zu erwischen? Eventuell 
ist genau der setTime-Command der Key?

Ich kämpfe noch, um Raspi, nrf24-modul, esp8266, nano und die Software 
zum Laufen zu bringen. Hoffe ich habe das bald bei'nander.

[isnoAhoy (Gast)]

Hallo Lukas P.

warum ist in hmRadio.h eigentlich Kanal 40 nicht als Receive Channel mit 
angegeben ?

#define RX_CHANNELS             5
...
            // Depending on the program, the module can work on 2403, 2423, 2440, 2461 or 2475MHz.
            // Channel List      2403, 2423, 2440, 2461, 2475MHz
            mRxChLst[0] = 03;
            mRxChLst[1] = 23;
            mRxChLst[2] = 40;
            mRxChLst[3] = 61;
            mRxChLst[4] = 75;
...
        uint8_t getRxNxtChannel(void) {
            if(++mRxChIdx >= RX_CHANNELS)
...
        uint8_t mRxChLst[RX_CHANNELS];

würde das um den Kanal 40 erweitern.
laut FCC Dokumentation soll das nRF Modul ja auf allen fünf Kanälen 
funktionieren.

@Christian P., Ziyat T., etc.

mit der o.g. Erweiterung könnte man ggf. auch seine DTU als 
"Dummy"-Wechselrichter eintragen,
also DTU Serien Nummer stattdessen mit führender 1121, 1141 oder 1161 
eingeben.

Er würde dann zwar auch versuchen der DTU die bekannten 
Status/setTime-Kommandos zu schicken,
aber gleichzeitig müsste er auch alles was von der DTU kommt als 
Received bytes channel XX im
Serial Monitor ausgeben.

[Christian P. (pocki)]

Ich selbst habe leider keine DTU, und plane auch nicht eine zu kaufen.

Ich fürchte es wird nötig sein, dass ein DTU-User einen MI-WR aus seinem 
Setup entfernt (de-registriert) und neu einrichtet/registriert. Und am 
besten BEIDES mitschneiden :-)

[Christian P. (pocki)]

Die Benutzeranleitung der DTU-Pro App erwähnt eine Funktion zur 
automatischen Erkennung naher Microinverter:

https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf 
Seite 16:
>3. You can add microinverter via “Automatic Search” or typing in...
>4. The search result of microinverters and microinverter added will be displayed

Die Screenshots wurden mit Inverter-Seriennummern 1121xxxxxxxx gemacht, 
also vermutlich MI-Serie.

Könnte jemand mit einer DTU und dieser App das mal ausprobieren und ggf. 
den nrf24-Traffic versuchen einzufangen?

[Daniel R. (Gast)]

Hi Pocki,

ui das klingt ja mal Interessant. Wenn es tatsächlich klappen sollte, 
könnte man das als Feature mit einbauen um einfacher die WR zu 
hinterlegen.

Sehr cool, glaub ich sollte auch mal das ganze Handbuch studieren. 😅

[Ziyat T. (toe_c)]

Wenn Ihr schon mit solchen guten Vorschlaegen kommt, bitte liest Ihr das 
HB 
(https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf 
) nochmals schön durch:-)
Es handelt sich um DTU-Pro-S
Microinverter Compatibility
Microinverter model HMS series, HMT series

[Christian P. (pocki)]

Hm, stimmt allerdings.
Ich erinnere mich Ende 2020 an ein Handbuch mit Screenshots zur DTUlite 
von schlecht designten HTML-Seiten zur Einrichtung der WR. Und da gab es 
auch einen "search"-Button. Und das war zu Zeiten bevor es die HM-Serie 
gab.

[isnoAhoy (Gast)]

Hallo martin (Gast) & Christian P.,

das sieht in der Tat interessant aus. Die Funktion scheint es auch in 
der DTU-Lite-S zu geben. Ich weiß natürlich nicht ob es das nur in der 
-S Version und/oder auch in der WLite Version gibt ?

User Manual_DTU-Lite-S_Global_EN_V202202
https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_DTU-Lite-S_Global_EN_V202202.pdf

> 3. You can click "Automatic Search" to add microinverter,
> or you can type in / scan the microinverter ID.

@martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic 
Analyzer ausprobieren und mitschneiden ?

[Daniel M. (daniel_m821)]

Mal eine blöde Frage zwischendurch:
Wenn ich versuche aus der Arduino-IDE meinen Wemos D1 Mini zu flashen, 
rennt er in eine Boot-Loop und kommt nicht.
Ich möchte nicht ausschließen, dass ich falsche Einstellungen habe, kann 
mir jemand die richtigen geben? Auch könnte der Flash mittlerweile 
hinüber sein, was ich auch nicht ausschließen kann.
Ich nutze aktuell Arduino 1.8.19 und habe es mit der ahoy-Version 0.4.13 
von Github probiert.

Mit etwas Überzeugungshilfe habe ich esptool 3.3 dann dazu bekommen, das 
bin-file direkt zu flashen und es klappte nach einigen Schwierigkeiten.

Danach wäre ein kurzer Exkurs in das Programm interessant, an welchen 
Stellen die Adressen und Befehle zusammengebaut werden.
Würde mich da mal mit den Anpassungen auf den TSUN beschäftigen und 
schauen, was ich mit meiner Unkenntniss hinbekomme.

Dankeschön :)

Edit: ein neuer Git Pull hat geholfen, habe noch eine Vorversion mit dem 
Bug drin gehabt. Die Einstellungen mal vergleichen wäre trotzdem 
Hilfreich.

[martin (Gast)]

isnoAhoy schrieb:
> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic
> Analyzer ausprobieren und mitschneiden ?

Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.

[Christian P. (pocki)]

martin schrieb:
> isnoAhoy schrieb:
>> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic
>> Analyzer ausprobieren und mitschneiden ?
>
> Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.

Das wäre ganz super :-)
Ich habe inzwischen mein Klump zusammen und kann gleichzeitig nrf24 
sniffen (noise wird über crc-check verworfen) und auch custom-payloads 
senden :-)

Sobald ich also einen Anhaltspunkt bekomme, an welche 
Destination-Adresse mit welchem Payload man Pakete senden könnte, kann 
ich starten.

[Christian P. (pocki)]

Ich habe von meinem MI-300 nun geschafft Antworten zu empfangen, 
wenngleich auch noch keine nutzbaren Daten:

Anfrage via nrf24 (on-air):

Address 1319406101    Data 15 77665544 88776655 81 58
          WR-rev           mid  DTU    dummy   cmd crc

Antwort vom WR (on-air):

Address 4455667701    Data 15 77665544 61401913 81 bf
          DTU-rev          mid  DTU    WR      cmd crc

Nach ein bisserl Herumspielen stelle ich fest:
1) Der WR antwortet an die Adresse, welche in der Anfrage-Payload bytes 
2,3,4,5 steht, reversed und mit 0x01 ergänzt. hier also 77665544 liefert 
die WR-Antwort an die Adresse 4455667701

2) Die Felder WR und DTU sind somit vertauscht (hinter dem MID): zuerst 
kommt die DTU (an welche der WR seine Antwort senden soll), und dann der 
WR.

3) Die Länge der Antwort ist immer gleich lange wie die Länge der 
Anfrage.

Keine der bekannten Anfragen (MID 0x07, 0x15 und CMDs 0x00, 0x80 bis 
0x83) liefern brauchbare Payload retour: es kommt immer nur genau das 
zurück, was in der Anfrage gesendet wurde. Einziger Unterschied ist die 
S/N des WR (bei mir 61401913) und dann natürlich die 8bit payload-crc.

So, und was nun? :-)
Ideen willkommen

[Daniel R. (daniel92)]

Hmm, interessant...

Ich hätte die Idee das man die MID inkrementiert und darauf lauscht.
0x00 bis 0xFF sind 255 steps.

Wie lang dauert das Senden + Empfangen + Delay? 1sek.?
Dann hätte man nach 255sek. wenigsten die Info ob bei allen MIDs die 
gleiche Antwort zurück kommt.

Oder was meint ihr?

[Christian P. (pocki)]

Ok, rennt schon. Leider nicht so simpel, weil der WR nicht bei jeder 
Sendung antwortet. Ich vermute, das liegt am Channelhopping des WR: der 
scannt umher auf den Kanälen.
Ich sende und sniffe aber nur Channel 0x03, daher kann es sein, dass ich 
ein Paket 5-10x senden muss, um eine Antwort zu bekommen.

Ein erster Durchlauf bestätigt das. Was ich schon mal sagen kann:
Pakete mit MID größer als 0x80 werden nicht beantwortet. Auch MID=0x00 
bleibt stumm.

Ich lasse mal laufen für MID=0x00-0xFF und CMD=0x00-0xFF folgende 
Payloads jeweils 4x mit 15 retransmissions :-)

  MID+  dtu   +   wr   +CMD+crc
zb 07 77665544 61401913 81 aa

Werde berichten...

Hoffentlich zerschiesse ich mir den WR damit nicht

[Daniel R. (daniel92)]

Hmm, soviele retransmissions macht doch kein Sinn?

Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu 
schalten, damit man mehrere Kanäle sich anhört.

Apropo Channel hopping, irgendwo muss doch eine Komunikation stattfinden 
das beide, WR + DTU, im selben Channel zuhören/reden. Oder?

Gerade gefunden: 
https://hackaday.com/2017/03/21/ask-hackaday-frequency-hopping-on-the-nrf24l01/

https://paulplusx.wordpress.com/2017/03/19/frequency-hopping-with-nrf24l01/

[Christian P. (pocki)]

Daniel R. schrieb:
> Hmm, soviele retransmissions macht doch kein Sinn?
>
> Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu
> schalten, damit man mehrere Kanäle sich anhört.

Ich habe 2 NRF-Module: eines am GPIO eines Raspberry zum Versenden und 
eines an einem Arduino-Nano zum Sniffen. Der liefert via serial an den 
gleichen Raspi ab, wo ich dann auf die Empfängeradresse filtere.

Die 15 Retramsmissions alle 250µs sind im Python-Initscript fix drinnen, 
habe es nicht geschafft das zu reduzieren. Die macht er, weil der WR ja 
kein ACK sendet.
Das 4x-Senden in 500ms Abständen loope ich bewusst, damit ich sicher 
gehen kann, dass es der WR auch gehört hat und nicht antworten will.

Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch. 
Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen, 
also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende. 
Hoffe nur wir können dann etwas beobachten.

[Daniel R. (daniel92)]

Alles klar, danke für die Arbeit.
Wichtig natührlich alles fleißig zu loggen... :D

[Christian P. (pocki)]

Ich bin noch skeptisch, ob uns das weiterbringt.
Bis jetzt habe ich ausnahmslos nur "gespiegelte" Antworten gesehen, also 
egal welcher MID oder CMD: es kam immer genau die selbe Nachricht 
retour, nur mit der anderen Seriennummer. Sonst: gleicher Inhalt, 
gleiche Länge.

Kann also sein, dass wir ohne Kenntniss des *echten 
Einrichtungs-Dialogs* zwischen einer DTU und einem MI-WR nicht 
weiterkommen.

[martin (Gast)]

Christian P. schrieb:
>> isnoAhoy schrieb:
>>> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic
>>> Analyzer ausprobieren und mitschneiden ?
>>
>> Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.

Hallo,
ich konnte zwischenzeitlich mal ein paar Captures aufnehmen.
In Capture0 und 1 habe ich mich per App mit der DTU verbunden (die baut 
ja ihr eigenes WLAN auf) und dann auf "Inverter Hinzufügen und 
Automatische Suche" geklickt. In Capture2 habe ich mal die 
Echtzeitdatenabfrage laufen lassen (Zeigt die Istwerte auf dem 
Inverter).

Habe heute leider keine Zeit mehr, die Daten aufzubereiten, daher die 
Rohausgabe als .txt und die Logic-Captures direkt mit im Anhang, für 
eure eigenen Analysen (Saleae Logic-Software kann man kostenlos 
runterladen und die Captures öffnen).

Zur Info nochmal:
Inverter 1141 72220200
DTU Lite 10D9 72818832

[Christian P. (pocki)]

Danke, mir fällt insbesonders alles ausser mid=15 und =95 auf auf:

capture_1.txt
7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 
0a,8d,7f
7e,81,72,81,88,32,72,81,88,32,00,81,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,81,72,81,88,32,72,81,88,32,01,80,7f
7e,06,72,22,02,00,72,22,02,00,00,06,7f
7e,06,72,22,02,00,72,22,02,00,00,06,7f
7e,01,72,81,88,32,72,81,88,32,00,01,7f
7e,01,72,81,88,32,72,81,88,32,01,00,7f
7e,02,72,22,02,00,72,22,02,00,00,02,7f

Verstehe ich das korrekt: das sind die Daten von "on-wire" zwischen dem 
Onboard-Chip und dem NRF24-Modul der DTU? Weil: leider kann man da nicht 
klar herauslesen, an selche destination-address das nrf24-paket dann 
geschickt wird. Oder?

[martin (Gast)]

Christian P. schrieb:
> das sind die Daten von "on-wire" zwischen dem
> Onboard-Chip und dem NRF24-Modul der DTU?

Ja genau, auf der UART zwischen GD32 und NRF24.
Um die Richtung zu erkennen habe ich die Saleae-Files mit hochgeladen.
Dort kann man anhand des Kanals erkennen, ob es der DTU-Controller an 
den NRF schickt (sprich: die DTU an den Inverter) oder ob es vom 
Inverter zurückkommt.

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Daniel R. schrieb:
.....
> Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch.
> Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen,
> also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende.
> Hoffe nur wir können dann etwas beobachten.

Habe schon vor 2 Monaten ausprobiert, bei mir kam nichts...
Ich habe mehrere logs vom MI1500 hier veröffentlicht

[isnoAhoy (Gast)]

Christian P.,
ja die Salea Captures haben noch en 0x7e Prefix und Postfix 0x7f 
vor/nach den uns sonst geläufigen Nachrichten / Paketen.

7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 
0a,8d,7f
ist also eigentlich
MID=0x86
Destination=72220200
Source/DTU=72220200
Paket/CMD=0x02
Payload=11,41,72,22,02,00,00,b0,00,00,00,b0,01,0a
CRC8=0x8d

Ich sehe da also zwei Addressen:
* 72220200
* 72818832
Vielleicht sind die im capture1.txt genannten Adressen ja so eine Art 
Broadcast Adresse für die jeweiligen Modellreihen ?

Interessant dürften für die MI Wechselrichter in der Tat die MIDs außer 
0x15 und 0x95 der HM Baureihen sein: Speziell 0xc2 und 0x06 stechen mir 
ins Auge, ich meine so etwas auch in Ziyat T. bzw. Arnaldos Logfiles 
bereits gesehen zu haben.

[isnoAhoy (Gast)]

Hallo martin (Gast),
Danke für die Aufnahmen!

Hast Du die Aufnahmen während des Tages gemacht, d.h. dabei war ein WR 
anwesend und hat geantwortet.
Interessant wäre ja auch das Verhalten der DTU in einer abgeschirmten 
Umgebung.
Hier sollte die DTU ja prinzipiell einmal alle Discovery Optionen 
ausspielen, die ggf. auch eine MI-Wechselrichter interessieren könnten.

In der Payload steht ja eine HM-600/700/800 Serien Nummer: 114172220200
Damit hat die DTU wohl einen jungen Fisch gefangen ?

[isnoAhoy (Gast)]

Noch eine (Broadcast) Adresse 10,d9,42,7f ?

grep '^7e' capture0.txt | less
/(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83)

bzw.

grep '^7e' capture0.txt | grep -v '72,22,02,00' | less
/(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83)

um den ganzen Smalltalk mit 114172220200 auszufiltern ergibt:

7e,81,72,81,88,32,72,81,88,32,00,81,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,81,72,81,88,32,72,81,88,32,01,80,7f
7e,01,72,81,88,32,72,81,88,32,00,01,7f
7e,01,72,81,88,32,72,81,88,32,01,00,7f

[Ziyat T. (toe_c)]

Hallo
im Anhang sind die wireshark logs zwischen DTU-Pro und MI1500 mit 
versch. channels.
Hatte sie mit NRF24_Sniff von Ivo Pullens generiert.
Adr:1284..DTU, 6071..MI, Adr sind verkehrt!

z.Bsp: im NRF24_Sniff die DTU Adresse eingegeben, auf CH3, das ist die 
Antwort vom WR, ist von mir entschlüsselt, siehe früheren Beitrag:
ch3-2-12842272.pcapng
b6:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 
05:05:b1
b8:63:70:71:60:63:70:71:60:01:bb:00:0c:09:86:13:87:02:23:01:da:01:16:03: 
00:01:fa
b7:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 
05:05:b0
b9:63:70:71:60:63:70:71:60:01:bb:00:06:09:85:13:87:01:2b:01:3f:01:16:03: 
00:01:1c

im NRF24_Sniff die WR Adresse eingegeben, auf CH23:
ch23-60717063.pcapng
51:63:70:71:60:72:22:84:12:5a:5a:1a:8f
51:63:70:71:60:72:22:84:12:5a:5a:1a:8f
51:63:70:71:60:72:22:84:12:5a:5a:0b:9e


36:63:70:71:60:72:22:84:12:00:f2
37:63:70:71:60:72:22:84:12:00:f3
38:63:70:71:60:72:22:84:12:00:fc
39:63:70:71:60:72:22:84:12:00:fd



Villeicht hilfts euch weiter.

[Jan-Jonas S. (janjonas_s)]

Ich habe heute mal die c2 und 81 er Payloads bei mir in die Luft 
geworfen und von meinem HM600 keine Reaktion bekommen. Die Frage ist 
natürlich, ob die Dinge wirklich on-air gehen oder nur setup-commands an 
das NRF-Modul sind?

Christian P. schrieb:
> MID+  dtu   +   wr   +CMD+crc
> zb 07 77665544 61401913 81 aa

Damit hast Du ja nur ein Re-Transmit angefordert(?).
So einfach ist das nicht mit durch iterieren, weil viele Anfragen 
einfach eine definierte payload mit Parametern erwarten.

Interessant ist eigentlich nach jedem Kommando mal ein 80 11 abzufragen 
(event log). Das wird bestimmt überlaufen mit a_code=2, was ich denke 
wird soviel sagen wie Software-Fehler, Parameter-Fehler oder 
Kommunikationsfehler (Spekulation)

Leider scheint im Dump auch die Anfrage auf die Antwort mit der 
Seriennummer zu fehlen.

[Christian P. (pocki)]

Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das 
Shockburst-Frame des nrf24-Protololls gesendet wird?

Wenn die Daten ein Dump aus der internen DTU-Schnittstelle zum
nrf24-Modul sind, zeigen die ja nur (?) den Payload oder?

Oder steuert das erste Feld (MID) das Verhalten des nrf24 hinsichtlich 
Destination-Adresse/Adresslänge/ShockburstOnOff?

Hat sonst noch jemand captures von on-air Daten?

[Friedhelm E. (fritsche)]

Hallo Hubi(Gast)
Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme 
aber beim kompilieren folgende Fehlermeldung:
In file included from 
/home/papalapap/Arduino/HoyDtuSim/HoyDtuSim.ino:86:
/home/papalapap/Arduino/HoyDtuSim/ModWebserver.h: In function 'void 
handleRoot()':
ModWebserver.h:55:33: error: 'getSerialNoTxt' was not declared in this 
scope
   55 |     out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";
      |                                 ^~~~~~~~~~~~~~
exit status 1
'getSerialNoTxt' was not declared in this scope

Vielleicht sagt dir die Fehlermeldung in der ModWebserver.h etwas.
Wünsche frohe Pfingsten

Arduino: 1.8.19 (Linux), Board: "LOLIN(WEMOS) D1 R2 & mini, 160 MHz, 
Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most 
compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for 
IRAM/PROGMEM, 4MB (FS:1MB OTA:~1019KB), v2 Lower Memory, Serial, None, 
All Flash Contents, 921600"

[Ziyat T. (toe_c)]

DTU-Pro <-> MI1500 logs

WR -> DTU
----------
len } 2a:
hdr } 2c:67:b7:0f:00:63:70:71:60: 63:70:71:60:
data} 
01:b2:00:0f:09:22:13:89:02:77:01:02:01:b7:03:00:03:74:48:9e:3e:aa:77:de: 
ab:ec:b6:a6:40:
U DC    I DC    U AC    Hz AC    P DC        C
1  b2  0  0f  9  22  13  89  2  77  1  2  1  b7


DTU -> WR
---------
16: d4:cf:21:0f:00:63:70:71:60: 72:22:84:12:5a:5a:1b:8e:ee:12:3d:b6:08

[Jan-Jonas S. (janjonas_s)]

Christian P. schrieb:
> Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das
> Shockburst-Frame des nrf24-Protololls gesendet wird?

Die Richtung kann man nicht erkennen.
Aus beobachtungen weiß ich bisher, dass 0x15 dtu->wr und 0x95 die 
Antwort vom wr ist. Oder man kennt die Adressen seiner Geräte. 7e,7f 
markiert start und ende der spi-kommunikation in der dtu. Das geht nicht 
on-air.

0xc2 und 0x81 sind neu für mich und enthalten z.T. keinen gewöhnlichen 
ESB-Aufbau. Vermutlich könnte es also sein, dass die dtu da den nrf-chip 
konfiguriert oder status register abfragt. (Spekulation)
Könnte aber auch genauso gut sein, dass 0xc2 Übertragungsart ist, 
broadcast vs. 0x15 unicast?

[Tobi D. (tobidd)]

ich habe meinen HM-400 heute endlich in Betrieb nehmen können. Der WR 
läuft und produziert auch,aber ich bekomme mit meinem WemosD1 und dem 
NRF Modul leider keinerlei Rückemeldungen vom WR.

Uptime: 0 Tage, 00:54:20
Time: 2022-06-05 14:09:30
Statistics:
Receive success: 0
Receive fail: 652
Send Cnt: 1304
Free Heap: 0x98c8
Inverter 'HM-400' is not available and is not producing
MQTT: connected

Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die 
Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu 
haben.

im seriellen log steht folgendes:

Free heap: 0x9fb0
Inverter #0 no Payload received!
Requesting Inverter SN 1121xxxxxxxx
Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 
05 00 00 00 00 B0 39 B9
Error while retrieving data: last frame missing: Request Retransmit
Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 
05 00 00 00 00 B0 39 B9
Free heap: 0x9fb0
Inverter #0 no Payload received!
Requesting Inverter SN 1121xxxxxxxx

Version nutze ich die aktuelle 0.4.15

[Jan-Jonas S. (janjonas_s)]

Hast Du einen Kondensator an VCC vom NRF-Modul? Wichtig.
Manchmal hilft, die Sendeleistung von der "DTU" zu ändern. Habe das 
schon gehabt, dass WR nicht antworten, wenn man die zu laut fragt.
Auch die Ausrichtung der Antenne kann Wunder wirken.

[Tobi D. (tobidd)]

ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe 
ich auch alle low, min, high und max probiert.

genauso wie die entfernung zwischen paar cm und einigen metern geändert 
wurde

[Ziyat T. (toe_c)]

Mehr DTU-Pro <-> MI1500 logs
Diesmal WR ist stumm, weil Nacht, DTU-Pro neu gestartet

[Lukas P. (lumapu)]

Tobi D. schrieb:
> Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die
> Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu
> haben.

Seriennummer muss so eingetragen werden, wie sie auf dem Aufkleber zu 
lesen ist.
Hast du mal mit der Ausrichtung der Antenne gespielt? Stimmt dein 
Pinout, vor allem der IRQ Pin darf nicht auf GPIO16 liegen?

[Hubi (Gast)]

Friedhelm E. schrieb:
> Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme
> aber beim kompilieren folgende Fehlermeldung:
> In file included from

Hallo Friedhelm
hol dir die neueste Version von 
[[https://github.com/hm-soft/Hoymiles-DTU-Simulation]], das sollte 
klappen

[rosch99 (Gast)]

Tobi D. schrieb:
> ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe
> ich auch alle low, min, high und max probiert.

Viele der NRF-Module haben geclonte Chips, manche funktionieren besser, 
manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit 
ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht 
funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne 
auf der Platine bestellt, die funktionieren problemlos.

rosch99

[Daniel M. (daniel_m821)]

Der Tip mit den Modulen mit Antenne, die irgendwie nicht so ganz laufen, 
war gut.

Ardunio-Konsole:

14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB 
14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB 
14:40:00.684 -> Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 4A 00 11 09 5F 13 85 02 2D 03 61 00 F2 AC
14:42:57.596 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4 
14:42:57.644 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4

Hauptsächlich jedoch kommt diese Meldung:

14:43:00.590 -> Error while retrieving data: last frame missing: Request Retransmit

Das passiert fast immer, wenn vom WR eine Antwort eingeht.

Raspi mit ahoy python-tool:

2022-06-06 14:43:06.908846 Received 24 bytes channel 23: 89 63 50 0b 16 e3 50 0b 16 81 4a 40 17 09 5b 53 88 82 dc 0b 64 80 f2 d3
Error while retrieving data: max() arg is an empty sequence

2022-06-06 14:43:13.198405 Received 24 bytes channel 75: 8b 63 50 03 16 63 51 0b 56 95 5a 09 53 19 5b 33 8a 92 de 0b 6c 91 f6 d1
Error while retrieving data: Frame 1 missing: Request Retransmit

2022-06-06 14:49:57.395157 Received 18 bytes channel 61: 88 63 50 03 16 63 50 13 16 00 03 00 80 08 01 00 03 89
2022-06-06 14:49:57.401382 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:50:01.087613 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56
2022-06-06 14:50:01.098937 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:50:02.584152 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 3

2022-06-06 14:52:42.631804 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 13 86 01 c4 03 6d 00 f6 55
2022-06-06 14:52:42.643443 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 53 86 05 c5 03 6d 01 f6 55
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:52:44.136428 Received 18 bytes channel 40: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 3

2022-06-06 14:52:46.298238 Received 24 bytes channel 75: 91 63 50 03 16 63 50 03 16 01 47 00 0e 09 58 13 86 01 c1 03 67 00 f6 4f
Error while retrieving data: Missing packet: Last packet 1

2022-06-06 14:52:47.289513 Received 18 bytes channel 3: 94 63 50 02 16 63 50 02 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:52:47.851089 Received 18 bytes channel 40: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 01 00 03 89
Error while retrieving data: Missing packet: Last packet 3

2022-06-06 14:56:22.534647 Received 18 bytes channel 3: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91

Der Raspi empfängt etwas alle ca. 30s, wenn die DTU die Requests sendet.
Den Tx hab ich rausgelassen, da wir wissen, dass mein WR nicht darauf 
reagiert.

Ich hab aus dem Log von Raspi mal diese größeren Abschnitte mit nur Tx 
gelöscht.

Ich bin mit Arduino und C++ nicht wirklich gut unterwegs und brauche 
Starthilfe, an welchen Stellen die Sendebefehle wie zusammengebaut 
werden.

Mein Tsun hat 2 Kanäle, füge ich ihn über 1141 statt 1041 hinzu, 
funktioniert das schonmal :)

[Jan-Jonas S. (janjonas_s)]

Das Python-Script wird damit auch nichts automatisch dekodieren können, 
weil für die Wahl des Dekoders die Anfrage ausschlaggebend ist, die 
python selbst abgesetzt hat.

Du kannst höchstens manuell den Datenstrom aufzeichnen, zusammensetzen 
und einen Dekoder dafür in Python bauen und das dann copy&pasta mit 
bytes.fromhex() da durch schieben. Das geht tatsächlich sehr gut und man 
kann dann auch schön am Dekoder rum tweaken bis die Ergebnisse sinnvoll 
sind. Beispiele habe ich ja schonmal gepostet.

Bis die gesamte Transaktion implementiert ist, wird das mit dem 
python-Script, automatisch, keine Daten dekodieren können ohne den Tx 1. 
zu haben und 2. sinnvoll verstanden zu haben. Also aus dem Tx muss man 
erkennen können welche Daten angefragt wurden.

Theoretisch könnte die DTU ja auch gerade ein Firmware-Update hochladen. 
Die Fragmente der Transaktion kann man schon durch einen Status-Dekoder 
schieben, bekommt dann aber keine sinnvollen Werte. Der Dekoder wird 
schon dekodieren. Der kann nicht erkennen ob das sinnvoll ist oder 
nicht, oder ob er für die Daten die man ihm gibt überhaupt geeignet ist. 
Zumindest solange der buffer groß genug ist und man nicht in einen 
IndexError läuft.

Du bekommst da zwar Daten aber ohne Kontext. Binärdaten ohne Kontext 
sind nicht mehr als Rauschen.

[Daniel M. (daniel_m821)]

Hi Jan,

aktuell zeichne ich einfach auf, was durch die Luft fliegt.
Die Requests habe ich da, kann sie nur nicht senden, allerdings macht 
das, was ich so empfange Sinn zu dem, was ich in der DTU sehe.
Die bytes kann ich soweit dekodieren und nachvollziehen, nutze das eher 
als sniffer, den ich bedienen kann.
Dass ich mit dem Python-Script nicht viel weiter komme, ist mir klar :)
Leider bin ich nicht so tief in der Programmierung drin, wie einige 
andere hier, so dass ich sehr froh bin, die Scripte soweit überhaupt hab 
starten können und ihnen was sinnvolles entlocken konnte.

Primäres Ziel war erstmal:
 - funktionieren die NRF-Platinen? -> mit externer Antenne nicht, 
integriert ja
 - auf welchen Kanälen wird empfangen? -> 3, 23, 40, 61, 75
 - ist das, was ich empfange, sinnvoll? -> weitestgehend ja
 - kriege ich es hin, mit dem D1 mini was zu sehen? -> nur zufällig, 
eher nein

Beim rumschnüffeln in der Luft hab ich noch 2-4 byte lange Antworten 
gesehen sowie solche Konstrukte:

channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d fa 01 3a 33
channel 40: b2 6b 50 03 16 63 50 07 16 00 03 00 00 02 00 20 02 91
channel 23: a8 6b 50 03 36 63 50 03 16 00 13 00 00 0a d7 26 af bb
channel 3: a9 63 50 03 16 63 50 07 16 01 35 00 04 09 4a 13 8a 00 8e 85 03 01 3a d0
channel 3: b2 63 50 03 36 63 50 03 16 00 13 01 00 00 00 80 08 93 c3 93 3a aa
channel 3: 94 63 50 03 16 63 50 03 14 00 43 00 00 00 10 00 01 91
channel 3: 8b 63 50 03 16 63 51 03 16 01 2e 00 02 09 51 13 8e 80 51 05 04 01 2b 1b

Was es damit aufsich hat, schau ich mir später noch an, da es 
wiederkehrende Muster aller paar Minuten sind.

Ohne Hilfe beim Code werd ich aber nicht viel machen können, da mir 
einfach die Grundlagen fehlen. Ich komme aus dem Dickstrombereich, das 
hier ist Hobby ;)

Deine Beispiele sehen gut aus, hab die versucht und bin (erstmal) 
gescheitert. Ich werd meine Freundin mal fragen, ob die damit weiter 
kommt. Wird aber etwas dauern. Trotzdem danke für den Ansatz, mit Geduld 
wirds werden :)

[Jan-Jonas S. (janjonas_s)]

Ich hab gerade nochmal ein PR für python auf gemacht. Habe den 
DebugDecodeAny Dekoder nochmal überarbeitet.

Beispiel: (auf der Kommandozeile)

tools/rpi$ python3 -c 'import hoymiles; hoymiles.decoders.DebugDecodeAny(bytes.fromhex("5c 00 00 b4 91 00 00 ab bf 03 71 03 78"))'
 payload has 13 bytes

Field view: int
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12
Hex       5c    00    00    b4    91    00    00    ab    bf    03    71    03    78
>B        92     0     0   180   145     0     0   171   191     3   113     3   120

Field view: shorts
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12
Hex       5c    00    00    b4    91    00    00    ab    bf    03    71    03    78
>H           23552         180       37120         171       48899       28931
>H                     0       46225           0       43967         881         888

Field view: longs
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12
Hex       5c    00    00    b4    91    00    00    ab    bf    03    71    03    78
>L                  1543504052              2432696491              3204673795
>L                             46225                   43967                57738104
>L                                11833600                11255555
>L                                    3029401600              2881422193
 type utf-8  : utf-8 decode error
 type ascii  : ascii decode error

*payload gekürzt, weil dieses dämliche Forum Zeilenumbrüche in Code, und 
damit Leserlichkeit kaputt macht.
Würde die komplette Payload in die DebugDecodeAny-Klasse gepastet werden 
würde es uns noch sagen, dass sich um die Payload eine valide Modbus CRC 
(oder CRC8) befindet.

Referenz:

2022-05-10 11:39:49.447628 Payload: 00 01 01 35 03 a8 0b 4a 01 37 03 aa 0b 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 09 08 13 87 15 a1 00 00 00 ef 03 e8 01 ef 00 06 99 3a
2022-05-10 11:39:49.447628 Decoded: 49.5 phase0=voltage:231.2, current:23.9, power:553.7, frequency:49.99 string0=voltage:30.9, current:9.36, power:289.0, total:46.225, daily:881 string1=voltage:31.1, current:9.38, power:290.8, total:43.967, daily:888

Wir finden aber Zahlen wieder und sehen schön an welcher Position in den 
Hex-Daten die stehen.

Meiner Meinung nach sind in den tsun-Daten viele korrupte Pakete mit 
Bitfehlern drin. Die Payload CRC8 stimmt oft nicht. Manchmal auch 
offensichtlich durch korrumpierte Adresse. Nicht, dass wir da jetzt 
Unsinn lernen. Grundsätzlich würde ich das auf der Luft-Schnittstelle 
aber erwarten, da wir das Protokoll nicht implementiert haben.

[Ziyat T. (toe_c)]

@Daniel M. schrieb:
@Jan-Jonas S
> Hi Jan,
>
> aktuell zeichne ich einfach auf, was durch die Luft fliegt.

Hallo
Die Antwort
channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d 
fa 01 3a 33
Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert. 
D.h. dieser TSUN ist ein MI?
Konntest du schon einen request schicken und TSUN hat geantwortet?

[Christian P. (pocki)]

Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu 
bekommen. Wie habt ihr das gemacht (ohne eine DTU)?

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu
> bekommen. Wie habt ihr das gemacht (ohne eine DTU)?

Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine 
Logs v. früher.
Ich sehe die WR-Antworten nur wenn meine DTU-Pro die request schickt.
Ich glaube, ich habe alle logs zusammen, WR-Antworten decodiert aber wie 
die request funktioniert hab nicht rausgefunden.

[Christian P. (pocki)]

Ziyat T. schrieb:
> Christian P. schrieb:
>> Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu
>> bekommen. Wie habt ihr das gemacht (ohne eine DTU)?
>
> Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine
> Logs v. früher.

Ja das las ich, ist also immer noch stand der Dinge wie es scheint :(

Ich bin nur auf Funk-Ebene unterwegs, also versuche die Messages einer 
DTU mit einem nrf24-Modul nachzumachen, um die Funk-Antworten meines WR 
zu erhalten. Dabei fiel mir auf:

Der WR antwortet NUR, wenn das nrf-paket im Funkheader die Zieladresse 
des WR hat (also SN=102161401913 -> Zieladresse 13:19:40:61:01 mit Länge 
5). Das wäre die Unicast-Variante. Ich konnte keine 
Broadcast-Empfangsadresse für den WR hier im Forum bislang ausmachen, 
auch nicht anhand der jüngsten Logs zu "automatische Suche". Sowas 
könnte eine 2-5 bytige Addresse sein, auf die jeder WR in der zweiten 
Pipe lauscht.

Außerdem: Die bekannten Payloads dokumentieren immer nach dem MID die 
S/N der DTU und danach die S/N des WR. Bei mir ist das umgekehrt! Der WR 
antwortet auf die Anfragen immer an jene Adresse, welche der ERSTEN S/N 
in der Payload entspricht. Das würde für mich bedeuten: die erste S/N 
der Payload sollte die DTU sein, an die deer WR seine Antwort 
adressiert.
Die bislang dokumentierte Payload stellt aber als erstes die S/N des WR 
dar, und erst danach die S/N der DTU.

Kann das jemand bestätigen?

[Christian P. (pocki)]

Also so:

python3 py-nrf24/send.py --crc 1 1319406101 15776655446140191381
..sendet die payload 15776655446140191381+crc8 an 13:.19:40:61:01 
77665544 ist die erfundene SN meines Raspi
61401913 ist die echte SN meines WR.

Sent: to Address 1319406101 Data 15 77665544 88776655 81 58
Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf

Das geht auch ohne der S/N des WR in der Anfrage
python3 py-nrf24/send.py --crc 1 1319406101 15776655440000000081

Sent: to Address 1319406101 Data 15 77665544 00000000 81 94
Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf

Ergo:
1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed, 
0x01 als 5. byte).
2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5, 
reveresed mit 0x01 ergänzt
3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload
4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 
und 0x7f beginnen.

[Christian P. (pocki)]

Habe was neues gefunden:

         nrf24-dest      pcf     payload
anfrage: 13 19 40 61 01 (16/0/0) df 02 00 776655441111111100fcaf85 0b
antwort: 13 19 40 61 01 (16/3/0) df 02 00 776661401913111100fcaf85 31

der Payload-Anfang df0200 bewirkt, dass der WR die Antwort-Adresse 
irgendwie ändert. Hier am Beispiel sendet er nicht an die DTU laut SN in 
den bytes 2.. retour, sondern an sich selbst?! Nachgefolgde MDI=15 
anfragen werden ebenfalls an diese Andresse dann beantwortet.

Ich hoffe ich habe mir nun nichts zerschossen. Scheinbar aber bewirkt 
der PRefix df0200 aber mal was anderes als nur MID=15.

[Tobi D. (tobidd)]

rosch99 schrieb:
> Tobi D. schrieb:
>> ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe
>> ich auch alle low, min, high und max probiert.
>
> Viele der NRF-Module haben geclonte Chips, manche funktionieren besser,
> manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit
> ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht
> funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne
> auf der Platine bestellt, die funktionieren problemlos.
>
> rosch99

hab mir jetzt auch noch ein nrf modul bei az del. ohne externe antenne 
bestellt, leider auch keine besserung

[Ziyat T. (toe_c)]

Christian P. schrieb:

> 1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed,
> 0x01 als 5. byte).
> 2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5,
> reveresed mit 0x01 ergänzt
> 3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload
> 4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00
> und 0x7f beginnen.

interresant, bei mir sieht es ganz anders aus..

[Christian P. (pocki)]

Ziyat T. schrieb:
> interresant, bei mir sieht es ganz anders aus..

naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit 
Schluss sind.

Ich habe inzwischen folgendes nachstellen können.

sende    15:77665544:22222222:80 an WR
empfange 15:77665544:61401913:80 als Antwort an Adresse 44:55:66:77:01
10sek pause
sende    df0200:7766 55443333 3333:00 an WR
empange  df0200:7766:61401913:333300 als Antwort an Adresse 22:22:22:22

Bei der ersten Nachricht setze ich im WR eine DTU-Adresse, die sich der 
WR merkt.
Bei der zweiten Nachricht verwendet der WR die DTU-Adresse von zuvor und 
überschriebt nur die Bytes 4..7 mit der eigenen SN.


> Christian P. schrieb:
>>4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00
>> und 0x7f beginnen.

ich revidiere, punkt 4 stimmt nicht

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ziyat T. schrieb:
>> interresant, bei mir sieht es ganz anders aus..
>
> naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit
> Schluss sind.

Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die 
Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du?
Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die 
gleiche SW verwenden würden, kommen wir ev. besser vorwaerts.

[Olaf A. (Gast)]

Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ 
und CE zu tauschen.

[IsnoAhoy (Gast)]

@Tobi B.
Beschreibe mal Deine Schaltung bzw. Überprüfe ob es evtl wie von Olaf 
geschrieben am IRQ Eingang liegt. Nicht alle Pins am ESP sind 
Interruptfähig.
Laut Deinem Log hat Dein HM-400 folgende Seriennummer:

> Inverter SN 1121xxxxxxxx Transmit 27 | 15 80 13 52 94

112180135294 stimmt das ?

Ich sehe in Deinem „kurzen“ Log nämlich nur TX aber kein einziges RX 
Paket. D.h. dein ESP und nRF24 scheinen zu senden, aber der HM-400 fühlt 
sich offenbar nicht angesprochen.

Alternativ kannst Du gerne auch mal ein längeres Log anhängen, 
vielleicht sieht man da mehr. Nach dem Booten sollte der ESP auch einen 
Block mit den nRF24 Settings ausgeben, etc pp.

[IsnoAhoy (Gast)]

@Daniel M. und Freundin, Ziyat T.,
Das sieht doch schon ganz vielversprechend aus. Ich meine auch das mit 
den „reversed“ 5 Byte (das letzte 01) bei der MI- Baureihe am Anfang des 
Threads gelesen zu haben. Habe mich immer gewundert, dass die HM- 
Baureihe die Seriennummer in der richtigen Reihenfolge und mit nur 4 
Byte annimmt. Da scheint es wohl einen Unterschied zu geben.
Viel Erfolg weiterhin!

[Tobi D. (tobidd)]

Olaf A. schrieb:
> Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ
> und CE zu tauschen.

das hats gebracht, vielen dank für den tipp :)

[Christian P. (pocki)]

Ziyat T. schrieb:
> Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die
> Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du?
> Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die
> gleiche SW verwenden würden, kommen wir ev. besser vorwaerts.

Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+ 
modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und 
bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit 
sehe ich alle pakete (inkl. der destination adresse).
Quelle des sketch kann ich nimmer sagen: habe ich Sept. 2020 
organisiert, Author ist J. Coliz inspired by cpixip.
Diesen Sketch habe ich etwas modifiziert, damit das 9bit PCF als 3 
dezimale angezeigt wird und alles danach um das 1 Bit verschoben ist: so 
kann man viel leichter die Payload erkennen.
Ergänzend habe ich ein Skript gebaut, dass die CRC des nrf24-Pakets 
prüft, so kann ich leichter die Noise aus dem gesnifften Kauderwelsch 
rausfiltern und es bleiben nur "echte" Pakete übrig.

Zum Senden nutze ich einen Raspberry Pi 2B mit einem nrf24+ Modul an den 
GPIO Pins. Software ist von https://github.com/bjarne-hansen/py-nrf24 
mit kleinen Modifikationen, um z.B. einen crc8 automatisch anzufügen.

Ich sende und sniffe nur auf CH 0x03.

[Daniel R. (daniel92)]

Hallo zusammen,

ich bin aktuell ein stiller leser geworden.
Habe aber folgende Infos mitbekommen (speziell für die MI-WR) und denke 
das es hier noch nicht im Forum diskutiert wurde?

In dieser PDF Seite 8, sieht man die ältere Generation der DTU.
https://cdn.webshopapp.com/shops/296982/files/328732372/mi-500-mi-600-mi-700-microinverter-user-manual-rev.pdf

Das müsste genauer gesagt diese DTU sein: 
https://loja.opussolar.com.br/produto/transmissor-dados-hoymiles-dtu-mi/

Und hier sieht man eine DTU mit S.Nr.(10F052403668) aufgeklebt: 
https://ae01.alicdn.com/kf/H91aaca10736b4450a21891509dfeb934v.png

Mit der Info will ich nur aussagen, dass die MI-WR die S.Nr. von der 
alten DTU wahrscheinlich hören wollen. Wie Olaf schon die Erkenntnis 
hatte, kann man nicht jede DTU mit jeden WR kommunizieren. :)

Olaf A. schrieb:
> *Anmerkung: Der Mikrowechselrichter 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

Somit könnte man bei der Abfrage die DTU(alt), die S.Nr. 10F0xxxxxxxx 
hinterlegen.

@IsnoAhoy: Hier könnte man die Excel aktualisieren, oder?
https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx
Und wenn mein Gedanke richtig ist und das so auch funktioniert,... 
könnte man später im Code hinterlegen mit welcher DTU-S.Nr. die 
Kommunikation stattfinden soll.

Bsp:
HM-800  11417420xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx)
HM-1500 11616320xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx)
MI-1200 10616090xxyy => DTU-Alt? (10F0xxxxxxxx)

Gruß Daniel

[isnoAhoy (Gast)]

Hallo Olaf A. / Tobi D.,

danke für die positive Rückmeldung. Könnt Ihr bitte unter github oder 
hier Eure Verkabelung zwischen ESP (welches Modul) und dem nRF24 
Funkmodul dokumentieren bzw. mit der Verkabelung dort vergleichen ?
Danke!

ESP8266: Discussion Verkabelung / Pinout #36
https://github.com/grindylow/ahoy/issues/36

[Daniel R. (daniel92)]

Daniel R. schrieb:
> Hallo zusammen,

Nachtrag: Hier eine bessere Quelle:
https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt

[Frank (Gast)]

Daniel R. schrieb:
> Daniel R. schrieb:
>
>> Hallo zusammen,
>
> Nachtrag: Hier eine bessere Quelle:
> https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt

Quatsch mit Soße.

[Daniel R. (daniel92)]

Hallo Frank,

danke für die Ausführliche Rückmeldung. ;)
Die Quelle soll sich eher auf die DTU-MI (Bilder) beziehen.

Ich weiß ja nicht inwieweit es "Quatsch mit Soße" seien soll.
Lieber verweise ich auf die Quelle woher die S.Nr. stammt.

Schließlich ist doch jede Hilfe (auch wenn es nur eine S.Nr. ist) 
brauchbar.
Vielleicht könnte man die Daten aus dem MI-WR mithilfe dieser DTU S.Nr 
beziehen. Bisher wird meines wissens nach in der "hmRadio.h" mit einer 
festen S.Nr. vorgegaukelt welche DTU spricht.

Vielleicht macht es Sinn hier die ersten 4 stellen diese mit 
einzubeziehen.

So, erkläre mir jetzt mal wieso das Quatsch mit Soße ist!?

[Ziyat T. (toe_c)]

Christian P. schrieb:
>>>
> Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+
> modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und
> bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit
> sehe ich alle pakete (inkl. der destination adresse).
>>>>
Das ist interresant, habe wie gesagt bisher die aurduinoUno+nrf24 kombi 
und SW von Ivo Pullens verwendet.
Ich würde gerne mal deine aurduino Sketches ausprobieren um zu sehen ob 
ich die gleichen Daten sehe wie du, geht das?

[IsnoAhoy (Gast)]

Hallo Daniel R.,

ja das ist evtl ein interessanter Fakt, ich habe noch keine Rückmeldung 
von den anderen DTU Besitzern erhalten welches Prefix die denn haben, 
sonst könnte ich die Tabelle gerne mal ergänzen/aktualisieren. Ich habe 
schon ein paar zusätzliche Informationen gesammelt aber noch keine. 
commit gemacht.

@Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg 
wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer 
versendet ?

10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ?

@Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. 
Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf 
0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten 
auf dem Kanal 2403GHz.

@Oliver F. das wäre doch was für Deinen nRF24 hexa-Decker mit sechs nRF 
Modulen kannst Du dann senden und alle fünf Kanäle (2403-2475) 
mitschneiden.


Ebenfalls interessant ist mE die Beschreibung unter Seite 8 des von 
Daniel R. verlinkten „historischen“ Dokuments:

Fig.2. MI-500 /MI-600 /MI-700 Microinverter wiring diagram
Note 1: DTU connects the power production of each microinverter. If the 
asymmetry current is going to exceed 16 A, DTU will send stop signal to 
one or more microinverters to let the asymmetry current lower than 16A.

Das sind ja die Signale die uns noch fehlen, also wie kann die DTU die 
WR dazu bringen ihre Kanäle abzuschalten. Evtl. kann man mit diesem 
Wissen und einem regelbaren Netzteil am Eingang der WR eine DTU in den 
Panikmodus versetzen und die Nachricht abfangen ?

[Daniel R. (daniel92)]

Hallo IsnoAhoy;

IsnoAhoy schrieb:
> am Eingang der WR eine DTU in den
> Panikmodus versetzen

Das klingt an sich nicht schlecht, nur ist die Frage ob der Flag im 
Speicher vom WR sich automatisch zurücksetzen lässt (durch ein 
Neustart?).

Sonst bestünde die Gefahr das der WR für immer in dem Modus bleibt, 
außer man schickt den richtigen Befehl... wobei ich behaupte mal das die 
Entwickler hierfür bestimmt was vorgesehen haben.

Hier würde ich mal das ganze mit vorsicht "genießen".

[IsnoAhoy (Gast)]

Hallo Daniel R.
ich gehe mal davon aus, wenn die Differenz der Leistung wieder unter 16A 
fällt sollte eine ordentliche DTU das auch wiedee freischalten, das 
könnte man dann auch aufnehmen. Hattest Du nicht Deinen WR mangels 
Modulen noch am Labornetzteil ? Ich nehme an das bezieht sich auf 
mehrere WR in der auf Seite 8 beschriebenen Modul-Konfiguration.

[Daniel R. (daniel92)]

Genau, ich betreibe es aktuell am Labornetzteil.
Nur habe ich ein HM-1500. Mein Netzteil kommt an sein Limit. :(

Besitze nur einen mit 30V und knapp 10A.

[Christian P. (pocki)]

IsnoAhoy schrieb:
> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code.
> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf
> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten
> auf dem Kanal 2403GHz.

Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte 
konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und 
0x00AA.

Achtung: man kann hiermit keine längeren Payloads mitlesen, weil ja 
wegen der Empfangskonfig 6 Bytes und 1 Bit zu früh empfangen wird und 
deshalb die hinteren bis zu 7 Byte fehlen.

Ziel dieses Sniff-Methode ist es, die Destination-Adresse im 
nrf24-Header zu identifizieren. Wenn man die mal genauer weiß, kann man 
den nrf24 auf diese Adresse und Adresslänge konfigurieren und dann die 
ganze Payload über die herkömmliche (=designte) Methode empfangen.

Anbei der Sketch und die verwendete RF24 library.
Mit readserial.py hole ich mir den Output am Raspberry Pi herein.
Mit verifyserial.py filtere ich nach Paketen mit gültigem CRC. Aus 
Performancegründen nur Pakete mit 5stelliger Zieladresse. Das kann man 
in Zeile 59 auf range(0,3) setzen, um 2 bis 5 byte lange Adressen 
durchzuanalysieren.

Achtung: Payloads länger als 23 Byte oder 24 Byte könnten hier übersehen 
werden.

LG

[Daniel R. (daniel92)]

Hallo zusammen,

ich versuche gerade das NRF auf dem Raspi zum laufen zu bringen.
Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".

sudo python3 -um hoymiles --log-transactions --verbose --config /home/dtu/ahoy.yml | tee -a log2.log
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.7/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.7/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/home/Hoymiles_NRF24/hoymiles/__init__.py", line 14, in <module>
    from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
ImportError: /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: undefined symbol: _ZN4RF2410setPALevelEh

Ich habe wie in der Beschreibung auf Github alles Installiert und auch 
den Wrapper drauf gepackt. Ich musste vorher noch die Module crcmod & 
RF24 nach installieren.

Aber irgendwie hängt das ganze. :(
Raspberry Pi 4
Python 2.7.16
Python 3.7.3

PS: Bei Step 4 "nano gettingstarted.cpp", habe ich diesen Punkt einfach 
ohne Änderung weiter gemacht. Ist das falsch?

[Carsten B. (carstenb)]

Hallo in die Runde,

nachdem ich eine Weile nur selten mitlesen konnte, habe ich nun mein 
Setup wieder aktiviert. Diese Software 
https://github.com/hm-soft/Hoymiles-DTU-Simulation läuft auf einem 
Arduino Nano V3 zuverlässig und liefert an meinem HM600 Werte, die gut 
zu dem passen, was ich am Shelly mitlogge.

-----------------------
rcv CH:75 00 1234567801 00BE 17 3  95 72014650 72014650 830000000403E8012900163010E7B896 B896 1
Udc.CH1=29.4 V
Idc.CH1=0.14 A
Pdc.CH1=4.2 W
Udc.CH2=30.0 V
Idc.CH2=0.15 A
Pdc.CH2=4.6 W
E-Total.CH1=145.471 KWh
E-Total.CH2=146.316 KWh
E-Tag.CH1=1568 Wh
E-Tag.CH2=1610 Wh
Uac=233.6 V
Freq.ac=49.99 Hz
Pac=8.4 W
Ipv=0.04 A
WR-Temp=29.7 °C
Status=1000 
E-heute=3178 Wh
E-Total=291.787 KWh

Tagesproduktion heute lt. Shelly 3100Wh und Total 290 KWh

Klasse, wie gut das schon funktioniert :-)

Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem 
ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g. 
Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht 
kompatibel sind.

Hat jemand eine lauffähige Version für ESP32?

Viele Grüße

Carsten

[Ziyat T. (toe_c)]

Christian P. schrieb:
> IsnoAhoy schrieb:
>> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code.
>> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf
>> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten
>> auf dem Kanal 2403GHz.
>
> Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte
> konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und
> 0x00AA.
>>>>
Hallo Christian P.
Danke für die SW!
Habe gerade ausprobiert ohne was zu aendern, also als sniffer:
 WR ist im Schlaf , die DTU-Pro sendet/sucht.
Zuerst mal bin ich beruhigt, die Daten sind gleiche was ich auch schon 
mit "meiner" SW gesehen habe.
Siehe Anhang, du kannst es sicher besser interpretieren..
Was die DTU sendet ist dauernd: 00 f2 bis 00 fd

[Christian P. (pocki)]

> Was die DTU sendet ist dauernd: 00 f2 bis 00 fd

Das liest sich so:

60 71 70 63 01 (11/0/0) 38(63 70 71 60|72 22 84 12)00 fc[a4 bb]

Erste 5 Bytes: Adresse, an welche das nrf24 Paket geschickt wird. Nur 
nrf24 Module empfangen das, die nach Paketen an diese Adresse 
"lauschen".

(11/0/0) ist das decodierte 9bit PCF:
11=Länge der payload, 0=message counter, 0=noack-flag

Die payload ist also 0x38 bis 0xfc. Danach in der eckigen Klammer ist 
der crc16 vom nrf24 Protokoll.

Die Payload habe ich mit (|) versucht zu untergliedern: erstes Byte ist 
das MID (sofern das stimmt). Danach 4 Byte mit S/N des WR, dann 4 Byte 
mit S/N der DTU, dann der CMD 0x00, dann ein CRC8 über die vorangegangen 
Bytes der Payload.

Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden 
Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn 
der WR antwortet steht an genau dieser Stelle die S/N des WR.

Nun gilt es herauszufinden, wie man dem WR "programmiert", an welche 
Adresse er seine Antwortpakete senden soll. Ich habe das zuletzt 
geschafft indem ich ein Paket mit MID=15 und CMD=80 an den WR geschickt 
habe (Inhalt nach der Logik wie oben). Danach hat der WR einige Minuten 
lang alle seine Antworten an die gesetzte Adresse geschickt 8-)

Leider aber konnte ich weiterhin keine Stromdaten aus dem WR 
herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von 
deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die 
PV-Kanäle 36:1, 37:2, 38:3 und 39:4...?

[Daniel R. (daniel92)]

Hallo zusammen,

Daniel R. schrieb:
> Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".

Zu meinem obigen problem bin ich nicht weiter gekommen. Alles neu 
gemacht aber irgendwie hänge ich nun an dem Wrapper.

Nunja, wollte euch nur zum Thema "NRF24 kann nicht senden" noch 
Informieren das man die Platine einpacken soll. Siehe:
https://github.com/nRF24/RF24/blob/master/COMMON_ISSUES.md

Falls es jemand interessiert. :)

[Ziyat T. (toe_c)]

Christian P. schrieb:
>>>
Ach so, danke für die Erklaerung!

> Leider aber konnte ich weiterhin keine Stromdaten aus dem WR
> herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von
> deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die
> PV-Kanäle 36:1, 37:2, 38:3 und 39:4...?

Ich hatte mal früher schon mit MID=00bisFF und CMD=00bisFF alle 
Kombinationen erfolgslos versucht, aber hab vielleicht was falsch 
gemacht..
Jetzt bin gespannt, was bei dir rauskommt.

> Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden
> Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn
> der WR antwortet steht an genau dieser Stelle die S/N des WR.

Das ist genau so, imho bei allen DTU's

[Daniel R. (daniel92)]

Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden.

Handbuch: 
http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf

Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text

If the DTU cannot detect all the microinverters in the system over 30 minutes, please use manual mode instead.

Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping" 
aussendet und die WR darauf eine Rückantwort ausgeben.

Hier müsste es auch in der DTU-Pro diese Funktion geben.
Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon" 
auffangen und mit Implementieren (Feature).

------------------------

In diesem Beitrag von einem anderen Forum: 
https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840

Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann, 
ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :)

Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf...

Gruß

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden.
>
> Handbuch:
> 
http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf
>
> Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text
>

If the DTU cannot detect all the microinverters in the system over 
> 30 minutes, please use manual mode instead.

> Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping"
> aussendet und die WR darauf eine Rückantwort ausgeben.
>
> Hier müsste es auch in der DTU-Pro diese Funktion geben.
> Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon"
> auffangen und mit Implementieren (Feature).
>

Das ist ein altes Manual. Bei meiner DTU-Pro geht das nicht mit dem 
MI-WR, man muss ihn zuerst in der APP/Cloud angeben

>
> In diesem Beitrag von einem anderen Forum:
> 
https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840
>
> Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann,
> ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :)
>
> Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf...
>
> Gruß

Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache 
seit einem Jahr per Modbus den zero export.
Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine 
früheren Beitraege hier...

[Ziyat T. (toe_c)]

@Christian P.
Anfrage DTU-Pro:
PV1: ...36(63 70 71 60|72 22 84 12)00
PV2: ...37(63 70 71 60|72 22 84 12)00
PV3: ...38(63 70 71 60|72 22 84 12)00
PV4: ...39(63 70 71 60|72 22 84 12)00

Anworten vom MI-WR:

PV1: ...b6(63 70 71 60|63 70 71 60)data
PV2: ...b7(63 70 71 60|63 70 71 60)data
PV3: ...b8(63 70 71 60|63 70 71 60)data
PV4: ...b9(63 70 71 60|63 70 71 60)data

36 00110110
b6 10110110   bit8 gesetzt

37 00110111
b7 10110111   bit8 gesetzt

;-)

[Christian P. (pocki)]

Ziyat T. schrieb:
> @Christian P.
> Anfrage DTU-Pro:
> PV1: ...36(63 70 71 60|72 22 84 12)00
> PV2: ...37(63 70 71 60|72 22 84 12)00
> PV3: ...38(63 70 71 60|72 22 84 12)00
> PV4: ...39(63 70 71 60|72 22 84 12)00
>
> Anworten vom MI-WR:
>
> PV1: ...b6(63 70 71 60|63 70 71 60)data
> PV2: ...b7(63 70 71 60|63 70 71 60)data
> PV3: ...b8(63 70 71 60|63 70 71 60)data
> PV4: ...b9(63 70 71 60|63 70 71 60)data

Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten 
vom WR.

13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2]   <-anfrage vom Raspi
44 55 66 77 01 (11/2/0) 36(77 66 55 44|61 40 19 13)00 1d[88 16]   <-antwort vom WR

Gleiches Ergebnis mit MID=37 bis 40.

Bei mir antwortet der WR nur, wenn die erste S/N die vom Raspi ist. 
Setze ich da die S/N vom WR ein, dann antwortet der nicht mehr.

Irgendwas macht deine DTU also zusätzlich, vielleicht auch nur alle $$ 
Minuten? Oder gar nur einmalig beim Hinzufügen des WR ins Setup?

Vielleicht passiert es auch auf einem der anderen Kanäle? Ich lausche ja 
nur auf 0x03. Den Kanal kann man in den Skripten ja auch mal ändern...

[Ziyat T. (toe_c)]

@ Christian P. (pocki)
Hier noch was:
DTU:
51(63 70 71 60|72 22 84 12)5a 5a 0b 9e
WR:
d1(63 70 71 60|63 70 71 60)5a 5a d1
51>d1 8 bit gesetzt

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ziyat T. schrieb:
>> @Christian P.
>> Anfrage DTU-Pro:
>> PV1: ...36(63 70 71 60|72 22 84 12)00
>> PV2: ...37(63 70 71 60|72 22 84 12)00
>> PV3: ...38(63 70 71 60|72 22 84 12)00
>> PV4: ...39(63 70 71 60|72 22 84 12)00
>>
>> Anworten vom MI-WR:
>>
>> PV1: ...b6(63 70 71 60|63 70 71 60)data
>> PV2: ...b7(63 70 71 60|63 70 71 60)data
>> PV3: ...b8(63 70 71 60|63 70 71 60)data
>> PV4: ...b9(63 70 71 60|63 70 71 60)data
>
> Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten
> vom WR.
>
> [code]
> 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2]
> <-anfrage vom Raspi

ich glaube es muss so sein:
DTU>WR
36(63 70 71 60|72 22 84 12)00 f2
37(63 70 71 60|72 22 84 12)00 f3
38(63 70 71 60|72 22 84 12)00 fc
39(63 70 71 60|72 22 84 12)00 fd

[Christian P. (pocki)]

Bei mir so - ich habe nun einfach mal deine Adressen kopiert.

13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- raspi an WR
60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- antwort vom WR

sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt.
Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet 
der gar nicht.

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache
> seit einem Jahr per Modbus den zero export.
> Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine
> früheren Beitraege hier...

Ok, da ich ein HM besitze ist es bis auf 2% echt cool. 8-)

Ziyat T. schrieb:
> @Christian P.
> Anfrage DTU-Pro:
> PV1: ...36(63 70 71 60|72 22 84 12)00
> PV2: ...37(63 70 71 60|72 22 84 12)00
> PV3: ...38(63 70 71 60|72 22 84 12)00
> PV4: ...39(63 70 71 60|72 22 84 12)00

Sobald ich meine Probleme mit dem Raspi+NRF in den Griff bekommen habe, 
probiere ich das mal aus. Danke! :)

@pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt.
Hattest du die selben Probleme? -> 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Christian P. (pocki)]

Daniel R. schrieb:
> @pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt.
> Hattest du die selben Probleme? ->
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Ja, habe ich auch nicht hinbekommen und dann hingeschmissen.

[Andreas S. (drschiffler)]

Guten Tag,

ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500.

Mein interesse ist die "export limitierung" realisiert durch einen 
bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens 
der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24)

Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode 
der DTU-PRO nicht weiter um die Informationen besser zu decodieren?

Grüße
Andreas

[Ziyat T. (toe_c)]

Andreas S. schrieb:
> Guten Tag,
>
> ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500.
>
> Mein interesse ist die "export limitierung" realisiert durch einen
> bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens
> der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24)
>
> Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode
> der DTU-PRO nicht weiter um die Informationen besser zu decodieren?
>
> Grüße
> Andreas

Hallo Andreas
Hast du die Quellcode der DTU-PRO? Oder wo kann man sie finden?

[Ziyat T. (toe_c)]

@Christian P. (pocki)
Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann?
Ich möchte gerne die obige Diskussionen/Erkentmisse bei mir mal 
ausprobieren ohne lange deinen Sketch zu studieren und kaputt zu machen 
:-)
Es waere einfach wenn ich als data z.B.
36(63 70 71 60|72 22 84 12)00 f2
37(63 70 71 60|72 22 84 12)00 f3
38(63 70 71 60|72 22 84 12)00 fc
39(63 70 71 60|72 22 84 12)00 fd
schicken könnte

[Daniel R. (daniel92)]

Hallo Andreas,

wenn ich dich richtig verstanden habe ist an sich dein Gedanke nicht 
schlecht. Um an den Quellcode dran zu kommen ist es nötig das jemand die 
Mikrocontroller vom DTU-Pro dumped, diesen müsste man dann decompilieren 
und und und... wäre an sich möglich.

Die Frage jedoch, wer hat eine DTU-Pro UND das Equipment um ein Dump zu 
machen?  Bluepill, Blackpill,... 
https://medium.com/techmaker/reverse-engineering-stm32-firmware-578d53e79b3

Achtung: bei solch einem Dump werden natührlich auch die Daten (S.Nr, 
Email?, User-Infos) mit gesichert.

Wenn jemand sich das zutrauen könnte, wäre das an sich eine feine Sache. 
=)

Edit: Wie Ziyat schon geschrieben hat: Quellcode ist ja ein vom 
Hersteller geschrieben und ich kenne kaum eine Firma die denn Quellcode 
freigeben. ;)

[Christian P. (pocki)]

Ziyat T. schrieb:
> @Christian P. (pocki)
> Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann?

Leider nein, so gut bin ich mit Arduino-Sketches nicht. Deshalb mache 
ich das auch mit einem Raspi und einem zweiten nrf24 Modul an den 
GPIO-Pins. Software dazu siehe ein paar Posts weiter oben mit den zip 
Attachments.

[Ziyat T. (toe_c)]

Hallo an die HolyMolyDTU SW-Entwicker

Ich habe die letzte SW im April eingesetzt, sowohl ESP als auch Arduino 
Versionen, da die MI-WRs nicht mehr aktuell sind und ich war der einzige 
mit einem MI-WR, habe ich damals aufgehört weiter zu machen.
Seit dem habe keine Ahnung mehr über die SW-Staende etc..

Jetzt hat mich wieder ein bisschen durch Christan P. gepackt, den MI zu 
lauschen, ich denke wir sind bisschen weiter gekommen.
Ich möchte gerne eine der SW-Versionen (ESP oder Arduino) verwenden um 
einfach paar Msgs zu schicken und was zu empfangen.
Ich gestehe, bin etwas faul um irgend eine SW zu aendern.

Kann mir jemand von SW-Enwicklern eine Version anbieten mit der ich die 
folg. payload schicken kann:
MID..WR...........DTU..........CMD..
36...63 70 71 60..72 22 84 12..00 f2
37...63 70 71 60..72 22 84 12..00 f3
38...63 70 71 60..72 22 84 12..00 fc
39...63 70 71 60..72 22 84 12..00 fd
erwartete Antwort
b6...63 70 71 60..63 70 71 60..data.....

Danke

[Andreas S. (drschiffler)]

Hallo,

es gibt ein git-respository. Das parent-repository ist einige commits 
ahead aber privat. Die Aussage leite ich aus den merge requests 2020 ab. 
Aber vermutlich werden ein paar brauchbare Informationen vorhanden sein.
https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO
(Anmelden über den github oauth provider)

Allerdings enthält das repository keine Lizenz Informationen. Daher ist 
eine bedenkenlose Verwendung wohl fraglich.

Grüße
Andreas

[Daniel R. (daniel92)]

Christian P. schrieb:
> Deshalb mache ich das auch mit einem Raspi

Also funktioniert es bei dir doch. Hmm...
Gut dann gehe ich denn weg alleine.

Andreas S. schrieb:
> Das parent-repository ist einige commits
> ahead aber privat.

Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff 
darauf, kann man da etwas scrapen? :)

Dann könnte man das ganze hier sogar beschleunigen.

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Bei mir so - ich habe nun einfach mal deine Adressen kopiert.
>
>

> 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- 
> raspi an WR

das hier sollte 5a 5a 9e 0b sein

> 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- 
> antwort vom WR
>

>
> sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt.
> Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet
> der gar nicht.

hab alle MID=51 von DTU im Anhang, dann antwortet MI regelmaessig mit 
MID=D1

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Christian P. schrieb:
>> Deshalb mache ich das auch mit einem Raspi
>
> Also funktioniert es bei dir doch. Hmm...
> Gut dann gehe ich denn weg alleine.
>
> Andreas S. schrieb:
>> Das parent-repository ist einige commits
>> ahead aber privat.
>
> Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff
> darauf, kann man da etwas scrapen? :)
>
> Dann könnte man das ganze hier sogar beschleunigen.

Christian P. hat zum Lauschen Arduino+nrf24 zum Senden Raspi+nrf24.
Versuch mal mit seiner Raspi SW ?:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Andreas S. (drschiffler)]

Daniel R. schrieb:
> Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff
> darauf, kann man da etwas scrapen? :)
Also:
- Gefunden mit dem Tool "google". ( 
https://www.google.de/search?q=gitee+hoymiles+dtu )
- Jeder hat Zugriff (siehe Link vorher oder erster Treffer in der google 
Suche) wenn man einen Account auf gitee erstellt. (github ist für die 
Welt, gitee ist für China)
- Ja sollte helfen, da kompletter Quellcode inklusive Bootloader, Doku, 
Tabellen, Logs,...

Grüße
Andreas

[Christian P. (pocki)]

Super - da findet sich im gitee repo ein excel file mit dem Titel 
RFxxxx-V6.5. Schon ohne Translator erkennt man darin Message-Schemen. 
Das haben wir gesucht!

Nun geht es ans übersetzen und auf die Suche des "PASSWORD/unlock codes" 
für die Commands MID=0x15 und 0x09... :-) Die finden sich vielleicht 
auch irgendwo dort im Repo.

[Andreas S. (drschiffler)]

Hallo,

ich habe scheinbar ein Händchen für Suchfunktionen. :-)

Im file usart_nrf.c ist definiert:
UsartNrf_Send_PackSetLockOnOffCommand(...)

Andreas

[Daniel R. (daniel92)]

Hallo  Ziyat T,

danke für den Link. Jedoch ging es eher von Ahoy Github 
(https://github.com/grindylow/ahoy/tree/main/tools/rpi). Das bekomme ich 
nicht zum laufen. :(

Christian nutzt die andere abgewandelte. ^^ Das würde ich dann nehmen, 
wenns nicht anders geht.

@Andreas S: Okay cool, Gitee kannte ich gar nicht und wo ich auf die 
Seite gekommen bin (mit translator), wurde ich indirekt abgewimmelt.

Ich versuche mich dort mal zu Registrieren. Mal schauen wie gut ich in 
Chinesisch bin. joke :)

[Herbert K. (avr-herbi)]

Hallo,
gibt es einen Trick das ganze Repo als ZIP herunterzuladen ?
Ich bekomme überall nur 404 wenn ich den Button "Clone or Download" und 
dann "Download as ZIP" versuche (bei gitee.com). Anmeldung hab ich 
hinbekommen.

[Daniel R. (daniel92)]

Also bei mir hat es funktioniert.
Die ZIP ist 148MB groß.

[Christian P. (pocki)]

Sieht nach den "Kronjuwelen" aus!
Der Source Code lässt vermutlich keine Fragen mehr offen.

[Daniel R. (daniel92)]

Andreas super arbeit!

Übrigens bin ich bisschen vorsichtig hier. Habe mal zwecks Dokumente 
lesen diese bei Virustotal geschoben. Aktuell nichts auffäliges.

https://www.virustotal.com/gui/file/a31fea2076e821eae5d783c75fa3814e7a3378002f21d80d4737d238a31e4b47?nocache=1

Würde das bei allen Files empfehlen, besonders die bat / exe. Die erste 
bat-File im root Ordner sieht bisschen suspekt aus.

Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich einige 
Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder 
besser Github pushe?

[Herbert K. (avr-herbi)]

Danke ! ! !  für den Link ! ! !   Danke Andreas  ! ! !

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Andreas super arbeit!
>
p> Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich 
einige
> Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder
> besser Github pushe?

Rechtlich sind wir sowieso alle Banditen hier, darum gefaellt es mir;-))
Die Chinesen haben seit mehr als 20 Jahren auch alles kopiert...
Für mich lieber Github, auch ohne Uebersetzung

[Ziyat T. (toe_c)]

@Christian P.

#define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF  0x51 
//ŒÓËø&ÏÞÖƹŠÂÊ

#define CONTROL_LOCK_MI_SUB                 0xa5a5
#define CONTROL_LIMIT_POWER_SUB             0x5a5a
#define CONTROL_ON_SUB                      0x55aa
#define CONTROL_OFF_SUB                     0xaa55

genau was ich heute bei mir gesehen habe ;-)
51(63 70 71 60|72 22 84 12)5a 5a

[Daniel R. (daniel92)]

Also in der Excel "RF通讯协议-V6.5.xlsx" 
(RF-Kommunikationsprotokoll-V6.5.xlsx) stehen viele Dinge über die alten 
MI-WR Serie. ;)

Da sollte in Zukunft Licht ins dunkle kommen.
Die Excel habe ich zu ca. 1/3 auf Deutsch übersetzt.

Ich breche hier ab und schaue mich noch in den anderen Dokumenten um.

[Daniel R. (daniel92)]

Bingooo!!!!

/***********************************************
** Function name:     //Stellen Sie die Anti-Rückfluss-Parameter ein
** Descriptions:
** input parameters:    ?
** output parameters:   ?

** Returned value:      ?
*************************************************/
uint8_t UsartNrf_Send_PackSetRefluxPowerCommand(uint16_t reflux_power, uint8_t MainCmd, uint16_t SubCmd)
{
    uint8_t i = 0;
    uint16_t j;
    uint8_t temp_dat[UART_LEN];
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//Kopf
    temp_dat[0] = MainCmd;   //Anweisung
    memset(&temp_dat[1], 0, 4);
    memset(&temp_dat[5], 0, 4);
    //
    //  MIReal[PortNO].Data.NetCmd = NET_TURN_ON;
    //    if(MIReal[PortNO].Data.NetCmd == NET_TURN_ON)        //开机状态
    //    {
    temp_dat[9]  = SubCmd & 0XFF00 >> 8;
    temp_dat[10] = SubCmd & 0XFF;
    temp_dat[11] = reflux_power * 100 / (EVERY_PORT_POWER * 10 * Dtu3Detail.Property.PortNum);  //Prozentsatz der Leistungsbegrenzung
    temp_dat[12] = reflux_power >> 8;    //Hohe 8-Bit-Leistungsbegrenzung
    temp_dat[13] = reflux_power & 0x00ff;             //Niedrige Leistungsgrenze 8 Bit
    //    }
    //    else                                                          //开低功耗
    //    {
    //        temp_dat[9]  = SubCmd & 0XFF00 >> 8;   //5a5a
    //        temp_dat[10] = SubCmd & 0XFF;
    //      temp_dat[11] = 0;
    //      temp_dat[12] = 20&0x00ff;
    //      temp_dat[13] = 20&0xff00>>16;
    //    }
    temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
    i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //Vorwärtssubstitution
    Uart_SendBuffer[i + 1] = ETX; //Ende
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

[Andreas S. (drschiffler)]

Guten Abend,

ich kann zwar programmieren -- denke ich -- aber ich bin eher der 
Anwender / Orchestrator. Daher meine vorsichtige Frage. Bekommen wir, 
ihr oder die Community es hin eine Arduino Bibliothek und/oder ein 
Python modul "ahoymilesdtu" zu erstellen?

Man könnte ja in die Kommentare der Files im Sinne "copyleft" das 
quellgebende repository nennen.

Danke und Grüße
Andreas

[Daniel R. (daniel92)]

Ich kann mit der Frage nichts Anfangen.
Was möchtest du nochmal genau wissen? :)

[Andreas S. (drschiffler)]

Daniel R. schrieb:
> Ich kann mit der Frage nichts Anfangen.
> Was möchtest du nochmal genau wissen? :)
Das Resultat der zahlreichen Stunden die hier investiert werden könnte 
doch so aussehen:
arduino
include <ahoydtu.h>
include <mysmartmeter.h>

AHOYDTU ahoydtu_nrf24(SS_PIN, RST_PIN,...);
MYSMMETER mysm('192.168.1.1',502); // Haus-Hauptanschluss

void setup() {
...
ahoydtu_nrf24522.Init();
...
}

void loop(){
...
if (mysm.read_active_pw_kw() < -0.6){
  ahoydtu_nrf24.reduce_pw_by(0.6 - math.abs(mysm.read_active_pw_kw()) );
} else {
  // no power limit
}
//wait some time
...
}

und/oder das gleiche in python

import ahoydtu as ahoy
....# usw.

So kann man 2kW installieren und speißt max. 600W ein. Und dank 
Blindleistungsregelung max. -60VA laut Richtlinien.
Das geht glaube ich so in der DTU Pro software (noch) nicht. (siehe 
file: AntiBackflow.c )

[Jan-Jonas S. (janjonas_s)]

Sieht ja vielversprechend aus. Die Frage der Lizensierung ist sehr 
berechtigt. Ich würde meine Werke gerne unter der GPLv2 lizensiert 
sehen.
Das wäre auch ein Grund für die Teilung der Repos. Meinetwegen bleiben 
sie bei Petersilie.
Früher oder später muss das eh passieren, wenn wir python mal als 
richtiges installierbares Package bauen wollen.

Für den MI-Teil bin ich sogut wie raus, weil ich hier kein DuT habe.
Ich kann die Grundsubstanz des Python-Codes vielleicht mal modularer 
gestalten, dass das MI-Protokoll parallel hinzugefügt werden kann.

Grundsätzlich bietet python ja schon die Idee, rohe Payloads via mqtt zu 
injecten. Jedoch bisher nur als Payload in zu einem HM, ohne ESB-Frame. 
Könnte man aber anpassen. Schwieriger wird dann das empfangen.

[Jan-Jonas S. (janjonas_s)]

Andreas S. schrieb:
> So kann man 2kW installieren und speißt max. 600W ein. Und dank

Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein 
Zertifikat sehen, dass das auch funktioniert.
Im Wesentlichen wird das EVU fordern bei Dir eine 
Fern-Abschalteinrichtung einzubauen.
Physikalisches Limit != Software Limit.
Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine 
DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in 
Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal 
wegen Unterproduktion die Computer aus.

[Heinz R. (heijz)]

Jan-Jonas S. schrieb:
> Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine
> DIY Frickelei ohne Siegel und Plombe eh nicht sein.

Doch, ist sie, das ist gar kein Problem
Zeig mir einen WR an dem die 70% Grenze verplombbar ist - entweder den 
Installateur interessiert es nicht oder man nimmt sie raus nachdem er 
weg ist
Mit Kontrollen ist hier auch nicht zu rechnen  auf welcher rechtlichen 
Grundlage sollte das passieren?

Und selbst wenn es so passieren sollte - Pressemitteilung "900.000 
PV-Anlagen in Deutschland still gelegt weil sie 3% zu viel eingespeist 
haben"- lächerlich

[isnoAhoy (Gast)]

Hallo Andreas S.,
das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges.

Hier die usart_nrf.c übersetzt ins Englische. Ich traue den 
Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht.

Man sollte halt keinen Source Code 1:1 aus dem Original übernehmen, dann 
ist das ja auch nur eine Referenz und keine Kopie -> Urheberrecht. Bei 
dem Python Code von Jan-Jonas und den anderen Pythonistas sehe ich da 
sowieso eher kein Problem. Wenn es um die Portierung des Protokolls von 
der C in eine C++ Variante geht scheint mir der C++ Code von Lukas auch 
viel eleganter als das doch recht prozedurale C der Hoymiles Bibliothek. 
Vor allem der Parser für die Pakete ist m.E. bereits viel hübscher und 
modularer geraten.

[Christian P. (pocki)]

isnoAhoy schrieb:
> Hallo Andreas S.,
> das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges.
>
> Hier die usart_nrf.c übersetzt ins Englische. Ich traue den
> Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht.

Danke, super.
Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch 
den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden. 
Kann mir wer damit helfen?

Verdächtig sind da ein paar Commands in der Übersicht:
0x02 broadcast commands to collect terminal device IDs in the network
0x13 Set query RF ID
0x18 All wRFID retrieval, respond as long as there is retrieval
0x1a Set MI-NRF ID

[isnoAhoy (Gast)]

Hier ist eine englische Übersetzung des RF communication 
protocol-V6.5xlsx

[isnoAhoy (Gast)]

Anbei noch einige übersetzte Dokumente. Laut dem Filesystem Design 
Dokument speichert die DTU 96 Werte pro Tag, das sind bei 1440 / 96 = 15 
Minuten Intervalle.

[isnoAhoy (Gast)]

Hallo Christian P.,

> Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch
> den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden.
> Kann mir wer damit helfen?

Ich habe das Excel-Dokument noch ein bißchen formatiert damit es 
leichter lesbar ist.

Ich vermute das ist das Legacy poll data command 0x09 auf Seite 3 Data 
Collection instructions. Für den/die anderen Kanäle der zwei bzw. vier 
Kanal-Wechselrichter Varianten gibt es noch das Command 0x11 Kanal B, 
bzw. 0x36, 0x37, 0x38, 0x39 (=Kanäle A1, B1, A2, B2).

Für die Suche nach einem WR kann man Command 0x02 verwenden siehe Seite 
5 Data acquisition RF dedicated.

Eventuell hast Du unbeabsichtigt auch das Kommando 0x01 Switch DTU-NRF 
air baud rate 2M / 250K an Deinen WR abgesetzt ?
Versuche es doch mal mit 0x01 im User data wieder auf 250K zurück zu 
setzen. Ich meine so etwas auch in martin (Gast)'s DTULite Logfiles an 
den RX/TX Punkten gesehen zu haben. Ich vermute die Kommunikation mit 
250K ist um einiges stabiler als die 2M Baudrate, vor allem in unseren 
Breitengraden mit einem vollen 2.4GHz Band.

[Christian P. (pocki)]

Bingo - habe meinem MI-300 eine Antwort entlockt:

Anfrage:
13 19 40 61 01 (11/1/0) 09(61 40 19 13|51 22 22 22)00 51[cc 1a]
Antworten:
22 22 22 51 01 (24/1/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1c.13 89.00 71.00 18.00 a4.8b[cb ??]
22 22 22 51 01 (24/3/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1d.13 89.00 6b.00 19.00 a4.91[fb ??]
22 22 22 51 01 (24/0/0) 89(61 40 19 13|61 40 19 13)01 3f.00 03.09 20.13 89.00 69.00 19.00 a4.d3[ad ??]

0x0142 = 32,2  V_PVA_AVG
0x0003 = 0,3   I_PVA_AVG
0x091c = 233,2 GridVol_AVG
0x1389 = 50,01 GridFre_AVG
0x0071 = 11,3  APower_AVG
0x0018 = 2,4   AEnergy
0x00a4 = 16,4  Temp_AVG

Hoffe die Kommaverschiebungen habe ich richtig inerpretiert.

Zu dem Zeitpunkt liefert der WR etwa 92mA und 6W

Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so 
dokumentiert.

[Daniel R. (daniel92)]

Sehr cool Pocki! :)

Damit alle Dokumente hier Hand und Fuß hat, würde ich mir wünschen statt 
alles in dem Forum zu Posten. Stattdessen auf Github zu laden, die Frage 
ist jedoch: Macht das Sinn?

Beste grüße.

[Ziyat T. (toe_c)]

Christian P. schrieb:
Super Christian!

> 0x0018 = 2,4   AEnergy
Das sollte 24Wh sein.

D.h. MI-300 und MI-1500 wegen der Anzahl Ports anders anzusprechen, echt 
mühsam

[Richard K. (laserrichi)]

Hallo,

da ich die bisher immer nur stiller mitleser war habe ich mich jetzt 
endlich angemeldet.

Ich habe einen Mi-600 und ich weis nicht ob ich hier was dazu beitragen 
kann.

Zuerst hatte ich etwas schwierigkeiten den ESP8266 zum laufen zu 
bringen.
Ich hatte die FW compiliert und geflasht und sah aber keinen acesspoint, 
auch der connect ins heimische wlan ging nicht (hatte es direkt beim 
compilieren schon mit rein)

Ffertige .bin von hier probiert, die 0.4.11  und 0.4.13 mit selben 
Ergebniss.
Die version 220519_ahoy_0.4.4_esp8266.bin  hatte endlich funktioniert, 
und konnte auch auf die 0.4.13 upgraden... dabei war mir aufgefallen das 
die settings mit vielen yyyyyy gefüllt waren.

Meine SN fängt mit 104161 an

[Daniel R. (daniel92)]

Hallo Richard,

also der letzte Update auf Github war vor ca 40min.
An sich gibt es verschiedene wege wie man das ganze auf den ESP bekommt.

Meines wissens nach ist der ganze Code noch nicht für den 
MI-Wechselrichter angepasst. Wäre es ein HM, dann wäre würde es schon 
besser klappen.

Du musst dich noch ein bisschen gedulden für die MI-Serie, da neue 
Erkentnisse erlangt worden sind und das demnächst nach und nach weiter 
aufgebaut wird. ;)

PS: yyyy sind übrigens nur "Platzhalter", die müsste man ersetzen.

[Andreas S. (drschiffler)]

Jan-Jonas S. schrieb:
> Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein
> Zertifikat sehen, dass das auch funktioniert.
> Im Wesentlichen wird das EVU fordern bei Dir eine
> Fern-Abschalteinrichtung einzubauen.
> Physikalisches Limit != Software Limit.
> Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine
> DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in
> Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal
> wegen Unterproduktion die Computer aus.
Hallo Jan-Jonas,

das sehe absolut genauso. Die Herausforderung ist nicht die Software.
Ich könnte meinem EVU sogar eine REST-API zur Fernabschaltung anbieten 
aber ich vermute wenn ich aktuell den vereinfachten Antrag ("600W") 
stelle mit: "Balkonanlage mit 2kwWp und Null-Export-Begrenzung" wird man 
damit nichts anfangen können und ggf. sagen, "...ja aber was ist mit der 
Blindleistung...". Selbst wenn ich das mit gekaufter Hardware mache. (Es 
gibt ja hier auch Nutzer von MI-1500, wie ist es hier gelaufen?)

Ich frage mich daher, es gibt ja diese Funktion. Das wird dann wohl von 
großen Anlagen genutzt (+ Blindleistungsanpassung)?

Hat da jemand Dokumente / Zertitikate von hoymiles die diese 
Regelungsfunktion laut Standard XY durch TüV, VDE o.ä. zertifizieren?
Danke für Hinweise.

[Daniel R. (daniel92)]

Konformitätszertifikat Erzeugungseinheit VDE AR-N-4105:2018-11
https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_EZE.pdf

Konformitätszertifikat NA-Schutz VDE AR-N-4105:2018-11
https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_NA.pdf

Nur das konnte ich finden.

EDIT: Hier gibts von jedem Hoymiles-WR ein Zertifikat.
https://www.shinetech-power.de/wechselrichter/hoymiles/

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> Konformitätszertifikat Erzeugungseinheit

Das gilt aber nicht für das Gerät mit selbst geschriebener Software oder 
selbst gebastelten Teilen des Komplettsystems :)

[isnoAhoy (Gast)]

Hallo Christian P.,
> Bingo - habe meinem MI-300 eine Antwort entlockt:
Na das ist doch mal eine freudige Nachricht!

> Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so
dokumentiert.

Das ist m.E. die Fehler Antwort, wenn der WR einige Events im Log hat, 
die man sich genauer ansehen soll. M.W. hat Jan-Jonas die Event Log 
Abfrage für die aktuellen HM-XXX Wechselrichter in der Raspberry 
Pi/Python Software bereits umgesetzt.

@Christian P., Ziyat T. & Richard K.,
vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos 
in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen 
?
Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das 
Programm an der Stelle zu testen / verifzieren..


Hallo Daniel R.,

> Damit alle Dokumente Hand und Fuß haben, würde ich mir wünschen - statt
alles hier ins Forum zu Posten - es stattdessen auf Github zu laden. Die 
Frage
ist jedoch: Macht das Sinn?

Es gab diverse Meinungen dass es nicht unbedingt sinnvoll ist den 
OpenSource Code mit den Closed Source Dokumenten auf GitHub zu mischen. 
Aber es spricht sicher Niemand dagegen, wenn Du die Dokumente auf Deinem 
Github in einem separaten Repository ablegst.

[Ziyat T. (toe_c)]

isnoAhoy schrieb:

> @Christian P., Ziyat T. & Richard K.,
> vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos
> in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen
> ?
> Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das
> Programm an der Stelle zu testen / verifzieren..
>
Ich würde gerne die ESP8266+nrf24 / Arduino+nrf24 Variante für den 
MI-1500 einsetzen.
Die SW-Staende kenne ich nicht (mehr).
Ich weiss dass die SW komplett auf HM zugeschnitten sind, darum ich 
braeuchte eine "Anleitung", wo und wie ich die Kommandos eingeben kann, 
natürlich auch die Antworten zu parsen.

Edit: hier sind die Kommandos/Antworten welche ich in der Luft gesehen 
habe. DTU-Pro<>MI1500
Daten
======================================================================== 
=
Anfrage v. DTU-Pro:
MID,WR,DTU,CMD
PV1: ...36(63 70 71 60|72 22 84 12)00
PV2: ...37(63 70 71 60|72 22 84 12)00
PV3: ...38(63 70 71 60|72 22 84 12)00
PV4: ...39(63 70 71 60|72 22 84 12)00

Anworten v. MI-WR:
MID,WR,WR,Data

PV1: ...b6(63 70 71 60|63 70 71 60)data
PV2: ...b7(63 70 71 60|63 70 71 60)data
PV3: ...b8(63 70 71 60|63 70 71 60)data
PV4: ...b9(63 70 71 60|63 70 71 60)data

36 00110110 > b6 10110110   bit8 gesetzt

37 00110111 > b7 10110111   bit8 gesetzt

Limitierung
======================================================================== 
=
Anfragen v. DTU-Pro:
51(63 70 71 60|72 22 84 12)5a 5a 0b 9e         0b = 11% power 
limitierung
Anworten v. MI-WR:
d1(63 70 71 60|63 70 71 60)5a 5a d1
51>d1 8 bit gesetzt

#define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF  0x51
//ŒÓËø&ÏÞÖƹŠÂÊ

#define CONTROL_LOCK_MI_SUB                 0xa5a5
#define CONTROL_LIMIT_POWER_SUB             0x5a5a
#define CONTROL_ON_SUB                      0x55aa
#define CONTROL_OFF_SUB                     0xaa55

[IsnoAhoy (Gast)]

Hallo Ziyat T.,
ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für 
HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80, 
MI-250/300/400 MID = 0x09, MI-600/700/800 MID = 0x09 & 0x11 sowie 
MI-1000/1200/1500 MID = 0x36..0x39
In der hmInverter.h müssen die Inverter Model ebenfalls mit getModel und 
setModel implementiert werden
In der hmSystem.h kann man dann in addInverter das Protokoll in einem 
switch je nach Modellnummer setzen.
Und dann kann man in der hmRadio.h die Methoden sendTimePacket den 
sendCmdPacket Aufruf anpassen mit case je nach Inverter getModel.
Das Mapping der Inverter Daten erfolgt dann wieder über die in hmDefines 
zu definierenden byteAssign_t miXchAssignment[] und deren Länge

Irgendwie müssen wir dem Code dann noch beibringen dass für die 
MI-Serien teilweise zwei/vier Cmd Pakete geschickt und ausgewertet 
werden müssen. Aber mit den og Anpassungen sollte es erstmal den ersten 
Kanal der MI-Modelle abfragen können.

@Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei 
so was umzusetzen?

[Lukas P. (lumapu)]

IsnoAhoy schrieb:

> @Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei
> so was umzusetzen?

Nein bin ich nicht und habe es auch nicht vor.

Ich fände es am besten, wenn man die Inverter Serie per template 
Parameter übergibt und sich damit vor dem kompilieren entscheiden muss.

Weiter würde ich es bevorzugen die hm*.h Dateien zu duplizieren und als 
mi*.h umbenennen. Dann bekommen wir jetzt nicht ein riesen Chaos und 
ständige if-else-switch Konstrukte. In naher Zukunft kann man dann 
Gemeinsamkeiten suchen und diese wieder generisch anlegen.

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:
> Hallo Ziyat T.,
> ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für
> HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80,

Danke,
Habe die https://github.com/lumapu/ahoy/tree/main/tools/esp8266 runter 
geladen, ohooo, ist ja was implementiert worden. Muss sagen da blicke 
ich nicht einfach schnell durch.
Ich habe die Version von April hier, mache mal damit weiter, ich muss ja 
zuerst sicher sein, was ich in der Luft sehe sollte auch implementiert 
werden und soll so laufen..

[Holger Skusa (Gast)]

Hallo, ich habe mit großem Interesse diesen thread gelesen und mir die 
4.4. Bin auf einem Wemos geflasht. Mir ist nur nicht klar was ich bei 
inverter Adress eintragen soll. Ich habe mehrere HM-300 die ich anfragen 
möchte. Irgendwie scheint die serial number ne Rolle zu spielen,aber wo 
finde ich die.
Kann mir mal jemand auf die Sprünge helfen. Habe ich was überlesen?

[Herbert K. (avr-herbi)]

Holger Skusa schrieb:
> ...Irgendwie scheint die serial number ne Rolle zu spielen,aber wo
> finde ich die.

Die S/N der WR findest Du auf der Rückseite vom WR. Also auf der planen 
Seite.

[Holger Skusa (Gast)]

Und diese Nummer ist dann bei Adress inverter  einzutragen? Oder muss 
die noch irgendwie gewandelt werden?

[Lukas P. (lumapu)]

normaler Weise so eintragen wie sie drauf steht.
Ich würde dir empfehlen die aktuelle 0.4.17 zu installieren, die muss 
allerdings selbst kompiliert werden.

[oxylog (Gast)]

Hallo euch allen!
Ich wollte euch allen, die an der großartigen Entwicklung beteiligt 
sind, danken.
Ich bin ein stummer „Mitleser“ mit einem HM-300, der zufällig auf dieses 
Forum und die Topic stieß.
Was „Elektrotechnik" angeht bin ich maximal Anfänger; Was 
Mikrocontroller angeht kompletter Laie und was Funk angeht mit noch 
weniger Fachwissen ausgestattet.
Leider kann ich nicht so viel zur Programmierung beitragen, da ich auch 
hier komplett fachfremd bin und mir die Zeit momentan fehlt, mir das 
alles anzueignen.

Dank euch und eurer tollen Dokumentation konnte ich das Projekt mittels 
eines „D1 mini“-clones und einem NRF24L01+PA+LNA (jetzt mit zusätzlicher 
„Schirmung“) realisieren.  Funktionierte, wie dokumentiert, problemlos 
„out of the box“.

Danke für euer Engagement! Ihr habt da „etwas Lust am Basteln" bei mir 
etwas geweckt ;-)

[Oliver R. (esp_loeter)]

Hallo zusammen,
ich habe einige Platinen machen lassen.
Wemos D1 mini und NRF24 zusammen auf einer Platine mit der Verdrahtung 
wie im GitHub beschrieben.
Ich habe noch einige Platinen übrig und würde die für 2€ pro Stück 
abgeben.
Einfach in ebay-Kleinanzeigen nach esp-dtu suchen...

[Ert (Gast)]

Hallo zusammen,

wollte auch ein Danke loswerden! also: DANKE! Geile Arbeit! Dickes Lob 
an die Community!

Ich habe es jezt alles auf einem Nodemcu laufen.

Meine PV Module sind noch nicht da, also hab ich dem HM-300 ans 
Labornetztteil gepackt. Wenn keine DC-Spannung anliegt geht das 
Funkmodul vom Umrichter nicht. AC muss aber nicht anliegen um das System 
zu testen.

Gruß Ert

[Holger Skusa (Gast)]

Hallo,
ich wünschte ich könnte mich auch bedanken. Aber leider will es noch 
nocht so richtig.
Ich habe die Serial Nummer meines HM-300 nun gefunden und in der 4.4 
eingetragen. Leider kommen keine Daten.
Nun versuche ich dem Tipp von Lukas zu folgen und die 4.17 zu 
kompilieren.

Meine Arduino ide bricht aber immer mit:


In file included from app.cpp:1:0:
app.h:4:18: fatal error: RF24.h: No such file or directory
 #include <RF24.h>
 ab.

HELP !!!

[Holger Skusa (Gast)]

Die Library von Git maniacbug/RF24 hab ich installiert...

[Günter H. (gnter_h534)]

Mit der Arduino IDE 1.8.19 und

- aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4)

sowie den LIBRARIES

- Time 1.6.1
- RF24 1.4.2
- PubSubClient 2.8

klappt es bei mir problemlos.

Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt.

[Alexander P. (drdownload)]

Eine Frage, gab es auch schon Versuche Werte zu setzen so wie es die DTU 
Pro macht? Die kann ja den Output begrenzen bzw. ein "Country Protection 
File" hochladen (theoretisch braucht man das für den regelkonformen 
Betrieb)

[Holger Skusa (Gast)]

Günter H. schrieb:
> Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt.

Du bist mein Retter des Abends !!!
Soeben habe ich meine ersten Werte empfangen. Das hat jetzt aber auch 
Stunden gekostet. Aber Danke für die Datei. Mit der Arduino IDE hab ich 
schon immer auf Kriegsfuss gestanden. Die mag mich irgendwie nicht.

Ich hab die IDE nun ganz neu installiert und alle von Dir angegebenen 
Librarys installiert. Das Board nach installiert usw.

Was soll ich sagen, nun geht auch das kompilieren.

Na dann kann ich wenigstens zukünftige Versionen selber bauen.

Vielen Dank an alle die das hier möglich gemacht haben. Klasse Sache !!!

Eine Frage hab ich noch:

Wie viele Inverter kann ein Wemos mit einem RF24 empfangen. Das ist ja 
im Sketch einstellbar. Ist da bei 3 Stück Schluss, oder würden auch 6 
gehen ?

Gruß Skusi, und allen einen schönen Wochenanfang...

[isnoAhoy (Gast)]

Hallo Holger Skusa,

also prinzipiell werden die WR nacheinander abgefragt, es wären also 
auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen:

#define MAX_NUM_INVERTERS       3
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/config.h#L33

Irgendwann wird halt der Speicher knapp und ich weiß noch nicht sicher, 
ob sich der Code problemlos auch auf einem ESP32 kompilieren läßt.

[isnoAhoy (Gast)]

Hallo Alexander P.,
bitte schau mal in das letzte Excel File hier im Thread:
* RF_communication_protocol-V6.5.xlsx (78,3 KB)
dort sind die offiziellen Hoymiles Kommandos und Antworten dokumentiert. 
Damit ist es dieser Tage auch gelungen, die MI-Wechselrichter zum reden 
zu bringen.

Auch die offizielle "Bibliothek" von Hoymiles ist hier im Thread:
* usart_nrf.c (147 KB)
dort habe ich beim Übersetzen auch die Power Profile und Firmware Upload 
Routinen gesehen.

Wenn Du die Raspberry Pi/Python Software von Jan-Jonas verwendest, dann 
kannst Du u.a. über MQTT eigene Kommandos an den Wechselrichter senden. 
In der ESP8266 Variante ist eine derartige Option aktuell noch nicht 
vorgesehen.

@Lukas P., hast Du evtl. vor eine derartige MQTT-Schnittstelle, o.a. zur 
Fernsteuerung der Wechselrichter einzubauen oder bist Du mit der reinen 
Auswertung der Daten soweit zufrieden ?

[isnoAhoy (Gast)]

Hallo Oliver R.,
kannst Du das Platinen Layout evtl. noch im GitHub committen bzw. einen 
PR erstellen ? Ich glaube ich habe nur die Fritzing Layouts gemacht aber 
kein Layout hochgeladen. Danke!

[Daniel M. (daniel_m821)]

Ziyat T. schrieb:
> Hallo
> Die Antwort
> channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d
> fa 01 3a 33
> Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert.
> D.h. dieser TSUN ist ein MI?
> Konntest du schon einen request schicken und TSUN hat geantwortet?

Hi,
habe noch keine Requests rausbekommen. Dieser Part scheint mir auch 
defekt zu sein, da Abweichungen in den Bytes sind, z.B. die WR-Adresse 
im ersten Teil.

Es könnte sein, dass der MI1500 mit dem TSUN ähnlich ist, auch die 
Chinesen erfinden nicht 3x das Rad neu.

Bin jetzt erst von Montage wiedergekommen und schaue die Tage, was ich 
noch rauskriege.

[Holger S. (skusi)]

isnoAhoy schrieb:
> also prinzipiell werden die WR nacheinander abgefragt, es wären also
> auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen:
Hallo, ich hab jetzt mit der Einstellung

#define MAX_NUM_INVERTERS       6

kompiliert. Funktioniert aber nur bis 5 Stk !
Ab 6 Inverter startet der Wemos nicht mehr durch.
In der Console meckert er:

Settings not valid, erasing ...

Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?

[Daniel M. (daniel_m821)]

IsnoAhoy schrieb:
> @Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg
> wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer
> versendet ?
>
> 10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ?
>
> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code.
> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf
> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten
> auf dem Kanal 2403GHz.

Ich kriege aktuell nichtmal ein Kommando raus, da ich mit Arduino noch 
nicht so fit bin und Python auch nicht gerade ein Küchenlicht ist.
Meine Freundin ist immer erst ca. 19 uhr zuhause, da ist auch nicht mehr 
viel mit Code und Sonne, es zieht sich also etwas. Bin aber auch 
gespannt auf dem Code am Ende :)
Eine Kurzanleitung, wie für den ESP die Kommandos zusammengesetzt 
werden, wäre hilfreich, Strom in allen Formen, Farben und 
Geschmacksrichtungen sind für mich kein Problem, aber Bytes schubbsen in 
C++ ist ne andere Geschichte.

Seriennummern drehen hab ich mit dem anderen NRF-Chip ohne externe 
Antenne noch nicht getestet, mache ich die Woche noch.

Ich hab noch nicht so ganz verstanden, was meine DTU zwischen dem was am 
NRF reinkommt und am Ende in der Luft landet, noch macht, da sind 
Unterschiede.

[Lukas P. (lumapu)]

Holger S. schrieb:
> #define MAX_NUM_INVERTERS       6
>
> kompiliert. Funktioniert aber nur bis 5 Stk !
> Ab 6 Inverter startet der Wemos nicht mehr durch.
> In der Console meckert er:
>
> Settings not valid, erasing ...
>
> Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?

Nein es gibt keine Limitierung auf 6 Stück. Ich glaube in main.cpp oä 
wird new EEP(1000) oä aufgerufen. Die 1000 ist die Länge des 
zugreifbaren Eeproms oder besser gesagt emuliertes Eeprom also Flash.
Diese Zahl darf maximal 4096 sein. Zusätzlich muss in defines.h noch die 
Speicherposition vom SettingsCRC nach oben verschoben werden z.B. 1500

[Ziyat T. (toe_c)]

Hallo
@Daniel M.,@IsnoAhoy, @Hubi

Da ich schon früher Hubi's code verwendet habe, hab die letzte 
Git-Version von ihm angepasst/vergewaltigt;-)
Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD)
36 63 70 71 60 72 22 84 12 00
37 63 70 71 60 72 22 84 12 00
38 63 70 71 60 72 22 84 12 00
39 63 70 71 60 72 22 84 12 00
oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts!
nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an 
meine DTU-Pro, wenn sie eingeschaltet ist.
Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde 
ein neues nrf24 besorgen und damit ausprobieren.

[Daniel M. (daniel_m821)]

Ziyat T. schrieb:
> Da ich schon früher Hubi's code verwendet habe, hab die letzte
> Git-Version von ihm angepasst/vergewaltigt;-)
> Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD)

Hi, das selbe an meiner Front gerade.
D1 mini: 11 63 50 03 16 63 50 03 16 00 11 2E BA

> oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts!
> nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an
> meine DTU-Pro, wenn sie eingeschaltet ist.
> Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde
> ein neues nrf24 besorgen und damit ausprobieren.

Futsch isser sicher nicht. Solange wir nicht klar sagen können, was 
unsere Außenseiter genau hören wollen, bleiben die für uns stumm.

Die Scanner-Programme, die ich probiert habe, kriegen entweder nix 
(falsche Rx-Adressen) oder ich sehe z.B. in der originalen 
scanner-Anwendung der NRF-Libary aus den Beispielen nur die Kanäle wo 
was aufploppt, jedoch nicht was.

Ich kann bisher nicht sagen, wie die CRC aufgebaut ist oder was genau 
durch die Luft gesendet wird.

Morgen neuer Versuch, WR geht gleich schlafen :)

Angepasst habe ich erstmal in der hmRadio.h:

 void sendTimePacket(uint64_t invId, uint32_t ts) {
            //DPRINTLN(F("hmRadio.h:sendTimePacket"));
            sendCmdPacket(invId, 0x11, 0x91, false);
            mTxBuf[9] = 0x00; // cid
            mTxBuf[10] = 0x11;
            //CP_U32_LittleEndian(&mTxBuf[12], ts);
            //mTxBuf[19] = 0x05;

            uint16_t crc = crc16(&mTxBuf[10], 14);
            mTxBuf[11] = (crc >> 2) & 0xff;
            mTxBuf[12] = (crc     ) & 0xff;
            mTxBuf[13] = crc8(mTxBuf, 13);

            sendPacket(invId, mTxBuf, 14, true);
        }

Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine 
geänderten Dateien?

[isnoAhoy (Gast)]

Hallo Daniel M.,
also Du musst zwei Pakete senden, aber zwischendrin erstmal die Antwort 
abwarten:
Probiere mal:
1. sendCmdPacket(invId, 0x09, 0x00, true);
2. laß den Rest der Routine unter sendTimePacket einfach mal weg.

Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen 
timestamp oder gar eine CRC_16.
Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true 
berechnet und angehängt wird sollte eigentlich genug sein.

Er sollte dann z.B. folgendes Senden:
D1 mini: >09< <52 40 36 68> <63 50 03 16> >00< 11
Hier ist die 11 ganz vorne die MID (s.o.) dann die sollte die Serien 
Nummer der DTU als Routing Addresse (hier die antike DTU 10F052403668) 
folgen und dann erst die Serien Nummer des WR als Target Adresse 
(Routing und Target Adresse ist offenbar bei den MI-Wechselrichtern 
vertauscht). Die 00 sind die User data und dann kommt nur noch die CRC_8 
hier einfach mal 11 gelassen, sollte eigentlich richtig berechnet 
werden. Die Start und Stop-Bytes 0x7e und 0x7f hängt i.d.R. der 
nRF25L01+ automatisch dran.
Als Antwort bekommst Du dann 0x88 (status) / 0x89 (data) ...

Das selbe sollte auch mit 0x11 als MID funktionieren für den zweiten 
Kanal.
Also Antwort kommt dann eben 0x91 (data?) / 0x92 (status?) ...

Warum bei 0x11 die Reihenfolge von status und data umgekehrt sein soll, 
wissen vermutlich nichtmal die Hoymiles-Götter. Aber das Excel Sheet 
"RF_communication_protocol-V6.5.xlsx" widerspricht sich hier auch 
selbst. Vermutlich wurde es erst nachträglich korrigiert (rot auf "Data 
collection instructions" in Zellen B94 und B99)

@Ziyat T.,
Für Dich gilt m.E. genau das selbe, lediglich sollte als MID 0x36..0x39 
für die vier Kanäle verwendet werden.

Als Antwort kommt dann 0xB6... .. 0xB9... (data & status)

Viel Erfolg

[isnoAhoy (Gast)]

Hallo Holger,
wie Lukas schon erwähnt hat in eep.h:
            EEPROM.begin(4096);

und in den defines.h das Ganze gleich dynamisch gestalten:

#define ADDR_SETTINGS_CRC   ADDR_NEXT          + CRC_LEN

#if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
#error address overlap!
#endif

#if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
#error EEPROM size exceeded! Configure less inverters?
#endif

[Ziyat T. (toe_c)]

@Daniel M.
> Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine
> geänderten Dateien?

Wie gesagt, ich verwende Hubi's Code auf Arduino+nrf24, kein 
hmRadio.h,app.cpp

@isnoAhoy
> Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen
> timestamp oder gar eine CRC_16.
> Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true
> berechnet und angehängt wird sollte eigentlich genug sein.

Welches ist das alte MI-Protokoll? bis zum MI-600?
Meine DTU-Pro sendet zum MI-1500 ganz klar CMD 0x36 bis 0x39 mit SubCMD 
0x00, CRC 0xFx, sonst nichts:
60 71 70 63 01 (11/3/0) 39(63 70 71 60|72 22 84 12)00 fd[67 ed]
60 71 70 63 01 (11/1/0) 38(63 70 71 60|72 22 84 12)00 fc[a2 51]

Ich muss mal andere Kanaele nochmals lauschen, ob der WR was anderes 
braucht

Ps: Könnten wir uns auf die Bezeichnungen CMD und SubCMD einigen?

[Holger S. (skusi)]

Vielen Dank isnoAhoy, ich werde das mal bei Gelegenheit so versuchen. 
Fließt das dann auch in die nächste Version mit ein ?

Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen 
Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem 
Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate 
ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten 
und den Namen ändern.
Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.

[Daniel M. (daniel_m821)]

Habe den Code von Hubi etwas angepasst:
NRF24_SendRcv.ino:

    if (tel == 0) {
      #ifdef ESP8266
      hmPackets.SetUnixTimeStamp (getNow());
      #endif
      size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8);
    }
    else if (tel == 1)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x89);
    else if (tel == 2)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x91);
    else if (tel == 3) {
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83);
      //tel = 0;
    }
    else if (tel == 4)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x88);
    else if (tel == 5)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x92);

    SendPacket(dest, (uint8_t *)&sendBuf, size);

    tel++;

Settings.h

// WR und DTU
#define DUMMY_RADIO_ID          ((uint64_t)0xDEADBEEF01ULL) 
#define SerialWR                0x104163500316ULL        // <<<<<<<<<<<<<<<<<<<<<<< anpassen
uint64_t WR1_RADIO_ID           = Serial2RadioID (SerialWR);    // ((uint64_t)0x5279607201ULL);          
#define DTU_RADIO_ID            ((uint64_t)0x7311880801ULL)

Das Ergebnis:

20:19:58.728 -> Send... CH75
20:19:58.774 -> 00 7311880801 0092 12 1  92 63500316 63500316 000300000000000091D09E 1
20:19:58.774 -> ---- neues cmd=0
20:19:58.774 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 145.00 37328.00 53406.00 40502.00 13878.00 13981.00 
20:19:58.774 -> analyse words:50331648.00 0.00 0.00 0.00 145.00 37328.00 9556126.00 2446368256.00 3500029440.00 2654353152.00 909548928.00 916290496.00 

20:20:03.760 -> 00 7311880801 0094 12 2  88 63500316 63500316 00030000000000008B7436 1
20:20:03.760 -> ---- neues cmd=0
20:20:03.760 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 139.00 35700.00 29750.00 13867.00 11083.00 19437.00 
20:20:03.760 -> analyse words:50331648.00 0.00 0.00 0.00 139.00 35700.00 9139254.00 2339649024.00 1949707136.00 908807168.00 726396352.00 1273878016.00

20:20:49.802 -> 00 7311880801 00C0 18 0  91 63500316 63500316 012D0001095D1389003D085D00FFE550EF 1
20:20:49.802 -> P1.Udc  :26.50 
20:20:49.802 -> P1.Idc  :238.27 
20:20:49.802 -> P1.Pdc  :3507.20 
20:20:49.802 -> P2.Udc  :1562.40 
20:20:49.802 -> P2.Idc  :238.08 
20:20:49.802 -> P2.Pdc  :6550.90

Log anbei.
Die etwas anders aussehenden Zeilen sind aus dem Python-Mitschnitt und 
zeitlich relativ passend.
Die Werte stimmen natürlich noch nicht, aber hey, der WR redet mit mir 
:)

Der tel==3 Part passt noch nicht, wird aber offenbar nicht benötigt.

Ein kleiner weiterer Schritt in die richtige Richtung.

Danke Euch allen!

[Lukas P. (lumapu)]

Holger S. schrieb:
> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen
> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem
> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate
> ein neues Gerät zu bekommen.

Das wurde einfach aus dem Beispiel der MQTT lib übernommen, schau mal in 
der mqtt.h relativ weit unten, der neue Name wird 'extra' erzeugt, warum 
kann ich nicht sagen, evtl. findet man bei PubSubClient (so heißt die 
lib) etwas darüber.

Bei der nächsten Speicheränderung können wir den CRC wie isnoAhoy 
geschrieben hat noch weiter nach hinten schieben. Mit 6 WR bist du 
aktuell Spitzenreiter und musst sowieso selbst kompilieren. Bin gespannt 
ob das funktioniert. Ich glaube bis zu 4 wurden schon getestet.

[Marcel A. (a-marcel)]

Hallo,

habe seit langem mal wieder den Code geupdated und vorher hat alles sehr 
gut funktioniert aber mit dem neusten update bekomme ich gar keine Daten 
mehr. Ich sehe nur noch

Error while retrieving data: last frame missing: Request Retransmit
Error while retrieving data: last frame missing: Request Retransmit
Free heap: 0x430f8
Inverter #0 no Payload received! (retransmits: 0)
Requesting Inverter SN val = 0x112173109025

Gerät wurde nicht bewegt (Antenne ist gleich) und vor dem update ging es 
tadellos. Habe einen HM-400. Hat noch jemand das Problem ?

Vielen dank

P.s.: Ich habe was gelesen, das man jetzt schon weit ist die Einspeisung 
zu kontrollieren ? Ist das korrekt ?

[Lukas P. (lumapu)]

Hast du auch den Gegencheck mit der alten Version gemacht?
Ich habe zugegeben auch immer wieder Probleme, aber ich denke es liegt 
sehr stark an der Umgebung und die ändert sich doch mehr als man es 
erwarten würde. Gestern habe ich den ESP unters Dach getragen und 
ständig mit Abstürzen zu helfen gehabt (Wifi?) und heute konnte ich 
wieder aus dem Keller funken (aber auch nur in einer exakten 
Ausrichtung). Liegt die Antenne bisschen anders bekomme ich keine Frames 
rein. Ich hoffe die Ausrichtung passt morgen noch ...

Die Einspeisung zu reduzieren gilt bisher nur für die MI Serie - und 
dort wird grad heftig an der Kommunikation der ersten Daten geschraubt. 
Also bisher kann man noch keinen WR begrenzen.

[Ziyat T. (toe_c)]

Daniel M. schrieb:
> Habe den Code von Hubi etwas angepasst:
> NRF24_SendRcv.ino:

Gratuliere :-)

Ich mache so, aber ohne erfolg:

uint8_t MID = 0x36;   //0xB9=0x39      0xB8 38
uint8_t CMD = 0;
.
.
if (tel > 5)
tel = 0;

if (MID > 0x0039)
MID= 0x0036;

if (tel == 0) {
  #ifdef ESP8266
  hmPackets.SetUnixTimeStamp (getNow());
  #endif
  //do not need size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest 
>> 8, DTU_RADIO_ID >> 8);
  }
else
  size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, 
DTU_RADIO_ID >> 8, MID, CMD);

SendPacket (dest, (uint8_t *)&sendBuf, size);
MID++;
tel++;

[IsnoAhoy (Gast)]

Hallo Marcel A.,
bzgl Power Limitation würde ich Doch auf das o.a. Excel Sheet 
"RF_communication_protocol-V6.5.xlsx" verweisen.
Da steht mE alles drin was in der DTU Pro an Request und Response von 
MI-&HM-Wechselrichtern verstanden und gesendet wird. U.a. sind da auch 
die Kommandos zur Power Limitierung auf X % enthalten. Speziell auf der 
Seite „control commands“ findet sich das Limit Power command word 0x51 
subcommand 0x5A5A und die Antwort 0xD1.
Die Implementierung der Kommandos von Hoymiles dazu findest Du in der 
o.a. usart_nrf.c (147 KB).

@Ziyat T. und Daniel M.,
ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer 
noch ein Timestamp mitgesendet zu werden.
Laut der Command Word Summary sind die Commands words (früher hier MID) 
für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11 
(optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse 
MI-1000..1500)
Das Command word für die HM-Serie ist durchweg 15 und die Antwort 95.
Bitte schaut Euch doch mal die Screenshots aus dem Excel bzw. die 
entsprechenden Command words auf der Seite „data collection 
instructions“ unterhalb der Zeile „Legacy poll data command“ an.
Dort ist nach der Target Address nur noch das Subcommand / Userdata 00 
und die CRC-8, aber kein Timestamp wie beim Command word 15 für die 
HM-Serie.

[Ms L. (mslookup)]

Hallo zusammen,
auch wenn es nicht ganz zum aktuellen Stand der Unterhaltungen hier im 
Forum passt: Nachdem ich mehrere Stunden an mehreren Tagen verzweifelt 
probiert habe die NRF24 Python Library, also die Dependency für die 
Raspberry Version von Ahoy, korrekt zu installieren, habe ich mich 
gestern direkt an den Entwickler von NRF24 über github gewendet 
(https://github.com/nRF24/RF24/issues/845) - da ich, egal wie ichs 
gedreht und gewendet bekommen habe, den Python Wrapper für NRF24 nicht 
installiert bekommen habe.

Ich würde gerne meine Schritte weitergeben, sollte jemand an dem selben 
Punkt verzweifelt sein wie ich.

- Install Raspberry Pi OS lite x86 with raspberry pi imager
- Connect nrf24 module to raspberry pi (as described in github)
- Login with user pi
- Execute "sudo apt update && sudo apt -y upgrade"
- Execute "sudo raspi-config" and
-- "Expand filesystem" in "Advanced Options"
-- Activate "SPI" in "Interface Options"
-- "Finish" to exit raspi-config Tool, reboot YES!
- Login as pi user again

sudo apt install cmake git python3-dev libboost-python-dev python3-pip python3-rpi.gpio
sudo ln -s $(ls /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3*.so | tail -1) /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3.so
git clone https://github.com/nRF24/RF24.git
export RF24_DRIVER=SPIDEV
cd RF24
rm Makefile.inc #just to make sure there is no old stuff
mkdir build && cd build
cmake ..
make
sudo make install
cd ../pyRF24
rm -r ./build/ ./dist/ ./RF24.egg-info/ ./__pycache__/ #just to make sure there is no old stuff
python3 -m pip install --upgrade pip
python3 -m pip install .
python3 -m pip list #watch for RF24 module - if its there its installed
cd ..
cd examples_linux/
python3 getting_started.py # to test and see whether RF24 class can be loaded as module in python correctly

Wenn im letzten Schritt keine Fehlermeldungen kommen, dann sollte der 
NF24 Wrapper erfolgreich installiert sein.

Danke euch allen für eure Arbeit :)

[Daniel M. (daniel_m821)]

IsnoAhoy schrieb:
> @Ziyat T. und Daniel M.,
> ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer
> noch ein Timestamp mitgesendet zu werden.
> Laut der Command Word Summary sind die Commands words (früher hier MID)
> für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11
> (optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse
> MI-1000..1500)

Die 0x09 und 0x11 mit den Antworten 0x88,0x89 sowie 0x91 unx 0x92 sind 
beim TSUN identisch mit dem was ich aus der MI-Serie gesehen habe. 
Offenbar haben die Chinesen einfach das MI-Modell kopiert.

Der Timestamp wird gesendet, die Funktion bewirkt aber garnichts, der WR 
ignoriert das einfach.
Hubi verwendet einfach ein i++ um den CMD hochzuzählen und entsprechende 
Abfragen zu schicken, zu sehen in dem Post weiter oben. Die passende pid 
für die Antwort wird gleich mitgegeben.

Mittlerweile hab ich auch die Felder zu den Antworten passend gemappt.
Der Part nach der WR-Temperatur fehlt mir noch, ich bin nicht sicher ob 
das CRC16 oder noch Werte sind, da mit die Gesamtproduktion der MPPT 
noch fehlt.
Weiter fehlen auch noch die Statusbytes. Vielleicht kriege ich das heute 
abend noch hin.

> Probiere mal:
> 1. sendCmdPacket(invId, 0x09, 0x00, true);
> 2. laß den Rest der Routine unter sendTimePacket einfach mal weg.

Der Teil ist mir ehrlich gesagt, zu hoch. Ich weiß nicht an welcher 
Stelle ich das einfügen soll.
Wenn du mir da kurz auf die Sprünge hilfst, teste ich das gerne.
Eventuell kannst du auch kurz was zaubern, womit ich 0x09 und 0x11 im 
Wechsel senden kann, dann probier ich mich mit dem Einbau daran aus.

[redien (Gast)]

Hallo,
die Platinen sind wahrscheinlich schon weg oder? Konnte leider nichts 
finden und könnte 3 Stück gebrauchen.
Danke und Gruß

[IsnoAhoy (Gast)]

Hallo Daniel M.,
ja, der TSUN scheint nur ein rebrandeter Hoymiles MI-Wechselrichter zu 
sein. Das hatten wir aufgrund der Seriennummer auch schon vermutet.

Meine Angaben bezogen sich auf den code von Lukas unter tools/esp8266 da 
ich den Rest für Nano und die nrfScan tools von Hubi und anddren nie 
genutzt habe.

Speziell bezog sich 1. & 2. auf die hmRadio.h Zeile 162ff

https://github.com/grindylow/ahoy/blob/e05d2220cb1f99bbbf4083d62b0281d096ceeccb/tools/esp8266/hmRadio.h#L162

[IsnoAhoy (Gast)]

Hallo Daniel M.,

habe mir den code nochmal genauer angesehen und vermutlich kannst Du die 
beiden Aufrufe von sendTimePacket und die anderen Aufrufe von 
sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe 
ersetzen und anpassen.

app::loop
Ab Zeile 295ff kommt die Senderoutine:
https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L339

app::processPayload
hier erfolgt das Lesen und Sammeln der Payload Fragmente und der bisher 
HM spezifische Retransmit:

https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L413

Im zweiten Teil dem processPayload könntest Du also nach Empfang der 
ersten Antwort 0x89 die zweite Anfrage 0x11 stellen und auf die Antwort 
0x91/0x92 warten. Dann solltest Du die Antworten jeweils in den 
Variablen/Strukturen ablegen und mit den Definitionen in miDefines.h 
(Kopie von hmDdfines.h) auslesen.

[Ameise (Gast)]

nur zur Info:  Habe ich bei ebay-kleinanzeigen gefunden

[oxylog (Gast)]

Guten Morgen!
Leider bin ich noch Anfänger auf dem Gebiet, habe mich aber an einem 
PCB-Design versucht, welches ich hier angehängt habe (habe keinen 
Github-Account; kann bei Gefallen gerne dort übernommen werden).

Designt mit EasyEDA;
Ich habe versucht, Platinenplatz einzusparen und gleichzeitig auch noch 
die Pins nochmals anzulegen (für weitere Spielereien wie 5/3,3v externe 
Stromversorgung ohne Löten etc). Ebenfalls habe ich den 100µF (oder 
andere Größe nach Belieben; das µ wollte mir das Programm nicht auf das 
Board beschriften ;-)) Kondensator zwischen GND und 3,3v auf das Board 
gepackt.

Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€.

Verbesserungsvorschläge gerne willkommen

[oxylog (Gast)]

oxylog schrieb:
> Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€.

kleiner Edit: 3 Boards habe ich bei Aisler für unter 10€ geordert

[Damian B. (damian_b)]

Hallo, ich habe ein Problem mit meiner ide. Ich bin weit weg von zu 
Hause und kann es nicht lösen. Könnte jemand bitte hier eine bin-Datei 
mit der neuesten Version für ESP anhängen. Danke im Voraus

[Günter H. (gnter_h534)]

Für das Wemos D1 mini-Board ist das hier:

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
>

sudo python3 -um hoymiles --log-transactions --verbose --config 
>     from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, 
> RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
> ImportError: 
> /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: 
> undefined symbol: _ZN4RF2410setPALevelEh
>

Sieht nach einer kaputten Installation des RF24-Moduls aus. Warte noch 
ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01, was man 
einfach komplett mit pip installieren kann. Kein fuckery mehr mit 
irgendwelchen selbst kompillierten blobs im System verteilen, die nur 
kompillieren, wenn man sie im richtigen Unterverzeichnis kompilliert.

```
ModuleNotFoundError: No module named 'cross.crossunixccompiler'
```

[Peter L. (leliep)]

Ameise schrieb:
> nur zur Info:  Habe ich bei ebay-kleinanzeigen gefunden

Da hat sich ja die Arbeit der Community gelohnt…

[Daniel M. (daniel_m821)]

IsnoAhoy schrieb:
> Hallo Daniel M.,
>
> habe mir den code nochmal genauer angesehen und vermutlich kannst Du die
> beiden Aufrufe von sendTimePacket und die anderen Aufrufe von
> sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe
> ersetzen und anpassen.

Hi,

Danke, ich versuche es mal die kommenden Tage.
Mit etwas experimentieren habe ich zumindest schonmal eine Payload 
gesehen, auch wenn das noch nicht zuverlässig geklappt hatte.

Deine Hinweise auf die Stellen schaue ich mir genauer an, an einigen 
Stellen war ich schon dran.

[Damian B. (damian_b)]

Meine ESP-Version 4.17 hat ein Problem, ich kann es nicht anpingen, das 
www funktioniert nicht, manchmal ist es 2 Minuten nach dem Start. Mir 
ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1 
Sekunde aktualisiert wird, ist das richtig?

[Holger S. (skusi)]

Ameise schrieb:
> nur zur Info:  Habe ich bei ebay-kleinanzeigen gefunden

Sauerei, das sich da wieder jemand dran bereichern muß.
Kann man da nix gegen machen ?

Pfui ! von mir...

[Holger S. (skusi)]

Ein paar Fragen:
Wenn ich in der config.h folgendes eintrage:

// fallback WiFi info
#define FB_WIFI_SSID    "Flackerlighter"
#define FB_WIFI_PWD     "meinPasswort"

1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem 
WLan auf ?
Console:

Main::setupStation
connect to network 
'⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮ 
⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮'  ...
...............................
........................................................................ 
............................
Main::setupAp

---------
AP MODE
SSDI: AHOY-DTU
PWD: esp_8266
Active for: 60 seconds
---------

2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert 
verwendet ?

3. Wie genau sind die Statistic Werte zu verstehen:
Receive success: 18
Receive fail: 17
Send Cnt: 128

sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ?

Gruß Skusi

[Holger S. (skusi)]

isnoAhoy schrieb:
> Hallo Holger,
> wie Lukas schon erwähnt hat in eep.h:
>             EEPROM.begin(4096);
>
> und in den defines.h das Ganze gleich dynamisch gestalten:
>
> #define ADDR_SETTINGS_CRC   ADDR_NEXT          + CRC_LEN
>
> #if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
> #error address overlap!
> #endif
>
> #if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
> #error EEPROM size exceeded! Configure less inverters?
> #endif

Hallo isnoAhoy,
ich habe die Änderungen so in die Dateien eingepflegt, aber sobald ich 
mehr als 4 inverter in die config.h eintrage bootet der Wemos nicht und 
sendet.
Settings not valid, erasing ...

???

[Einhart P. (einhart)]

Holger S. schrieb:
> Sauerei, das sich da wieder jemand dran bereichern muß.
> Kann man da nix gegen machen ?
>
> Pfui ! von mir...

Kannst du ausschließen dass jemand die Software selbst entwickelt hat?

[Daniel R. (daniel92)]

Jan-Jonas S. schrieb:
> Warte noch
> ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01

Moin Jonas, danke für die Antwort. :)
Ok, du bist schon dabei das ganze miteinander zu kombinieren?

Kann ich irgendwie helfen?

Mein Ziel ist es zukünftig alles direkt am Pi zu betreiben. Dann brauch 
ich nicht extra noch ein WiFi-Client ins Netz zu halten. :P

[Lukas P. (lumapu)]

Damian B. schrieb:
> Mir ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1
> Sekunde aktualisiert wird, ist das richtig?

ja, das hat isnoAhoy geändert und führt bei uns zu stabileren Systemen. 
Es hängt jetzt fix am Abfrageintervall, die Zeit wird sogar auf der 
Index Seite ausgegeben
(also wie lange das Intervall ist)

[Lukas P. (lumapu)]

Holger S. schrieb:
> 1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem
> WLan auf ?

Habe es selbst nie getestet, nur implementiert. Evtl findest du den 
Fehler?

> 2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert
> verwendet ?

Die kWp der angeschlossenen Module. Hiermit wird die Einstrahlung in 
Prozent berechnet, ganz interessant um zu wissen wie optimal deine 
einzelnen Module stehen.

> 3. Wie genau sind die Statistic Werte zu verstehen:
> Receive success: 18
> Receive fail: 17
> Send Cnt: 128
>
> sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ?

Success heißt die komplette Payload wurde empfangen. Fail sind 
dementsprechend die fehlgeschlagenen Payloads.
SendCnt sind alle gesendeten Frames, auch Retransmits. In besten Fall 
wäre success und SendCnt identisch und fail auf 0.

[Lukas P. (lumapu)]

Einhart P. schrieb:
> Holger S. schrieb:
>> Sauerei, das sich da wieder jemand dran bereichern muß.
>> Kann man da nix gegen machen ?
>>
>> Pfui ! von mir...
>
> Kannst du ausschließen dass jemand die Software selbst entwickelt hat?

Kann man nicht, aber sie wird sehr sicher auf unseren Erkenntnissen 
aufbauen. Wie sieht es denn lizenztechnisch hier aus? Ich denke ua., 
dass Christian Bauer hier auch mitliest.
@Jan-Jonas: Ich glaube du bist auf diesem Gebiet fit, was sollen wir für 
die (nahe) Zukunft machen?

Für mich sieht es so aus als würde sich jemand mit unserem Wissen zu 
bereichern, irgendwie arm, hoffentlich ein Einzelfall. Bei einem Preis 
von 10€ könnte man nichts sagen, aber hier ist eine Marge von 40€ 
veranschlagt.
Der kostenlose Support wird von Mikrokontroller.net geleistet oder wie?

[isnoAhoy (Gast)]

Hallo Holger S.,

ja das ist erstmal richtig, Du hast ja eine größere Config und die CRC 
Summe ist weiter nach hinten gerutscht, somit stimmt das nicht mehr und 
er löscht alle Settings (außer den WiFi Settings).

Du mußt dann im Setup die Wechselrichter Daten wieder eintragen. Ich 
glaube da gab es ein Problem, daß er aktuell keine sinnigen Default 
Werte einträgt sondern alles mit 0xFF auffüllt. D.h. Du mußt Alles in 
den Settings entfernen und nur die relevanten Teile eintragen. Da auch 
die Pin Settings fehlen kann er auch keinen nRF24 finden und startet 
immer wieder neu bzw. den Access Point.

Du kannst auch mal die folgenden u.a. Einträge mit #pragma error 
versuchen, vielleicht bekommst Du dann auch etwas mehr Debug Output. Ich 
weiß nämlich ehrlich gesagt nicht, wieviele Bytes eine Inverter Config 
groß ist ?

#define INV_CH_CH_NAME_LEN  MAX_NUM_INVERTERS  MAX_NAME_LENGTH  4 // 
(4 channels)

Laut der defines.h reserviert er immer vier Kanalnamen plus den 
Inverternamen à 16 Byte, also 5*16 Byte. Das sollten bei ca. 200 Byte 
für die WIFI und MQTT Settings ca. 100 Byte mal sechs Inverter weit 
unter 4096 sein.

#define ADDR_SETTINGS_CRC   ADDR_NEXT          + CRC_LEN

#if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
#pragma error "address overlap! (ADDR_SETTINGS_CRC="+ ADDR_SETTINGS_CRC 
+", ADDR_NEXT="+ ADDR_NEXT +")"
#endif

#if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
#pragma error "EEPROM size exceeded! (ADDR_SETTINGS_CRC="+ 
ADDR_SETTINGS_CRC +", CRC_LEN="+ CRC_LEN +")"
#pragma error "Configure less inverters? (MAX_NUM_INVERTERS=" + 
MAX_NUM_INVERTERS +")"
#endif

PS: Support-Anfragen der Käufer solange unsere Software noch so schöne 
Macken wie "Settings not valid, erasing ..." hat sind da bestimmt schon 
inklusiv =^p

[Lukas P. (lumapu)]

So das Angebot in Kleinanzeigen ist deaktiviert, Dank meiner Frau.

Evtl. sollten wir zusätzlich diese Lizenz aufnehmen um unsere Belange 
besser auszudrücken:

https://commonsclause.com/

Wir machen das hier für die Community, also Maker und nicht für 
jedermann. Alle anderen sollen bei hoymiles eine DTU kaufen.

[Peter L. (leliep)]

Einhart P. schrieb:
> Holger S. schrieb:
>> Sauerei, das sich da wieder jemand dran bereichern muß.
>> Kann man da nix gegen machen ?
>>
>> Pfui ! von mir...
>
> Kannst du ausschließen dass jemand die Software selbst entwickelt hat?

Das Gehäusedesign stammt jedenfalls von mir.
https://github.com/grindylow/ahoy/tree/main/tools/esp8266/WemosD1_NRF24_Case

[isnoAhoy (Gast)]

@Jan-Jonas & Lukas

the current implementation we use for HM-inverters seems to be in the 
Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or 
`usart_nrf3.h`.
There are also the user data starting with `0x80` in `byte[10]` and 
after that the Sub Command mentioned in the Excel sheet.

```
/***********************************************
** Function name: �豸����
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
uint8_t UsartNrf3_Send_PackDevControl(uint8_t *target_adr, uint8_t 
*rout_adr, uint16_t ControlMode, uint8_t *ControlData, uint8_t Num)
{
    uint8_t i = 0;
    uint16_t TempCrc = 0;
    uint8_t temp_dat[UART_LEN];
    uint16_t DatCrc = 0xffff;
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//ͷ
    temp_dat[0] = DEVCONTROL_ALL;   //command
    memcpy(&temp_dat[1], target_adr, 4);//Դ��ַ
    memcpy(&temp_dat[5], rout_adr, 4);//Ŀ���ַ
    temp_dat[9] = 0x80;//
    temp_dat[10] = ControlMode >> 8; //��������
    temp_dat[11] = ControlMode;//��������
    //CurSendPackageDataType = ControlMode;
    memcpy(&(temp_dat[11]), ControlData, Num); //���Ʋ���

    for(i = 10; i < 11 + Num + 1; i++)
    {
        if((i - 10) % 2 == 1)
        {
            TempCrc = (temp_dat[i - 1] << 8) | (temp_dat[i]);
            DatCrc =  CalcCRC16t(TempCrc, DatCrc);
        }
    }

    temp_dat[12 + Num] = DatCrc >> 8;
    temp_dat[13 + Num] = DatCrc;
    temp_dat[14 + Num] = Get_crc_xor(&temp_dat[0], 15 + Num);
    i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], (15 + 
Num)); //�����滻
    Uart_SendBuffer[(i + 1)] = ETX; //β
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}
```

According to the implementation in `usart_nrf3.h` the Sub Command is 
defined as `DataType` in `usart_nrf3.h`:
```
typedef enum
{
    InverterDevInform_Simple = 0, // 0x00
    InverterDevInform_All = 1, // 0x01
    GridOnProFilePara = 2, // 0x02
    HardWareConfig = 3, // 0x03
    SimpleCalibrationPara = 4, // 0x04
    SystemConfigPara = 5, // 0x05
    RealTimeRunData_Debug = 11, // 0x0B
    RealTimeRunData_Reality = 12, // 0x0C
    RealTimeRunData_A_Phase = 13, // 0x0D
    RealTimeRunData_B_Phase = 14, // 0x0E
    RealTimeRunData_C_Phase = 15, // 0x0F
    //RealTimeRunData_Password = 16, // 0x10
    AlarmData = 17, // 0x11
    RecordData = 18, // 0x12
    InternalData = 19, // 0x13
    ExternalData = 20, // 0x14
} DataType;
```
Especially the 0x0B rings a bell with me and the traces so far!

[isnoAhoy (Gast)]

Sorry that was the wrong function / method and the references in the 
Excel sheet e.g. `byte[10]` are including the SOF `0x7E`, whilst the 
implementation first sets up `temp_dat[]` which is without the SOF and 
EOF `0x7F`, hence the shift.

```
/***********************************************
** Function name: �豸������Ϣ���
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
uint8_t UsartNrf3_Send_PackDataCommand(uint8_t *target_adr, uint8_t 
*rout_adr, uint8_t DataType, uint8_t DataMode, uint8_t Gap, uint8_t 
*Password)
{
    uint8_t i = 0;
    uint16_t TempCrc = 0;
    uint8_t temp_dat[UART_LEN];
    uint16_t DatCrc = 0xffff;
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//ͷ
    temp_dat[0] = 0x15;   //command
    memcpy(&temp_dat[1], target_adr, 4);//Դ��ַ
    memcpy(&temp_dat[5], rout_adr, 4);//Ŀ���ַ
    temp_dat[9] = 0x80;//��֡��ʶ
    temp_dat[10] = DataType;//�û�����:��������
    CurSendPackageDataType = DataType;//��ǰ�������������
    temp_dat[11] = DataMode;//�û�����:����ģʽ
    // 
memcpy(&(temp_dat[12]),&(RTC_GetWorldSecond(Dtu3Detail.Property.timezone 
)),4);//�û�����:΢��ͬ��ʱ��
    temp_dat[12] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >> 
24;
    temp_dat[13] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >> 
16;
    temp_dat[14] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >> 
8;
    temp_dat[15] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone);
    //RTC_GetWorldSecond(Dtu3Detail.Property.timezone);
    temp_dat[16] = Gap;//�û�����:�����ϴ����������
    temp_dat[17] = Gap >> 8;
    memset(&(temp_dat[18]), 0, 2); //�û�����:���������յ��ĸ澯���
    memcpy((&temp_dat[20]), Password, 4); //�û�����:��������

    for(i = 10; i < 24; i++)
    {
        if((i - 10) % 2 == 1)
        {
            TempCrc = (temp_dat[i - 1] << 8) | (temp_dat[i]);
            DatCrc =  CalcCRC16t(TempCrc, DatCrc);
        }
    }

    temp_dat[24] = DatCrc >> 8;
    temp_dat[25] = DatCrc;
    temp_dat[26] = Get_crc_xor(temp_dat, 26);
    i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 27); 
//�����滻
    Uart_SendBuffer[(i + 1)] = ETX; //β
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}
```

[Lukas P. (lumapu)]

Holger S. schrieb:
> Ab 6 Inverter startet der Wemos nicht mehr durch.
> In der Console meckert er:
>
> Settings not valid, erasing ...
>
> Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?

Habe den Fehler soeben gefunden und gefixt.
Für die es interessiert: Wenn man in Macros addiert und subtrahiert muss 
man sich klar machen, dass alles expandiert wird. Gewollt war z.B. 
(2+2+4+5)-(2+4) es wurde aber 2+2+4+5-2+4 berechnet.
Es waren einfach zwei Klammern um `ADDR_NEXT` und `ADDR_START_SETTINGS` 
nötig, da sonst die Länge des Blocks falsch berechnet wird. Mal wieder 
ein Wunder, dass es überhaupt bisher funktioniert hat.

Hier die betroffene Zeile (existiert ähnlich auch nochmal in 
main.cpp:130)
https://github.com/grindylow/ahoy/blob/0347a3df44d77952524666794c888e6ef4693e45/tools/esp8266/app.cpp#L855

[isnoAhoy (Gast)]

According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:

```
#define DEVCONTROL_ALL         0x51
#define ANSWER_DEVCONTROL_ALL     (DEVCONTROL_ALL|0X80)
```

Hence the `UsartNrf3_Send_PackDevControl` method above is actually very 
much the same as the `CONTROL_LOCK_MI__LIMIT_POWER_ONOFF` for the legacy 
Gen 1 or 2 MI-inverters. The answer will be starting with Command `0xC1` 
or `ANSWER_DEVCONTROL_ALL`. This can be used to set various settings in 
HM-inverters e.g. the "sinus" wave `pWaveData = mymalloc(1200 * 
sizeof(uint8_t));` being recorded.

The main routine is in `UsartNrf3_Send_NetCmdToNrfCmd` where all the 
commands and subcommands are defined:

```
/***********************************************
** Function name: ��������ת��Ϊ����Э��nrfָ��
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
//  Type_ReactivePowerContr = 12,
//  Type_PFSet = 13,
//  Type_CleanState_LockAndAlarm = 20,
void UsartNrf3_Send_NetCmdToNrfCmd(void)
{
    if((CurNetCmd >= NET_TURN_ON) && (CurNetCmd <= NET_RESTART))
    {
        switch(CurNetCmd)
        {
            case NET_INVERTER_HW_INFOR:
            case NET_TERMINAL_INFOR:
                SubCmd = InverterDevInform_All;
                MainCmd = REQ_ARW_DAT_ALL;
                break;

            case NET_TURN_ON:
                SubCmd = Type_TurnOn;//����
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_TURN_OFF:
                SubCmd = Type_TurnOff;//�ػ�
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_LIMIT_POEWR:
                SubCmd = Type_ActivePowerContr;//���ƹ���
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_DOWNLOAD_PRO:
                MainCmd = DOWN_PRO;
                SubCmd = Type_Init;
                break;

            case NET_DOWNLOAD_DAT://���������ļ�
                MainCmd = DOWN_DAT;
                SubCmd = Type_Init;
                break;

            case NET_RESTART: //���س���/��λ
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                SubCmd = Type_Restart;
                break;

            case  NET_UNLOCK:
                SubCmd = Type_Unlock;
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_LOCK:
                SubCmd = Type_Lock;
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            default:
                break;
        }
    }
    else if(CurNetCmd == NET_INIT)
    {
        SubCmd = RealTimeRunData_Reality;
        MainCmd = REQ_ARW_DAT_ALL;
    }
    else if(CurNetCmd == NET_ALARM_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = AlarmData;
    }
    else if(CurNetCmd == NET_RECORD_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = RecordData;
    }
}
```

where the Sub Commands are of `DevControlType`

```
typedef enum
{
    Type_TurnOn = 0, // 0x00
    Type_TurnOff = 1, // 0x01
    Type_Restart = 2, // 0x02
    Type_Lock = 3, // 0x03
    Type_Unlock = 4, // 0x04
    Type_ActivePowerContr = 11, // 0x0B
    Type_ReactivePowerContr = 12, // 0x0C
    Type_PFSet = 13, // 0x0D
    Type_CleanState_LockAndAlarm = 20, // 0x14
    Type_Init = 0xff, // 0xFF
} DevControlType;
```

The AlarmDataType can store up to 50 Alerts as far as I could tell from 
the `UsartNrf3_Process_DevInform_Alarm` method.

BTW: The most recent version of the Gen3 protocol can be found in 
hoymiles-DTU-PRO-GPRS/User/NRF/usart_nrf3.c accompanied by the 
NetProtocol.c and AntiBackflow.c/.h
This implementation is more detailed than the ones under the 0.0.2 and 
0.0.1-20191115 Release directories.

Find attached the latest Test Report that came with the gitee repo. It 
has the following hint on this code line in NetProtocol.c:

> Enter the super password 10165082, you can change the password
```
            else if(Password_old == 10165082)
```

[isnoAhoy (Gast)]

Hallo Lukas,

> Settings not valid, erasing ...
gratuliere ein weiteres Problem behoben!

Da muß man auch erstmal drauf kommen in Zeile 130 und 855 noch 
zusätzliche Klammern zu setzen. Man könnte auch die Summen-Ausdrücke in 
den #Defines bereits in Klammern setzen, dann kann man sich auch in 
Zukunft nicht mehr verrechnen =^}

[Herbert K. (avr-herbi)]

Guten Morgen !
Wollte einfach nur mal ein Danke an die Nachtaktiven da lassen !

[Mel Yoshi (Gast)]

Grüezi mitenand,

es gibt anscheinend noch eine etwas neuere Version von usart_nrf3.c 
(hoymiles-DTU-PRO-APP/User/NRF/usart_nrf3.c) in folgendem repository:

https://gitee.com/iotloves/hoymiles-DTU-PRO.git

[Daniel R. (daniel92)]

Moin zusammen,

bin aktuell noch Unterwegs seit einer Woche. Melde mich wenn ich wieder 
Zuhause bin.

PS: Cool wie Ihr es bisher geschaft habt.

Beste Grüße Daniel :)

[Daniel M. (daniel_m821)]

Mel Yoshi schrieb:
> Grüezi mitenand,
>
> es gibt anscheinend noch eine etwas neuere Version von usart_nrf3.c
> (hoymiles-DTU-PRO-APP/User/NRF/usart_nrf3.c) in folgendem repository:
>
> https://gitee.com/iotloves/hoymiles-DTU-PRO.git

Moin,
wenn ich dort schauen will, bekomme ich die Meldung, dass das Repo für 
unregistrierte Benutzer gesperrt ist.
War das schon länger so oder ist das frisch?

lg :)

[Mel Yoshi (Gast)]

Grüezi Daniel M.,

versuch mal:
git clone https://gitee.com/iotloves/hoymiles-DTU-PRO.git

[Martin P. (mpolak77)]

Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy 
Version aufgegeben, weil dort das multiple messages handling schon 
funktioniert ... und habe dort das von mir benötigte json format für 
matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR 
damit erstellen).

Was mir aber auffällt ist, dass die Werte alle immer wieder Ausreißer (0 
oder mehrere zehntausend) haben ... ich habe versucht das im Code 
abzufangen und nur "gültige" Werte zu publishen, aber das funktioniert 
nur mäßig gut, weil es immer wieder unterschiedliche Werte betrifft.

Ich hatte eigentlich gemeint, dass der CRC das verhindern sollte?
Kann es sein, dass es ein Problem unterschiedlicher threads bzw Kontexte 
ist (also dass ein RX IRQ schon Daten überschreibt, während der MQTT 
Teil noch am versenden ist?

[Ziyat T. (toe_c)]

Mel Yoshi schrieb:
> Grüezi Daniel M.,
>
> versuch mal:
> git clone https://gitee.com/iotloves/hoymiles-DTU-PRO.git

Grüezi wohl Mel Yoshi
Bei mir gehts auch nicht, kannst du das neue usart_nrf3.c hier anhaengen 
bitte? Danke

[Lukas P. (lumapu)]

Nein, der ESP8266 hat nur einen Core und der IRQ setzt nur ein boolean. 
Daher ist hier eine Nebenläufigkeit ausgeschlossen. Zudem wird die 
Payload in einen extra Datenbereich kopiert und erst dann gepublished.

Bei mir läuft die Kommunikation schon immer ohne Ausreißer, die einzigen 
kommen von Wetter, zB. bei gemischter Bewölkung.

Welchen WR hast du? Der einzige, der hier Probleme machen könnte wäre 
der HM600

[Martin P. (mpolak77)]

Lukas P. schrieb:
> Welchen WR hast du? Der einzige, der hier Probleme machen könnte wäre
> der HM600

ich verwende einen HM-700 und einen HM-350 .... ich versuche mal genauer 
mitzuloggen, was da so vorsich geht. Aufgefallen ist es mir ja nur 
meinen Plots im IOBroker

[Lukas P. (lumapu)]

Dann schau doch Mal in deiner History in ioBroker ob da tatsächlich 
falsche Werte drin stehen, oder ob evtl zu selten ein Wert abgelegt 
wird.

Der HM-700 wäre auch betroffen, allerdings kann ich mir das nicht 
vorstellen.

[Holger S. (skusi)]

Hallo,
ich wollte gerade die 0.4.19 ausprobieren.
Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen, 
Bootloop, Console:

[13:57:41]I: connect to network 'Flackerlighter' ...
[13:57:43]...........
[13:57:53]
[13:57:53] ets Jan  8 2013,rst cause:4, boot mode:(3,6)
[13:57:53]
[13:57:53]wdt reset
[13:57:53]load 0x4010f000, len 3460, room 16
[13:57:53]tail 4
[13:57:53]chksum 0xcc
[13:57:53]load 0x3fff20b8, len 40, room 4
[13:57:53]tail 4
[13:57:53]chksum 0xc9
[13:57:53]csum 0xc9
[13:57:53]v0005af00
[13:57:53]~ld

Jemand einen Tipp ???

[Wo (Gast)]

Liebe Leute, ich habe seit einer Weile den HM700 und bin auf diese 
Diskussion gestoßen. Großartige Arbeit kann ich nur sagen! Ich habe 
nicht die nötige Expertise um hier mitreden zu können, möchte aber 
zumindest mein Feedback geben. Mit diesem Setup hatte ich sofort Erfolg:

.) "DollaTek NRF24L01 + PA + LNA mit Antenne"

.) Raspberry Pi 3B v1.2 (kein Plus)

.) Pi OS 32bit (vom 4.4.2022) mit Raspberry Imager aufgesetzt

.) Build/install RF24 und Anschlußbelegung Raspberry von hier:
https://tutorials-raspberrypi.de/funkkommunikation-zwischen-raspberry-pis-und-arduinos-2-4-ghz/ 
Allerdings mit diesen Paketen für Python3:
  sudo apt-get install python3-dev libboost-python-dev
  sudo apt-get install python3-setuptools
(für Python3 muss man noch die richtige boostlib verlinken, bei mir war 
es:
sudo ln -s /usr/lib/arm-linux-gnueabihf/libboost_python39.so.1.74.0 
/usr/lib/arm-linux-gnueabihf/libboost_python3.so )

.) Python-Software von hier: https://github.com/grindylow/ahoy

.) Im Verzeichnis  ahoy-main/tools/rpi  das ahoy.yml.example als 
ahoy.yml kopiert, mqtt disabled auf true gestellt, Seriennummer dort auf 
mein Gerät angepasst

.) Start mit: sudo python3 -um hoymiles --log-transactions --verbose 
--config ahoy.yml

Der Mikroinverter hat sofort geantwortet, die Leistungsangabe hat mit 
dem angeschlossenen Powermeter auch zusammengepasst - welches ich nun 
nicht mehr wirklich brauche.... Einfach super!

Danke schön für all die Mühen und die tolle Software!

[Günter H. (gnter_h534)]

Holger S. schrieb:
> ich wollte gerade die 0.4.19 ausprobieren.
> Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen,
> Bootloop, Console:

Ich habe bei meinem Wemos D1 mini mit 0.4.19 einen "Factory Reset" 
gemacht, meldet sich als AP unter 192.168.1.1, beim ersten Mal bewusst 
falsches Passwort für mein WLAN eingegeben, AP bleibt aktiv, mit 
richtigem Passwort Verbindung zum WLAN (s. angehängte Log-Datei).

Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass 
neue Netzwerkgeräte zugelassen werden?

[Mel Yoshi (Gast)]

Grüezi Ziyat T.,

ich bin mir nicht sicher ob es eine gute Idee wäre, die Datei hier 
einfach anzuhängen (Thema Copyright). Außerdem sind die einzelnen 
Revisionen möglicherweise auch nicht ganz uninteressant.

[Mel Yoshi (Gast)]

Vielleicht geht bei euch dieses Repository (mit gleicher Revision)?:

git clone https://gitee.com/andycao1860/hoymiles-DTU-PRO.git

[Herbert K. (avr-herbi)]

keine Probleme beim Download  :-)
allerdings hatte ich mich angemeldet beim 1. gitee Link
Datum der Dateien in obigem (also 3. Link) ist 13.07.2020 09:38
Ist der gleiche Zeitstempel wie beim 2. Link so wie ich das sehe.

[Holger S. (skusi)]

Günter H. schrieb:
> Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass
> neue Netzwerkgeräte zugelassen werden?

Ja, ist er. Mit den anderen Revisionen hat es ja funktioniert.

[Damian B. (damian_b)]

Hilfe
Meine DTU-Konfiguration auf ESP funktioniert nach der Programmierung 
maximal 10 Minuten und reagiert nicht auf Ping, sie kehrt nach einiger 
Zeit zurück und dies ist kein Problem für mein Netzwerk.

Ist MQTT für den ordnungsgemäßen Betrieb erforderlich?
ist eine spezielle Konfiguration erforderlich?

Momentan habe ich die Version 4.19 und nach dem Einrichten des Setups 
und der Eingabe von Visualisiert stirbt es ...

[isnoAhoy (Gast)]

Hallo Holger S.,
er kann Deinen Router nicht erreichen, deshalb (oder trotzdem) macht er 
den Access Point auf. Das hat er auch früher schon so gemacht. Nach 60 
Sekudnen sollte er eigentlich nochmal den Router versuchen.
Dabei scheint er sich aber irgendwie zu verrechnen, er kommt nämlich von 
42 Sekunden wieder auf 60 Sekunden ohne die WiFi Verbindung zu 
probieren!

I: connect to network 'HWW-WLAN-2-5G1581' ...
...............................
........................................................................ 
............................
I:
---------
AP MODE
SSID: AHOY-DTU
PWD: esp_8266
Active for: 60 seconds
---------

I: AP will be closed in 42 seconds
I: 1 clients connected, resetting AP timeout
I: AP will be closed in 60 seconds
I: 1 clients connected, resetting AP timeout
I: AP will be closed in 60 seconds
I: Serial debug is I: off

[isnoAhoy (Gast)]

Hallo Daniel M & Ziyat T.,

> Moin,
> wenn ich dort schauen will, bekomme ich die Meldung, dass das Repo für
> unregistrierte Benutzer gesperrt ist.
> War das schon länger so oder ist das frisch?

Ihr müsst Euch zwingend einen Account bei gitee.com erstellen, das war 
auch schon beim ersten Repolink dorthin so. Sonst kann man auf gitee.com 
m.E. nichts runterladen.

@Mel Yoshi, wie findest Du denn die anderen Repos von Hoymiles. Bei mir 
ergibt die Suche z.B. nach "usart_nrf3.c" auf gitee.com keinen einzigen 
Treffer ?

[Stefan T. (isnoahoy)]

Herbert K. schrieb:
> keine Probleme beim Download  :-)
> allerdings hatte ich mich angemeldet beim 1. gitee Link
> Datum der Dateien in obigem (also 3. Link) ist 13.07.2020 09:38
> Ist der gleiche Zeitstempel wie beim 2. Link so wie ich das sehe.

Habe es mal ausgepackt und verglichen mit diff/meld und kann auch keine 
Unterschiede feststellen.
Es gibt in 
hoymiles-DTU-PRO-master-iotloves/hoymiles-DTU-PRO-APP/User/NRF/
neben den bekannten usart_nrf3.c/.h auch eine usart_nrfConfig.h und in 
der usart_nrf3.c stehen einige Kommentare:

//dong 2020-0515
//dong 2020-06-17

Ich habe noch nicht ganz verstanden was der Unterschied zwischen 
hoymiles-DTU-PRO-APP und hoymiles-DTU-PRO-GPRS ist. Mal sehen ob das die 
ModBus RS485 Anbindung oder etwas anderes ist ?

[Stefan T. (isnoahoy)]

@Ziyat T. & Daniel M.,

es gibt in dem neuen gitee Repo(s) (iotloves === andycao1860) zwei neue 
Dateien namens SunSpec.c/.h die einiges an Implementierung zu MI-XXX 
Wechselrichtern enthalten.

[Mel Yoshi (Gast)]

Grüezi mitenand,

"hoymiles-DTU-PRO-GPRS" wurde in Commit bfb4da7 einfach in 
"hoymiles-DTU-PRO-APP" umbenannt. Das Ganze ist aber etwas neuer und 
könnte deshalb vielleicht mehr Infos zur HM-Serie enthalten. Deshalb 
meinte ich, dass es vielleicht interessant wäre auch die Commit-History 
mal anzuschauen (also am besten nicht nur das Archiv von gitee.com 
herunterladen sondern mit das gesamte Repository mit "git clone" 
klonen). Die Repositories iotloves und andycao1860 haben den selben 
Stand.

@isnoAhoy: Ich habe einfach mit Google gesucht:
https://www.google.de/search?q=site:gitee.com+hoymiles

[Holger S. (skusi)]

Günter H. schrieb:
> Holger S. schrieb:
>> ich wollte gerade die 0.4.19 ausprobieren.
>> Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen,
>> Bootloop, Console:
>
> Ich habe bei meinem Wemos D1 mini mit 0.4.19 einen "Factory Reset"
> gemacht, meldet sich als AP unter 192.168.1.1, beim ersten Mal bewusst
> falsches Passwort für mein WLAN eingegeben, AP bleibt aktiv, mit
> richtigem Passwort Verbindung zum WLAN (s. angehängte Log-Datei).
>
> Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass
> neue Netzwerkgeräte zugelassen werden?

Also ich hab es heute nochmal in Ruhe von vorne angefangen:
Ich glaube ich habe bei meinen gestrigen Versuchen falsche Pins in 
Pinout angegeben. Statt CS -> D8 hab ich wohl GPIO8 ausgewählt. Kann das 
sein das es dann in einen Bootloop geht ?
Dann hängt er auch in dieser Schleife, versucht immer mein WLan zu 
erreichen, schafft aber kein connect, öffnet aber auch keinen AP. Dann 
bleibt nur noch neu flashen !?

Nun funktioniert die 0.4.19 aber endlich super !
Ich habe zur Zeit 3 Inverter HM-300 dran und trotz Testaufbau und 
Blechdach und Amplifier Power Level auf Min recht gute Statistic Werte:

Uptime: 0 Tage, 00:10:01

Time: 2022-06-18 11:10:36

Statistics:

Receive success: 120
Receive fail: 3
Frames received: 387
Send Cnt: 169

Inverter 'West' is available and is producing
Inverter 'Sued_1' is available and is producing
Inverter 'Sued_2' is available and is producing
MQTT: connected

Mit der anderen version hatte ich bedeutend mehr fails.

Klasse Arbeit. Ich bin begeistert.
Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine 
Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die 
auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das 
Endprodukt soll dann eine kleine Box werden die man per Netzstecker 
direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser 
ganzen USB Netzteile.

Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen 
lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...

[Maik R. (bastelbarney)]

Heinz R. schrieb:
> IsnoAhoy schrieb:
>> 2. Grid Power Profile
>
> Damit ist wohl die Einstellung des CosPhi gemeint

Bisschen spät, aber da mir gestern das entspr. PDF in die Finger fiel 
... ich denke, der CosPhi wird in meiner Branche auf Englisch 
üblicherweise als "Power Factor" bezeichnet.
"Grid Power Profile" könnte sich daher mMn eher auf "Grid Type" aus dem 
Handbuch

https://www.hoymiles.com/wp-content/uploads/2021/11/Technical-Note_Hoymiles-Export-Management_Global_EN_V1.1.pdf

Seiten 3 und 4 beziehen. Lässt sich aber leider nicht durch

https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

untermauern. Aber auch nicht widerlegen ;-)

[MaXx (Gast)]

Stefan T. schrieb:
> Ich habe noch nicht ganz verstanden was der Unterschied zwischen
> hoymiles-DTU-PRO-APP und hoymiles-DTU-PRO-GPRS ist. Mal sehen ob das die
> ModBus RS485 Anbindung oder etwas anderes ist ?

Den DTU-Pro von Hoymiles gibt es in einer WLAN- und einer GPRS-Version:
https://www.alpha-solar.info/images/datenbl%C3%A4tter/Hoymiles/User-Manual_DTU-Pro-DE_V202103.pdf 
(Seite 5)

Grüazi, MaXx

[Günter H. (gnter_h534)]

Holger S. schrieb:
> Nun funktioniert die 0.4.19 aber endlich super !

Das freut mich zu hören.

> Das
> Endprodukt soll dann eine kleine Box werden die man per Netzstecker
> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser
> ganzen USB Netzteile.

Das halte ich für eine gute Idee. Ich bin auf das Ergebnis gespannt.

[Daniel M. (daniel_m821)]

Ich habe jetzt etwas rumgebaut und komme einfach nicht weiter.

Die Requests werden korrekt abgesetzt, allerdings renne ich entweder in 
den Fehler "Frame 1 missing" oder "last frame missing"

12:01:10.197 -> I: Inverter #0 I: no Payload received! (retransmits: 5)
12:01:10.197 -> I: Requesting Inverter SN 114163500316
12:01:10.197 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 
12:01:10.251 -> E: while retrieving data: last frame missing: Request Retransmit
12:01:10.251 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 
12:01:10.298 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.551 -> E: while retrieving data: last frame missing: Request Retransmit
12:01:10.551 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 
12:01:10.651 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.651 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.698 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.898 -> E: while retrieving data: last frame missing: Request Retransmit

Die app.cpp ab Zeile 224 original:

                if(0 != len) {
                    Inverter<> *iv = mSys->findInverter(&p->packet[1]);
                    if(NULL != iv) {
                        uint8_t *pid = &p->packet[9];
                        if((*pid & 0x7F) < 5) {
                            memcpy(mPayload[iv->id].data[(*pid & 0x7F) - 1], &p->packet[10], len-11);
                            mPayload[iv->id].len[(*pid & 0x7F) - 1] = len-11;
                        }

                        if((*pid & 0x80) == 0x80) {
                            if((*pid & 0x7f) > mPayload[iv->id].maxPackId) {
                                mPayload[iv->id].maxPackId = (*pid & 0x7f);
                                if(*pid > 0x81)
                                    mLastPacketId = *pid;
                            }
                        }

mit meiner Version:

                if(0 != len) {
                    Inverter<> *iv = mSys->findInverter(&p->packet[0]);
                    if(NULL != iv) {
                        uint8_t *pid = &p->packet[0]; //9
                        if((*pid & 0x88) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x88) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x88) - 1] = len-12; // (*pid & 0x7F)
                        }
                        if((*pid & 0x89) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x89) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x89) - 1] = len-12; // (*pid & 0x7F)
                        }
                        if((*pid & 0x91) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x91) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x91) - 1] = len-12; // (*pid & 0x7F)
                        }
                        if((*pid & 0x92) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x92) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x92) - 1] = len-12; // (*pid & 0x7F)
                        }

                        //if((*pid & 0x80) == 0x80) {
                        if( ((*pid & 0x88) == 0x88) || ((*pid & 0x89) == 0x89) || ((*pid & 0x91) == 0x91) || ((*pid & 0x92) == 0x92) ) {
                            if((*pid & 0x88) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                            }
                            if((*pid & 0x89) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                            }
                            if((*pid & 0x91) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                            }
                            if((*pid & 0x92) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                                                   
                                if(*pid > 0x92) // (*pid & 0x81)
                                    mLastPacketId = *pid;
                            }
                        }

Bei len-11 ist Frame 1 missing, len-12 bringt last frame missing.

Den Reqest habe ich so gestaltet:

                    if(mSerialDebug)
                        DPRINTLN(DBG_INFO, F("Requesting Inverter SN ") + String(iv->serial.u64, HEX));
                    //mSys->Radio.sendTimePacket(iv->radioId.u64, mPayload[iv->id].ts);
                    // for MI-Series or TSUN
                    static uint8_t tel = 0;
                    if (tel = 2)
                      tel = 0;
                                        
                    if (tel == 0) {
                      //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x09, mLastPacketId, true);
                      mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x09, 0x00, true);
                      }
                      else if (tel == 1) {
                        //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, mLastPacketId, true);
                        mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, 0x00, true);
                      }
                      else if (tel == 2) {
                        //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, mLastPacketId, true);
                        mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x10, 0x00, true);
                      }     
                      tel++;                    
                    mRxTicker = 0;

Direkt danach folgt der Fehler:

else if(mSerialDebug)
                DPRINTLN(DBG_WARN, F("time not set, can't request inverter!"));
            yield();

für die Position, wo ich das geändert habe.

Das repo aus China konnte ich clonen und wühle mich da gerade durch. von 
dort habe ich auch den CMD 0x10, für Debug- und Verständniszwecke mal 
mit eingebaut. Gesehen habe ich die Antwort darauf auch schon, nur noch 
keine Idee, was ich mit den Werten am Ende mache (aktuell auch 
irrelevant).

Was die Payload-länge, maxPackID usw. angeht, habe ich keine Ahnung, was 
ich da tue und wie es richtig geht. Habe einiges durchprobiert, mangels 
Verständnis und Wissen scheitere ich an diesem Punkt.

&p->packet[0] findet auf jeden Fall die Antwort-ID, &p->packet[9] zeigt 
auf den Punkt, ab wann Nutzdaten kommen, die Länge der Nutzdaten ist 12 
(6 Werte).
Habe ich einen Denkfehler bei "len-12" das hier nicht die Gesamtlänge 
gefragt ist sondern eine Position in der Payload verschoben wird?

Ich würde den Knoten im Kopf gerne lösen.

edit: typo

[Thomas B. (tbnobody)]

Martin P. schrieb:
> Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy
> Version aufgegeben, weil dort das multiple messages handling schon
> funktioniert ... und habe dort das von mir benötigte json format für
> matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR
> damit erstellen).

Hallo Martin,
nur so aus eigenem Interesse, was ist denn matt?

[Ziyat T. (toe_c)]

@isnoAhoy
Also ich bin schon alt aber...;-)
Sicher habe einen gitee Account! Ich hab ja schon mal das 1. Repo 
runtergeladen, seit dem geht es nicht mehr und ich wollte mich nicht 
wieder neu registrieren.


@Mel Yoshi
Nach dem hier die Uebersetzungen v. div. files schon veröffentlicht 
wurden, ist eine Diskussion über das Thema Copyright für mich nicht mehr 
aktuell, aber jeder soll so handhaben, wie es ihm richtig scheint...

@Stefan T.
Das ist sicher die Implementierung das Sunspec Protokolls des MI-WR, das 
kann man auch im Modbus-HB lesen.

@Maik R., @isnoAhoy
Das Grid Profile enthaltet mehr Daten als nur den Power Factor, im 
Anhang ist mein Grid Profile für meinen Standort.


Und weitere Nachrichten aus MI-1500 Front:

Nach dem ich mit dem MI-1500 erfolglos war, habe noch einen Sniffer auf 
arduino/nrf24 basis neben dem esp8266/nrf24 (aeltere Vers.) gestellt, 
und sah in den Sniffer-Daten die Antworten vom WR ab und zu kommen, 
immer auf die Anfragen auf CH 75!!

Die esp8266/nrf24-SW erkennt die Antworten nicht, weil das CRC nicht 
stimmt, guckst du:

ab hier geht es nicht mehr weiter:
  if(mHoymiles->checkCrc(p->packet, &len, &rptCnt))

Ich habe vor dem if diese Zeile eingefügt:
  mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
So sehe ich ab und zu die Antworten auch im esp8266.

hmmmmm...???

[Martin P. (mpolak77)]

Thomas B. schrieb:
> Martin P. schrieb:
>
>> Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy
>> Version aufgegeben, weil dort das multiple messages handling schon
>> funktioniert ... und habe dort das von mir benötigte json format für
>> matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR
>> damit erstellen).
>
> Hallo Martin,
> nur so aus eigenem Interesse, was ist denn matt?

Das ist Mqtt mit Autokorrektur ;-)

[Peter L. (leliep)]

Holger S. schrieb:
….
>
> Klasse Arbeit. Ich bin begeistert.
> Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine
> Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die
> auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das
> Endprodukt soll dann eine kleine Box werden die man per Netzstecker
> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser
> ganzen USB Netzteile.
>
> Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen
> lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...

Gute Idee, ich hab da mal was probiert, siehe Fotos.

[Carsten B. (carstenb)]

Carsten B. schrieb:

> Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem
> ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g.
> Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht
> kompatibel sind.
>
> Hat jemand eine lauffähige Version für ESP32?

Das Thema ESP32 habe ich erst mal aufgegeben und benutze einen ESP8266. 
Die Ahoy-Software läuft darauf einwandfrei, allerdings musste ich in 
"defines.h" folgendes anpassen:

#define PWD_LEN             64

da mein WLAN-Schlüssel die volle Länge nutzt.

Mit der Änderung funktioniert es bei mir.

LG

Carsten

[Heinz R. (heijz)]

sorry wenn OT - gibt es in Euren chinesischen Quellen auch was für die 
HMS-Serie von Hoymiles?
Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke 
mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem 
HM-Protokoll ist?

Viele Grüße

[Daniel M. (daniel_m821)]

Heinz R. schrieb:
> sorry wenn OT - gibt es in Euren chinesischen Quellen auch was für die
> HMS-Serie von Hoymiles?
> Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke
> mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem
> HM-Protokoll ist?
>
> Viele Grüße

Hallo Heinz,

bei der Durchsicht der NRF-Dinge ist mir der HMS nicht begegnet. Die 
Daten sind von 2020, also nicht super aktuell.

Kannst du was genaueres sagen, welche DTU/DTU-Pro dafür passt?

Edit:
Was mir noch eingefallen ist: welche Seriennummer hat dein HMS und 
wieviele PV-Anschlüsse/MPPT Tracker?

[oxylog (Gast)]

Daniel M. schrieb:
> welche DTU/DTU-Pro dafür passt?


Gestern hatte ich das aus interesse nachgeschaut:
https://www.shinetech-power.de/wechselrichter/hoymiles/
"Die Überwachung für HMS Serie ist der DTU Lite S / Pro S, die für 
HM-Serie gebaute DTU Lite/Wlite/Pro funktioniert nicht mit HMS."
Hier gibt es die Anleitung dazu
https://manuals.plus/m/1ecf6e51138bca7f81443c62f0c1d440fcbbbf26c16146d949870e807c943955_optim.pdf

Hier ist das passende Datenblatt zu finden
https://www.mini-nrg.de/download

Heinz R. schrieb:
> Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke
> mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem
> HM-Protokoll ist?

In den Spezifikationen ist "Sub-1G" unter Kommunikation angegeben.

Inn der Bedienungsanleitung ist folgendes zu finden:
https://www.hoymiles.com/wp-content/uploads/2021/11/User-manual_HMS-160018002000-4T-NA_EN_V202201.pdf
"Range of Sub-1GHz wireless: Unlike Wi-Fi or Zigbee which both operate 
on the 2.4 GHz band, Sub-1GHz op-
erates on the 868 MHz or the 915 MHz band. Generally speaking, Sub-1GHz 
wireless transmission covers 1.5
to 2 times longer distance than the 2.4GHz spectrum"

Hierzu ist eventuell diese Dokumentation über das Sendemodul (?) 
interessant:
https://manuals.plus/m/a345e161e8ceba2155593aaeefcb3e2f3de7dfe1e13fe1e4dc9d421e50725131_optim.pdf

Aus einer Hoymiles-Präsentation habe ich noch ein Slide angehängt über 
HMS/HMT (Über das Protokoll heißt es hier nur "Proprietary"). Vielleicht 
hilft es euch etwas.

[Carsten B. (carstenb)]

Holger S. schrieb:
>
> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen
> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem
> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate
> ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten
> und den Namen ändern.
> Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.

Hallo Holger,

ich betreibe es auch auf dem ESP8266 und übermittle via MQTT an mein 
FHEM seit gestern. Hast du bezüglich der wechselnden ID schon eine 
Lösung gefunden?

Carsten

[Holger S. (skusi)]

Carsten B. schrieb:
> Holger S. schrieb:
>>
>> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen
>> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem
>> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate
>> ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten
>> und den Namen ändern.
>> Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.
>
> Hallo Holger,
>
> ich betreibe es auch auf dem ESP8266 und übermittle via MQTT an mein
> FHEM seit gestern. Hast du bezüglich der wechselnden ID schon eine
> Lösung gefunden?
>
> Carsten

Hallo Carsten,

wenn Du die aktuelle Version 0.4.19 verwendest ist die ID immer 
"AHOY_DTU"! Ich hatte das zwischenzeitlich auch schon geändert, aber nun 
wurde es wohl so eingepflegt.

Gruß Skusi

[Holger S. (skusi)]

Peter L. schrieb:
> Holger S. schrieb:
> ….
>>
>> Klasse Arbeit. Ich bin begeistert.
>> Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine
>> Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die
>> auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das
>> Endprodukt soll dann eine kleine Box werden die man per Netzstecker
>> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser
>> ganzen USB Netzteile.
>>
>> Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen
>> lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...
>
> Gute Idee, ich hab da mal was probiert, siehe Fotos.

WOW !!! So kompakt hatte ich eigentlich nicht vor. Das Gehäuse ist 
sicherlich gedruckt !? Ich habe keinen 3D Drucker, deshalb wird meine 
Box nicht direkt der Netzstecker sein, sondern eher ein Kleingehäuse von 
Pollin. Die Platine Darin enthält dann ein Mini Netzteil vom Typ 
HLK-PM01 von HI-LINK. Die Spannungsversorgung wird dann über ein EURO 
Netzkabel erfolgen.

Deine Arbeit ist noch eine Stufe Kompakter, aber für mich zu aufwendig. 
Aber großen Respekt!!! Ich finde die Lösung sehr gut, kann ich nicht 
gegen anstinken...

[Carsten B. (carstenb)]

Hallo,

sehr cool und schön kompakt. Ich habe meine Aufbau grade in eine 
IP65-Verteilerdose eingebaut. Das habe ich bei ähnlichen Anwendungen 
schon öfter so gemacht. Ist kostengünstig und lässt sich ggf. auch 
draussen benutzen.

Carsten

[Carsten B. (carstenb)]

Hallo,

ich hatte grade auch schon gefunden, wo ich es ändern kann und läuft 
jetzt.

Natürlich sollte ich mal die aktuelle Version einsetzen, aber für heute 
ist erst mal Schluss mit basteln :-)

Carsten

[Günter H. (gnter_h534)]

Carsten B. schrieb:
> Ich habe meinen Aufbau grade in eine
> IP65-Verteilerdose eingebaut.

Ist da ein separater 3,3V-Spannungsregler zur Versorgung des 
nRF24L01-Moduls eingebaut?

Ich mache gerade Versuche damit - inzwischen schafft mein Aufbau häufig 
24 h und länger ohne reboot.

Was jetzt auffällt: Nach dieser Zeitspanne geht in meinem Fall die 
Uhrzeit der "DTU" ca. 8 min nach.

Es sieht für mich so aus, als würde beim Booten NTP abgerufen, danach 
aber nicht mehr?

(Leider habe ich vom Programmieren praktisch null Ahnung)

[Daniel M. (daniel_m821)]

oxylog schrieb:

> "Range of Sub-1GHz wireless: Unlike Wi-Fi or Zigbee which both operate
> on the 2.4 GHz band, Sub-1GHz op-
> erates on the 868 MHz or the 915 MHz band. Generally speaking, Sub-1GHz
> wireless transmission covers 1.5
> to 2 times longer distance than the 2.4GHz spectrum"

868 MHz dieses mal. Ich kann mir nicht vorstellen, dass es ein neues 
oder groß anderes Protokoll gibt.

Vielleicht aber erstmal die aktuellen Baustellen abarbeiten und MI- und 
HM-Serie auf 2,4GHz vollständig implementieren.

Interessant ist das aber auf jeden Fall mit der 1G Verbindung, wurde ja 
bereits vor einigen Tagen hier schonmal mit YT-Links gezeigt.

@Heinz R.
> Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke
> mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem
> HM-Protokoll ist?

Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen.
Hab bitte etwas Geduld :)

[Carsten B. (carstenb)]

Ja, ich habe das Spannungsreglermodul von AZ-delivery benutzt und 
zusätzlich zwei Elkos angeschlossen (5V und 3,3V). Damit läuft es auch 
bei PA_HIGH stabil.

https://www.az-delivery.de/products/adapter-fur-nrf24l01

Ich habe allerdings immer noch fehlerhafte Pakete, seit der Aufbau nah 
am WR ist (ca. 2-3m durch eine Holzbalkendecke) ist es aber besser.

Statistics:

Receive success: 807
Receive fail: 103
Send Cnt: 2861

[Peter L. (leliep)]

Holger S. schrieb:

> WOW !!! So kompakt hatte ich eigentlich nicht vor. Das Gehäuse ist
> sicherlich gedruckt !? Ich habe keinen 3D Drucker, deshalb wird meine
> Box nicht direkt der Netzstecker sein, sondern eher ein Kleingehäuse von
> Pollin. Die Platine Darin enthält dann ein Mini Netzteil vom Typ
> HLK-PM01 von HI-LINK. Die Spannungsversorgung wird dann über ein EURO
> Netzkabel erfolgen.
>
> Deine Arbeit ist noch eine Stufe Kompakter, aber für mich zu aufwendig.
> Aber großen Respekt!!! Ich finde die Lösung sehr gut, kann ich nicht
> gegen anstinken...

Danke, freut mich, wenn es Dir gefällt. Das Schöne an so einer Community 
ist, dass die Diskussion mit Anderen die eigene Kreativität beflügelt. 
Über eine solche Kompaktlösung hatte ich vor Deinem Beitrag noch nicht 
nachgedacht :-)

Für diese Variante habe ich folgende Komponenten verwendet:
1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von 
Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die 
freundlicherweise verschraubt und nicht genietet sind, leicht zu 
zerlegen und perfekt für den vorgesehenen Zweck geeignet.
2. ein dazu passend konstruiertes Gehäuse-Unterteil mit 
Verschraub-Möglichkeit für den obigen Schukostecker.
3. das Mini-Netzteil 5V, das Du auch verwendest.
4. eine passend konstruierte Trennplatte mit Bohrung zum Abtrennen des 
Netzspannungs-Bereichs vom Rest.
5. ein ESP8266 D1 von AZ-Delivery mit zwei Buchsenleisten.
6. eine passende (ESP8266-Format) Leerplatine von AZ-D.
7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne. Modul mit 
Fädeltechnik und Steckerleisten auf Leerplatine gelötet.
8. 10uF Elko an 3.3V Versorgung dazu, bisschen isolierte Alufolie um den 
Prozessorteil des NRF24L01+, unter Vermeidung von Kurzschlüssen das 
Ganze zum Sandwich zusammengesteckt.
9. passend zum Gehäuse konstruierter Deckel.

Teile 2,4 und 9 sind 3D-gedruckt (die waren ursprünglich für eine 
ESPEasy-basierte Lösung zur Temperaturmessung mit DS1820 entstanden).

Im Moment liegen die Platinen nur locker im dafür vorgesehenen 
Gehäusebereich, das könnte man noch durch Anpassung der inneren 
Formgebung verbessern.

:-)

[Heinz R. (heijz)]

Daniel M. schrieb:
> Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen.
> Hab bitte etwas Geduld :)

sorry, hatte es verwechselt - HM und MI-Serie sind ja 2,4 GHz

Wollte hier jetzt auch nicht noch groß ein Thema wegen HMS aufmachen - 
aber hätte ja sein können jemand hat in den diversen chinesischen Seiten 
was dazu gefunden

Viele Grüße

[Daniel M. (daniel_m821)]

Heinz R. schrieb:
> Daniel M. schrieb:
>> Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen.
>> Hab bitte etwas Geduld :)
>
> sorry, hatte es verwechselt - HM und MI-Serie sind ja 2,4 GHz
>
> Wollte hier jetzt auch nicht noch groß ein Thema wegen HMS aufmachen -
> aber hätte ja sein können jemand hat in den diversen chinesischen Seiten
> was dazu gefunden
>
> Viele Grüße

Den Fortschritt beobachten ist auf jeden Fall wichtig.
Meinen TSUN als MI-Verschnitt habe ich damals geholt weil ich dachte, 
dass er gut und auch kommunikativ ist.
Hätte ich da gewusst, dass es sich um einen MI-Klon handelt, wäre ich 
gleich auf die HM-Serie gegangen.
Schlecht ist er nicht, er fängt sehr früh schon an mit produzieren und 
hält lange durch, aber für mehr als mal schnell irgendwo 2 Module 
hinlegen würd ich ihn auch nicht weiter einsetzen.
Da ich jetzt schlauer bin, werd ich die nächsten 16 Module wohl mit der 
HM-Serie bestücken. Wenn HMS jetzt kommt, fallen die HM hoffentlich im 
Preis. Aktuell ist ja fast nichts lieferbar, das ändert sich hoffentlich 
auch noch.

[Wo (Gast)]

Liebe Leute, eine Kleinigkeit ist mir aufgefallen - kann jetzt doch noch 
einen unbedeutenden Beitrag leisten... :-)

In Zeile 471 der Datei: 
https://github.com/grindylow/ahoy/blob/main/tools/rpi/hoymiles/decoders/__init__.py 
(in "class Hm600Decode0B") sollte wohl das stehen: "return 
self.unpack('>H', 34)[0]/100" (statt "/10"), sonst passt der ausgegebene 
AC Strom nicht.
Für die 1-String Inverter (in "class Hm300Decode0B") ist der Code 
korrekt.

Danke nochmal, Wolfgang

[Claus T. (Gast)]

Hallo,
ich verfolge diesen Thread schon ein paar Tage, dauert ja bei so vielen 
Einträgen schon ne Weile, bis man alles gelesen hat :-) und muss sagen, 
super Arbeit in so kurzer Zeit.
Da ihr ja auch an der Einspeise-Leistungsregelung arbeitet, hab ich noch 
eine Idee zu einer einfachen Leistungsmessung.
Mit den neuen elektronischen Stromzählern kann man über Optokopler den 
Zählerstand und die aktuelle Leistung auslesen (Obis/SML-Schnittstelle). 
Die wird bei mir auch negativ angezeigt, wenn der WR Überschuss 
produziert.
Meine Idee war, eine Software zum auslesen für den ESP schreiben und die 
Daten per MQTT weiter geben, oder eure Schaltung noch mit einer 
Photodiode ergänzen und die Obis-SW gleich mit integrieren.
Und wie es im Internet so ist, war da schon jemand anderer auf die Idee 
gekommen, ESP mit Obis-SW gibts schon:

https://github.com/mruettgers/SMLReader

Nur mal so als günstige Anregung der Leistungsmessung, ist auch leicht 
im Schaltschrank zu installieren, ohne Elektriker, nur auf den Zähler 
mit Magnet oder Klebeband aufsetzen. Bilder und Schaltplan sind bei 
GitHub dabei.

Grüße
Claus T.

P.S. ich habe seit kurzem ein Balkonkraftwerk mit Wechselrichter 
TSOL-M800 von TSUN, würde mich also über die Unterstützung dieses WR 
freuen.

[Holger S. (skusi)]

Peter L. schrieb:
> Für diese Variante habe ich folgende Komponenten verwendet:
> 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von
> Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die
> freundlicherweise verschraubt und nicht genietet sind, leicht zu
> zerlegen und perfekt für den vorgesehenen Zweck geeignet.

Solche alten Gehäuse ausgeschlachteter Steckernetzteile hab ich auch 
noch zu Hauf rumligen. Aber je mehr ich damit hantiere fällt mir auf das 
ich es immer gehasst habe das man diese Dinger nie da reingesteckt 
bekommt wo man sie gerade heben möchte. In Mehrfachsteckdosen belegen 
sie meist 2 Plätze oder passen eben gar nicht mit den anderen 
Winkelsteckern zusammen, usw...
Außerdem denke ich ist man mit der WLan Antennen Ausrichtung des Wemos 
flexibler wenn man das Gehäuse mit einem 230V Netzkabel ausstattet.

Ich werde die Variante mit Standard Gehäuse weiter verfolgen.

> 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne.

Ich werde in das Gehäuse ein Nrf24l01+pa+lna Modul verbauen. Dann kann 
ich ein SMA  Verlängerungskabel verwenden um die Antenne flexibel, 
wahrscheinlich sogar Outdoor (weil Blechdach) zu positionieren.
Dann muß ich die Technik selber auch nicht wasserdicht ausführen und 
kann sie Indoor lassen, ist mir lieber.

> 8. 10uF Elko an 3.3V Versorgung dazu

Ist das zu empfehlen ? Arbeitet das dann stabiler ? Auch ein Elko an 5V 
?

Gruß Skusi

[Holger S. (skusi)]

Carsten B. schrieb:
> Ja, ich habe das Spannungsreglermodul von AZ-delivery benutzt und
> zusätzlich zwei Elkos angeschlossen (5V und 3,3V). Damit läuft es auch
> bei PA_HIGH stabil.

Meinst Du das der Spannungsregler auf dem Wemos minderwertiger ist und 
deshalb oft rebootet wird ? Oder sind es eher die Elkos die da abhilfe 
schaffen.

Mein Testaufbau rebootet auch öfters. 24 Std hab ich noch nicht 
geschafft.
Ich beobachte das auch schon mit Sorge und frage mich was man da 
Hardwareseitig machen kann. Ich dachte immer das es noch 
Kinderkrankheiten der Software sind.

Gruß Skusi

[Stefan T. (isnoahoy)]

oxylog schrieb:
> Hierzu ist eventuell diese Dokumentation über das Sendemodul (?)
> interessant:
> 
https://manuals.plus/m/a345e161e8ceba2155593aaeefcb3e2f3de7dfe1e13fe1e4dc9d421e50725131_optim.pdf

Interessant ist neben den Pin-Outs folgender Absatz aus der Anleitung:

3.6 Label and compliance information
An exterior label on OEM’s end product can use wording such as the 
following:
“Contains Transmitter Module FCC ID: 2ARNB-HMS101” or “Contains FCC ID:
2ARNB-HMS101”

Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das 
ist m.W. Giga Devices, China) und einen 300A E965 945 chip. Die chin. 
Chip(s)-Hersteller produzieren viele ST32, nRF24 o.a. Clones.
https://fccid.io/2ARNB-HMS101/Internal-Photos/Internal-Photos-5204735

Du kannst ja mal weiter oben nachschauen ob das die selbe FCC ID ist wie 
im bisherigen nRF24-basierten Modul ?

Das mit dem Sub-1G Funkmodul steht auch bei den aktuellen Hoymiles 
HM-600 Invertern im Data Sheet, da nimmt es der Hersteller wohl nicht 
ganz so genau mit dem Marketing der Sende-Frequenzen.
Es könnte aber auch ein LoRaWAN ähnliches Modul sein, zumindest die 
genutzten Frequenzen von 868 & 915 MHz sprächen dafür, wobei in US 
glaube ich 433 MHz genutzt werden.

[Stefan T. (isnoahoy)]

Hallo Daniel M.,

probier mal die Anfrage umgekehrt zu stellen, d.h. erst DTU dann WR 
Adresse:

12:01:10.197 -> I: Requesting Inverter SN 114163500316
12:01:10.251 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27
12:01:10.298 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE

Also

> Transmit 11 | 09 78 56 34 12 63 50 03 16 00 27

das sollte dann eigentlich die Antwort geben

> 89 63 50 03 16 78 56 34 12 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE

Hier noch ein paar Kommentare um den Code zu verdeutlichen

> Die app.cpp ab Zeile 224 original:
>

>                 if(0 != len) {
>                     Inverter<> *iv = mSys->findInverter(&p->packet[1]);
>                     if(NULL != iv) {
// paket ID in byte 10, d.h. packet[9]
>                         uint8_t *pid = &p->packet[9]; 
// die paket ID muß < 5 sein, wenn man 0x80 abzieht bzw. sich alle unteren Bits ansieht.
>                         if((*pid & 0x7F) < 5) { 
// kopiere das Ergebnis in die Payload .data[1..5] ab der 11. Stelle bis zum  Ende, das Ende ist die Länge des Paketes len-11 Bytes (= 10 Bytes davor plus 1 Byte CRC-8 ganz am Ende)
>                             memcpy(mPayload[iv->id].data[(*pid & 0x7F) - 
> 1], &p->packet[10], len-11); 
// Berechne die Länge der Payload des Paketes, analog zur Länge davor
>                             mPayload[iv->id].len[(*pid & 0x7F) - 1] = 
> len-11;
>                         }
> 
// Wenn die Paket ID das höchstwertige Bit 0x80 gesetzt hat bzw. > 0x80 ist == Letztes Paket oder Antwort auf ein Retransmit  
>                         if((*pid & 0x80) == 0x80) {
// wenn die Paket ID > die maxPackId ist.
>                             if((*pid & 0x7f) > 
> mPayload[iv->id].maxPackId) {
// setze die maxPackId gleich der aktuellen Paket ID
>                                 mPayload[iv->id].maxPackId = (*pid & 
> 0x7f);
// falls die Paket ID > 0x81 ist, also 0x82 ... 0x85
>                                 if(*pid > 0x81)
// setze die mLastPackId = der aktuellen paket ID
>                                     mLastPacketId = *pid;
>                             }
>                         }
>

> mit meiner Version:
>

>                 if(0 != len) {
>                     Inverter<> *iv = mSys->findInverter(&p->packet[0]);
>                     if(NULL != iv) {
>                         uint8_t *pid = &p->packet[0]; //9
>                         if(*pid == 0x88) { // A Event
>                             memcpy(mPayload[iv->id].data[2], &p->packet[9], len-12);
>                             mPayload[iv->id].len[2] = len-12; 
>                         }
>                         if(*pid == 0x89) { // A Data
>                             memcpy(mPayload[iv->id].data[0], &p->packet[9], len-12);
>                             mPayload[iv->id].len[0] = len-12;
>                         }
>                         if(*pid == 0x91) { // B Event (or Data ?)
>                             memcpy(mPayload[iv->id].data[1], &p->packet[9], len-12);
>                             mPayload[iv->id].len[1] = len-12;
>                         }
>                         if(*pid == 0x92) { // B Data (or Event ?)
>                             memcpy(mPayload[iv->id].data[3], &p->packet[9], len-12);
>                             mPayload[iv->id].len[3] = len-12;
>                         }
> 
Den Rest würde ich erstmal weglassen und sehen, daß er die o.a. 0x89 Antwort sauber dekodiert. Das sollte er in processPayload machen.
Dabei kannst Du m.E. den Punkt mit buildPayload überspringen, dabei werden alle Teil-Payloads der Pakete zusammen nochmal mit einer CRC-16 validiert.
Das gibt/gab es bei den MI-Wechselrichtern nicht, dort reicht die bereits in Zeile 216 überprüfte CRC-8 die immer am Ende jedes Pakets vorhanden ist.

>                         if( (*pid == 0x88) || (*pid == 0x89) || (*pid == 0x91) || (*pid == 0x92) ) {
>                             if((*pid == 0x89) && (mPayload[iv->id].maxPackId < 1)) {
>                                 mPayload[iv->id].maxPackId = 1;
>                             }
>                             if((*pid == 0x88) && (mPayload[iv->id].maxPackId < 3) { 
>                                 mPayload[iv->id].maxPackId = 3;
>                             }
>                             if((*pid == 0x91) && (mPayload[iv->id].maxPackId < 2) { 
>                                 mPayload[iv->id].maxPackId = 2;
>                             }
>                             if((*pid == 0x92) && (mPayload[iv->id].maxPackId < 4)) {
>                                 mPayload[iv->id].maxPackId = 4;
> 
>                                 if(*pid == 0x92)
>                                     mLastPacketId = *pid;
>                             }
>                         }
>

Ich bin mir nicht sicher in welcher Reihenfolge die einzelnen Anfragen 
0x09, 0x11, 0x08 / 0x12 denn gestellt werden bzw. reinkommen. Ich habe 
jetzt einfach mal eine hypothetische Reihenfolge angenommen und nehme 
an, daß auch tatsächlich alle view Pakete gesendet / empfangen werden. 
Sollte das nicht der Fall sein, muß man das eben entsprechend kürzen. 
Persönlich wäre für mich nach 0x89 (als Antwort auf 0x09) und 0x91/0x92 
(als Antwort auf 0x11) erst mal Schluss. D.h. eigentlich nur zwei 
Antwort-Pakete und dann die mLastPacketId setzen.

> dort habe ich auch den CMD 0x10, für Debug- und Verständniszwecke mal
> mit eingebaut. Gesehen habe ich die Antwort darauf auch schon, nur noch
> keine Idee, was ich mit den Werten am Ende mache (aktuell auch
> irrelevant).

Laut Command Summary ist 0x10 Collect grid-connected configuration file 
name and version information  die Antwort beginnt dann mit 0x90.

> Was die Payload-länge, maxPackID usw. angeht, habe ich keine Ahnung, was
> ich da tue und wie es richtig geht. Habe einiges durchprobiert, mangels
> Verständnis und Wissen scheitere ich an diesem Punkt.

In der app.h wird die folgende Struktur definiert, die pro 
Wechselrichter existiert:

typedef struct {
    uint8_t invId;
    uint32_t ts;
    uint8_t data[MAX_PAYLOAD_ENTRIES][MAX_RF_PAYLOAD_SIZE];
    uint8_t len[MAX_PAYLOAD_ENTRIES];
    bool complete;
    uint8_t maxPackId;
    uint8_t retransmits;
    bool requested;
} invPayload_t;

> &p->packet[0] findet auf jeden Fall die Antwort-ID, &p->packet[9] zeigt
> auf den Punkt, ab wann Nutzdaten kommen, die Länge der Nutzdaten ist 12
> (6 Werte).

Ich denke das ist richtig.

@Lukas, kannst Du das und die weiteren Annahmen / Fragen zu buildPayload 
/ processPayload eventuell noch bestätigen bzw. etwas erklären ?

> Habe ich einen Denkfehler bei "len-12" das hier nicht die Gesamtlänge
> gefragt ist sondern eine Position in der Payload verschoben wird?

len ist die Länge des gesamten Antwort Paketes vom nRF24, also len-10 
sollte m.E. bei Dir richtig sein (10 Bytes = 1 Byte Command + 4 Bytes 
Source Adr + 4 Bytes Destination Adr + 1 Byte CRC-8 am Ende)

89 >63 50 03 16< >78 56 34 12< >01 2B< >00 56< >09 5C< >13 85< >09 A5< >02 B8< >01 FF< DE
1 + 4          + 4         + 2   + 2   + 2   + 2   + 2   + 2   + 2   + 1
CMD >WR ADR    < >DTU ADR    < >299 W< > 86 ?< >2396?< >4997?< >2469?< >696?< >511?< CRC8

> Ich würde den Knoten im Kopf gerne lösen.

Ich hoffe das o.a. ist jetzt nicht komplett verwirrend sondern hilft Dir 
etwas weiter. Vielleicht kann ja auch nochmal Lukas etwas zu einer 
möglichen Implementierung in der Methode processPayload (bzw. 
buildPayload) sagen.

Ich hoffe das klappt mit dem MI-Wechselrichtern bei Euch noch demnächst.

[Herbert K. (avr-herbi)]

Stefan T. schrieb:
...
> Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das
> ist m.W. Giga Devices, China)
...
Könnte dieser sein (Datenblatt siehe Anhang)

[Daniel M. (daniel_m821)]

Stefan T. schrieb:
> Hallo Daniel M.,
>
> probier mal die Anfrage umgekehrt zu stellen, d.h. erst DTU dann WR
> Adresse:
> Also
>
>> Transmit 11 | 09 78 56 34 12 63 50 03 16 00 27
>
> das sollte dann eigentlich die Antwort geben
>
>> 89 63 50 03 16 78 56 34 12 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE

DTU und WR-ID umdrehen klappt nicht, es folgen keine Antworten mehr.
Ich sende 0x09 und erhalte im normalfall eine 0x88 und eine 0x89 zurück.

88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B 
89 63 50 03 16 63 50 03 16 01 2F 00 05 09 5D 13 86 00 97 07 CC 01 60 5E

Die 0x88 ist der Status, hier die 03 ist der Modulstatus (verbunden und 
aktiv)
Die 0x89 sind die Werte:

 89 63 50 03 16 63 50 03 16 01 2F 00 05 09 5D 13 86 00 97 07 CC 01 60 5E
1 + 4           + 4         + 2   + 2   + 2   + 2   + 2   + 2   + 2   + 1
CMD >WR ADR    < >WR ADR   < >29,9V<>0,86A<>239,6V<>4997Hz<>24,69W< 
>0,696kWh< >51,1°C< CRC8

CMD, WR-ID, WR-ID, DC_U, DC_I, AC_U, AC_Freq, AC_Pow, Day_kWh, 
WR_Temperatur

Das gleiche gilt für die Anfrage 0x11 mit den Antworten 0x91 Status und 
0x92 Werte.

Mit Hubi seiner NRF24_SendRcv bekomme ich folgedes als Payload zurück:

00 7388888801 0096 12 3 88 63500316 63500316 00030000000000008B187E 1
00 7388888801 00C4 18 2 89 63500316 63500316 012B000409641384007D07D8014BB5780D 1

00 7388888801 00C4 18 2 91 63500316 63500316 013400030965138500720768014A0BACD6 1

00 7388888801 0096 12 3 92 63500316 63500316 00030000000000009158D6 1

Ich habs bisher noch nicht geschafft, das komplett anzeigen zu lassen.
Wird in der ahoy-Version der kram vor 0x88 usw. verworfen und ich starte 
quasi mit der Antwort bei packet[0] oder starte ich bei [10] und mit der 
Adresse bei [11]?

In allen Versuchen mit verschiedenen Adressen in dem Teil:

if(0 != len) {
                    Inverter<> *iv = mSys->findInverter(&p->packet[1]);
                    if(NULL != iv) {

habe ich nichts verwertbares bekommen. Den Debug konnte ich soweit 
verändern, dass er mir immer eine len=0 und maxPackId=4 ausgegeben hat, 
falls da überhaupt was war. Bei packet[1] hat die Funktion retransmit 
gegriffen, "Frame 1 missing", bei allen anderen Versuchen war "Last 
Frame missing".

Die anderen Tips schau ich mir gleich an.

> Ich hoffe das o.a. ist jetzt nicht komplett verwirrend sondern hilft Dir
> etwas weiter. Vielleicht kann ja auch nochmal Lukas etwas zu einer
> möglichen Implementierung in der Methode processPayload (bzw.
> buildPayload) sagen.

War nicht komplett verwirrend, aber ich brauche etwas Zeit um alles 
anzuschauen und nachzuvollziehen.
Ich denke, ich bin immernoch nur am Symptom dran, nicht an der Ursache. 
Irgendwo hab ich etwas übersehen, was verkehrt läuft.
Gerne mehr Informationen und Ideen :)

> Ich hoffe das klappt mit dem MI-Wechselrichtern bei Euch noch demnächst.

Das hoffe ich auch, hab ich ehrlich gesagt unterschätzt, wie aufwändig 
es ist.

Danke auf jeden Fall für deine ausführliche Antwort, ich probier weiter.

[Peter L. (leliep)]

Holger S. schrieb:
> Peter L. schrieb:
>> Für diese Variante habe ich folgende Komponenten verwendet:
>> 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von
>> Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die
>> freundlicherweise verschraubt und nicht genietet sind, leicht zu
>> zerlegen und perfekt für den vorgesehenen Zweck geeignet.
>
> Solche alten Gehäuse ausgeschlachteter Steckernetzteile hab ich auch
> noch zu Hauf rumligen. Aber je mehr ich damit hantiere fällt mir auf das
> ich es immer gehasst habe das man diese Dinger nie da reingesteckt
> bekommt wo man sie gerade heben möchte. In Mehrfachsteckdosen belegen
> sie meist 2 Plätze oder passen eben gar nicht mit den anderen
> Winkelsteckern zusammen, usw...
> Außerdem denke ich ist man mit der WLan Antennen Ausrichtung des Wemos
> flexibler wenn man das Gehäuse mit einem 230V Netzkabel ausstattet.
>
> Ich werde die Variante mit Standard Gehäuse weiter verfolgen.
>
ich denke, die Umsetzung sollte sich immer an den individuellen 
Anforderungen orientieren. Für mich ist klein und kompakt wichtig...

>> 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne.
>
> Ich werde in das Gehäuse ein Nrf24l01+pa+lna Modul verbauen. Dann kann
> ich ein SMA  Verlängerungskabel verwenden um die Antenne flexibel,
> wahrscheinlich sogar Outdoor (weil Blechdach) zu positionieren.
> Dann muß ich die Technik selber auch nicht wasserdicht ausführen und
> kann sie Indoor lassen, ist mir lieber.

bisher habe ich leider noch kein mit dem HM-1200 funktionierendes 
Funkmodul mit Antennenpin auftreiben können, daher die Platinenversion, 
die aber erstaunlich gut funktioniert. Auch eingebaut und fest in der 
Steckdose verstöpselt.

>
>> 8. 10uF Elko an 3.3V Versorgung dazu
>
> Ist das zu empfehlen ? Arbeitet das dann stabiler ? Auch ein Elko an 5V
> ?

es gibt irgendwo in diesem Thread eine Empfehlung dazu, die für mich 
plausibel klingt, daher habe ich das gemacht. Zu einem Elko an 5V kann 
ich nichts sagen, es schadet nicht, aber ob es eine Verbesserung 
bringt...?

[oxylog (Gast)]

Holger S. schrieb:
> Ist das zu empfehlen ?

Quelle für den Tipp: http://stefanfrings.de/esp8266/ oder 
https://esp8266-server.de/Tipps.html

[Stefan T. (isnoahoy)]

oxylog schrieb:
> Holger S. schrieb:
>> Ist das zu empfehlen ?
>
> Quelle für den Tipp: http://stefanfrings.de/esp8266/

Wemos D1 Mini Board
...
Der Spannungsregler reicht gerade für den WLAN Chip aus, er darf extern 
nur minimal belastet werden (50 mA bei 5 V). Um die Zuverlässigkeit zu 
verbessern, empfehle ich einen 100 µF Kondensator zwischen 3,3V und GND.

> oder https://esp8266-server.de/Tipps.html

Adapter Plate With IO Lead Out For ESP-07 ESP-08 ESP-12
...
Außerdem fehlt auf der Platine ein Puffer Kondensator an 3,3V –Seite. Es 
muss mindestens 100uF sein, denn ESP8266 Modul erzeugt kurzzeitig die 
Strompeaks von 400mA.

[Stefan T. (isnoahoy)]

Herbert K. schrieb:
> Stefan T. schrieb:
> ...
>> Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das
>> ist m.W. Giga Devices, China)
> ...
> Könnte dieser sein (Datenblatt siehe Anhang)

Treffer GD32 E329G8 ist ein STM blue pill clone.

Wegen dem 300A E965 945 habe ich dem o.a. FCC Beitrag noch folgendes 
entnommen:

4.1 NRF Channel List
Depending on the program, the module can work on 915MHz for North 
America and 868MHz for Europe. Unless necessary, it’s forbidden to 
change the module program.

Das spricht zumindest für NRF m.W. ein Nordic Semiconductors Standard. 
Vielleicht findet man ja mit NRF und der Frequenz etwas mehr, ich tippe 
auf einen nRF905 Clone ?

Data Sheet z.B. hier
https://www.sparkfun.com/datasheets/IC/nRF905_rev1_1.pdf

[Daniel R. (daniel92)]

Moin zusammen,

ich habe nun das NRF Module auf dem Raspberry zum laufen bekommen. :)

Poll inverter 116174403329
2022-06-20 14:43:35.254088 Transmit 27 | 15 74 40 33 29 78 56 30 01 80 0b 00 62 b0 79 87 00 00 00 05 00 00 00 00 bd d7 ec
2022-06-20 14:43:35.311724 Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 01 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00 00 95
2022-06-20 14:43:35.346887 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 d7 00 00 00 03 00 01 42
2022-06-20 14:43:35.417421 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 07 00 00 00 00 00 00 00 01 00 00 00 00 00 03 93
2022-06-20 14:43:35.458275 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 01 0d 00 0b c4 fc 2e
2022-06-20 14:43:35.960403 Payload: 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d7 00 00 00 03 00 01 00 07 00 00 00 00 00 00 00 01 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 01 0d 00 0b c4 fc
2022-06-20 14:43:35.960403 Decoded: temp=26.9, pf=0.0 phase0=voltage:0.3, current:0.0, power:0.0, frequency:0.0 string0=voltage:0.1, current:0.0, power:0.0, total:0.0, daily:0 string1=voltage:0.1, current:0.01, power:0.0, total:0.0, daily:0 string2=voltage:21.5, current:0.0, power:0.1, total:0.0, daily:0 string3=voltage:21.5, current:0.03, power:0.7, total:0.001, daily:0

Bekomme aber hin und wieder ein missing frame zurück. =(
Error while retrieving data: Frame 3 missing: Request Retransmit
Error while retrieving data: Frame 1 missing: Request Retransmit
Error while retrieving data: Missing packet: Last packet 2

[Holger S. (skusi)]

Tach auch,

ich habe nun gestern mein Platinenlayout fertig gestellt. Nun stellt 
sich mir noch die Frage nach der stabilen Spannungsversorgung des RF24.

Ich habe mal eben eine über 30 min die Stromaufnahme des Transceiver bei
Amplifier Power Level Max und drei Invertern gemessen. Die Spitzen lagen 
bei 34 mA.
Auf http://stefanfrings.de/esp8266/ steht geschrieben:

3V3  VCC  Spannungsversorgung 3,3 V (Eingang 500 mA oder Ausgang max. 50 
mA)

Wäre also im Limit. Trotzdem ist ein 100 µF Kondensator sicher nicht 
falsch.

Ich könnte zur Sicherheit natürlich noch einen eigenen Spannungsregler 
für den RF24 dazu stricken.

Eine andere Überlegung ist ein 3,3V Netzteil einzusetzen und den RF24 
sowie den Wemos damit zu versorgen. Im Netzt ließt man aber 
unterschiedliche Meinungen dazu ob es gut ist den Wemos eigenen 
Spannungsregler "rückwärts" mit 3,3 V zu betreiben. Es würde die Sache 
aber um einen Spannungsregler leichter machen. Den 100 µF Kondensator 
würde ich zur Sicherheit dann trotzdem an das Netzteil hängen.

Ich kann mich nicht entscheiden, wie ist Eure Meinung dazu ?

[Günter H. (gnter_h534)]

@ Holger

Der nRF24L01+ kann aber auch deutlich mehr Strom aufnehmen:
"The modules operate in the 2.4GHz band at data rates of 250Kbps, 1Mbps 
or 2Mbps.  Max operating current is < 115mA."
(Quelle: 
https://protosupplies.com/product/nrf24l01palna-2-4ghz-rf-wireless-module/)

Mit diesem Wert wäre man außerhalb einer stabilen Spannungsversorgung.

Mein Vorschlag: Zweiten 3,3V-Spannungsregler (und Peripherie) auf 
Platine vorsehen mit der Option, diesen Spannungsregler ggf. nicht zu 
bestücken und über eine dann einzulötende Drahtbrücke zu überbrücken.

[Ziyat T. (toe_c)]

MI-1500:
- Beim Sniffen keine Sender Daten vom ESP gesehen, lange gesucht und
- meine beiden ESP's waren futsch!!!!!, MOSI gehen an beiden nicht??!
- auf Arduino gewechselt
- es muss die PA Einstellung RF24_PA_LOW sein, schon mit RF24_PA_HIGH 
geht nichts mehr! Mein MurxBoard ist 10m vom WR weg.

- Warum bei beiden ESP's die MOSI's kaputt sind: kann die Standard 
Einstellung RF24_PA_MAX der Grund sein???

Hier mit 3 PV's

Send... CH75 36637071607222841200F2
Send... CH3 37637071607222841200F3
Send... CH23 38637071607222841200FC
Send... CH40 39637071607222841200FD
Send... CH61 36637071607222841200F2
00 1284227201 00DE 1B 3  B6 63707160 63707160 
01750004091E1387009703E0013E0300030EEAC5 1
PV:1 37.30V 0.40A 15.10W 992.00Wh 233.40V 49.99Hz 31.80C  Sts:3 Cnt:0

Send... CH75 37637071607222841200F3
Send... CH3 38637071607222841200FC
Send... CH23 39637071607222841200FD
Send... CH40 36637071607222841200F2
Send... CH61 37637071607222841200F3
00 1284227201 00DA 1B 1  B7 63707160 63707160 
017500040920138600AE040C013E030003E28DBB 1
PV:2 37.30V 0.40A 17.40W 1036.00Wh 233.60V 49.98Hz 31.80C  Sts:3 Cnt:0

Send... CH75 38637071607222841200FC
Send... CH3 39637071607222841200FD
Send... CH23 36637071607222841200F2
Send... CH40 37637071607222841200F3
Send... CH61 38637071607222841200FC
00 1284227201 00D8 1B 0  B8 63707160 63707160 
0163000409231387009106E1013F03000328AD7E 1
PV:3 35.50V 0.40A 14.50W 1761.00Wh 233.90V 49.99Hz 31.90C  Sts:3 Cnt:0

Send... CH75 39637071607222841200FD
Send... CH3 36637071607222841200F2
Send... CH23 37637071607222841200F3
Send... CH40 38637071607222841200FC
Send... CH61 39637071607222841200FD
00 1284227201 00D8 1B 0  B9 63707160 63707160 
016300000921138600030006013E0300035C4E20 1
PV:4 35.50V 0.00A 0.30W 6.00Wh 233.70V 49.98Hz 31.80C  Sts:3 Cnt:0

[Richard K. (laserrichi)]

Holger S. schrieb:
> Eine andere Überlegung ist ein 3,3V Netzteil einzusetzen und den RF24
> sowie den Wemos damit zu versorgen. Im Netzt ließt man aber
> unterschiedliche Meinungen dazu ob es gut ist den Wemos eigenen
> Spannungsregler "rückwärts" mit 3,3 V zu betreiben. Es würde die Sache
> aber um einen Spannungsregler leichter machen. Den 100 µF Kondensator
> würde ich zur Sicherheit dann trotzdem an das Netzteil hängen.
>
> Ich kann mich nicht entscheiden, wie ist Eure Meinung dazu ?

auf dem Wemos ist ja ein RT9013 verbaut, vom Blockschaltbild sehe ich 
erstmal kein Problem wenn auf der 3,3V Seite Spannung anliegt.

Ich würde das ganze sowieso entkoppeln, alleine wegen dem ganzen Funk 
und HF zeugs was sich gegenseitig ja stört. Einfach einen zweiten RT9013 
nur für den RF24 nehmen und dann kannst du alles mit 5V Versorgen.

[Daniel M. (daniel_m821)]

Ich habe nach Stefan seiner Anleitung noch etwas rumprobiert und bin 
hier rausgekommen:

D: Received 18 bytes channel 75: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B
D: ],[0,6103,"normal"],[0,3104,63.62],[0,6101,0],[0,9101,"roller"],[0,4108,239.21]]}

D: Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 00 E4 00 00 09 4E 13 88 00 0D 01 E2 00 BC E3
D: ],[0,6103,"normal"],[0,3104,63.62],[0,6101,0],[0,9101,"roller"],[0,4108,239.21]]}

Wo kommen "normal" und "roller" her, was ist das?

Wie genau wird die mPayload zusammengebaut? Wofür stehen die 
".data"-Adressen?

memcpy(mPayload[iv->id].data[3], &p->packet[16], len-9);
mPayload[iv->id].len[3] = len-8;

Ich denke, so langsam verstehe ich, was passiert.

@Ziyat:
Glückwunsch! :)
Das PA_Max war es wahrscheinlich nicht, mein Wemos hält bisher stand.

lg

[Stefan T. (isnoahoy)]

Hallo Holger,

ich kann noch das folgende vom Author der RF24 Bibliothek beisteuern:

my PA/LNA module fails to transmit
https://nrf24.github.io/RF24/md_COMMON_ISSUES.html

You may find variants of the nRF24L01 transceiver that are marketed as 
“nRF24L01+PA+LNA”. These modules are distinct in the fact that they come 
with a detachable (SMA-type) antenna. They employ seperate RFX24C01 IC 
with the antenna for enhanced Power Amplification (PA) and Low Noise 
Amplification (LNA) features. While they boast greater range with the 
same functionality, they are subject to a couple lesser known (and 
lesser advertised) drawbacks:

    Stronger power source. Below is a chart of advertised current 
requirements that many MCU boards’ 3V regulators may not be able to 
provide (after supplying power to internal components).
    Specification   Value
    Emission mode current(peak)   115 mA
    Receive Mode current(peak)   45 mA
    Power-down mode current   4.2 µA
    Needs shielding from electromagnetic interference. Shielding usually 
works best when it has a path to ground (GND pin), but this connection 
to the GND pin is not required. It is important that the sheilding does 
not touch any current carrying parts.
        Professionals tend to use a faraday cage/mesh to implement 
electromagnetic shielding, but it can be pricey for this scenario.
        A quick do-it-yourself solution (as proof-of-concept) would be 
to wrap the PA/LNA module with electrical tape and then wrap foil around 
the electrical tape (for shielding) while being very careful to not let 
the foil touch any current carrying parts (like the GPIO pins, the 
antenna mount, and the soldier joints for the antenna mount). Observe 
ghetto_shielding_1.png ghetto_shielding_2.png


Sowie hier die Empfehlung einen Kondensator zwischen 3,3V und GND zu 
klemmen:

Troubleshooting
https://howtomechatronics.com/tutorials/arduino/arduino-wireless-communication-nrf24l01-tutorial/

It’s worth noting that power supply noise is one of the most common 
issues people experience when trying to make successful communication 
with the NRF24L01 modules. Generally, RF circuits or radio frequency 
signals are sensitive to power supply noise. Therefore, it’s always a 
good idea to include a decoupling capacitor across the power supply 
line. The capacitor can be anything from 10uF to 100uF.
NRF24L01 Troubleshooting- decoupling capacitor and external power supply

Another common issue is that the 3.3V pin of the Arduino boards, cannot 
always supply enough power to the NRF24L01 module. So, powering the 
module with an external power source is also a good idea.


Fixing NRF24L01+ Modules Without Going (Too) Insane
https://hackaday.com/2021/01/22/fixing-nrf24l01-modules-without-going-too-insane/

Ich habe auch irgendwo bei Hack-A-Day gelesen, daß es evtl. besser ist 
einen Elko mit ca. 100uF und 25V und ein Tantalum Cap mit 1-10pF 
parallel anzuklemmen um sowohl hoch- als auch niederfrequente Teile der 
Versorgungsspannung zu glätten.


Bei mir läuft es (das o.g. PA Modul mit Antenne und ohne Schirmung vom 
maker"laden") ganz ohne Elko, etc. Ich würde daher empfehlen drei Plätze 
vorzusehen, für den Elko, für den Tantalum und einen für die Lötbrücke, 
am besten die Lötbrücke fest verdrahten zum raus-cuttern, wenn man die 
Elkos und/oder Tantalum einbaut.

[Stefan T. (isnoahoy)]

Hallo Daniel,

mach doch mal ein Issue auf Github auf, damit wir dort die Punkte für 
den MI-Wechselrichter abstimmen, hier gehen die Punkte m.E. etwas 
verloren, da ja auch noch andere Diskussionen ablaufen ?

Daniel M. schrieb:
> Wo kommen "normal" und "roller" her, was ist das?
>
> Wie genau wird die mPayload zusammengebaut? Wofür stehen die
> ".data"-Adressen?
>

> memcpy(mPayload[iv->id].data[3], &p->packet[16], len-9);
> mPayload[iv->id].len[3] = len-8;
>

>
> Ich denke, so langsam verstehe ich, was passiert.

normal und roller habe ich bei mir noch gar nicht gesehen... "roller" 
z.B. kann ich auch im repo von grindylow/ahoy nirgends finden ?

mPayload ist eine Struktur, mit einem data[] Array.
In data[0..3] werden Deine vier Antworten bzw. die Daten davon, also 
alles ab packet[10..len] abgelegt, das sind dann len-10 bytes.
in len[0..3] wird die Länge der jeweiligen Daten im Packet abgelegt, 
also die len-10 bytes.

Bei diesem Vorgang werden die Daten mit der memcpy(ziel, anfang_quelle, 
länge) Funktion kopiert.
Die Länge ist nur ein Wert, der wird direkt zugeordnet.
Das heißt am Ende hast Du in mPayload.data[0..3] Deine Daten, ohne die 
Adressen und die Antwort ID 0x88/0x89,0x91/0x92.
Weil die Daten beim HM-Wechselrichter unterschiedlich lang sein können, 
vor allem das letzte Paket ist i.d.R. nicht 12 Byte lang, deshalb gibt 
es das len[0..3] Feld in dem die jeweilige Länge steht.
Der HM-Wechselrichter hat dann in den letzten beiden Bytes des letzten 
Pakets noch eine Prüfsumme (CRC-M/CRC-16) stehen, die in buildPayload 
geprüft wird.
Da die MI-Baureihe keine zweite Quersumme hat, kann der Teil m.E. 
entfallen.

Du mußt also nur die Daten in processPayload den entsprechenden Werten 
zuordnen und ggf. durch 100 oder 1000 teilen. Das wird in hmDefines.h 
für jeden HM-Wechselrichter definiert und dann nach diesen Vorgaben 
umgerechnet.

[Ziyat T. (toe_c)]

MI-1500
========
Limitierung laeuft!

Hier als Bsp. die Limitierung auf 5% (5a:5a:05:)

Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1
Rcv... auf 0x51 cmd=0xD1  (korrekt)

WR zeigt Status 8 > PVs sind ausgeschaltet, weil bei MI unter 10% nicht 
limitiert werden kann

Send... CH3 38:63:70:71:60:72:22:84:12:00:fc:
Send... CH23 39:63:70:71:60:72:22:84:12:00:fd:
Send... CH40 36:63:70:71:60:72:22:84:12:00:f2:
Send... CH61 37:63:70:71:60:72:22:84:12:00:f3:
00 1284227201 00DA 1B 1  B7 63707160 63707160 
01C900000941138700050062017E081F01ADC76E 1
PV:2 0.50W 45.70V 0.00A 98.00Wh 236.90V 49.99Hz 38.20C  Sts:8 Cnt:31

Send... CH3 39:63:70:71:60:72:22:84:12:00:fd:
Send... CH23 36:63:70:71:60:72:22:84:12:00:f2:
Send... CH40 37:63:70:71:60:72:22:84:12:00:f3:
Send... CH61 38:63:70:71:60:72:22:84:12:00:fc:
00 1284227201 00DA 1B 1  B8 63707160 63707160 
01C1000009441387000700B5017D081F01793AD4 1
PV:3 0.70W 44.90V 0.00A 181.00Wh 237.20V 49.99Hz 38.10C  Sts:8 Cnt:31

Send... CH75 39:63:70:71:60:72:22:84:12:00:fd:
Send... CH23 37:63:70:71:60:72:22:84:12:00:f3:
Send... CH40 38:63:70:71:60:72:22:84:12:00:fc:
00 1284227201 00D8 1B 0  B9 63707160 63707160 
01C10000093C138700050001017D081F01B6D1BA 1
PV:4 0.50W 44.90V 0.00A 1.00Wh 236.40V 49.99Hz 38.10C  Sts:8 Cnt:31

[Herbert K. (avr-herbi)]

Ziyat T. schrieb:
> MI-1500
> Limitierung laeuft!
Gratulation !

[Steff (Gast)]

Hallo Forum!

Eine Frage treibt mich um: Bei uns wurde ein STP 5.0-3SE-40 / SMA SUNNY 
TRIPOWER 5.0 - SMART ENERGY verbaut. Vielleicht findet die 
Schwarmintelligenz (?) auch darauf eine Antwort:
Gilt das in den letzten 1270 Beiträgen Gesagte dafür auch?

LG Steffi

[Andreas S. (drschiffler)]

Ziyat T. schrieb:
> MI-1500
> ========
> Limitierung laeuft!
>
Hi,

wie ich sehe ist auch bei Dir die Spannung an den Modulen 3/4 und 1/2 
identisch. Das liegt am Code im Decoder da hier die gleichen Bytes 
aufgelöst werden.
Allerdings ist in der Antwort vom Umrichter auch keine weitere 
Information zu den Spannungen drin. (Es fehlen schlicht Bytes rein 
rechnerisch)
Es gibt meinerseits zwei Vermutungen:
1. Das ist im Umrichter intern so verschaltet, dass die Module 3/4 und 
1/2 jeweils am gleichen Potential hängen.
2. Den Wert gibt es schlicht nicht. (Die Leistung ist ja individuell für 
jede der vier Module / Eingänge und wird auch ausgegeben)

Sonst noch Erklärungen?

Grüße
Andreas

[Ziyat T. (toe_c)]

Steff schrieb:
> Hallo Forum!
>
> Eine Frage treibt mich um: Bei uns wurde ein STP 5.0-3SE-40 / SMA SUNNY
> TRIPOWER 5.0 - SMART ENERGY verbaut. Vielleicht findet die
> Schwarmintelligenz (?) auch darauf eine Antwort:

Hallo Steff
Hier geht es nur um die Hoymiles Inverter, leider keine Lösung für den 
SMA SUNNY TRIPOWER hier

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> MI-1500
> ========
> Limitierung laeuft!

Sehr sehr cool schonmal. Unabhängik davon, konnte jemand schon was beim 
HM-1500 oder kleiner, etwas erreichen?

Die Dokus von Gitee sind ja fast ausschlieslich für MI bezogen, oder hab 
ich was übersehen?

[Ziyat T. (toe_c)]

Andreas S. schrieb:
> Ziyat T. schrieb:
>> MI-1500
>> ========
>> Limitierung laeuft!
>>
> Hi,
>
> wie ich sehe ist auch bei Dir die Spannung an den Modulen 3/4 und 1/2
> identisch. Das liegt am Code im Decoder da hier die gleichen Bytes
> aufgelöst werden.
> Allerdings ist in der Antwort vom Umrichter auch keine weitere
> Information zu den Spannungen drin. (Es fehlen schlicht Bytes rein
> rechnerisch)
> Es gibt meinerseits zwei Vermutungen:
> 1. Das ist im Umrichter intern so verschaltet, dass die Module 3/4 und
> 1/2 jeweils am gleichen Potential hängen.
> 2. Den Wert gibt es schlicht nicht. (Die Leistung ist ja individuell für
> jede der vier Module / Eingänge und wird auch ausgegeben)
>
> Sonst noch Erklärungen?
>
> Grüße
> Andreas
Hallo Andreas
MI hat 2 MPPTs für 4PVs
Module 1/2 am MPPT1
Module 3/4 am MPPT2
Die Grafik zeigt es auch, ich denke die hängen am gleichen Potential

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ziyat T. schrieb:
>> MI-1500
>> ========
>> Limitierung laeuft!
>
> Sehr sehr cool schonmal. Unabhängik davon, konnte jemand schon was beim
> HM-1500 oder kleiner, etwas erreichen?
>
> Die Dokus von Gitee sind ja fast ausschlieslich für MI bezogen, oder hab
> ich was übersehen?

Danke, es hat ja ziemlich lange gedauert...

Richtig, in den Dokus hab ich auch nichts extra für HM gesehen, aber
das Modbus-Doku beschreibt die gleiche Limitierung-Register für alle 
WR-Modelle, vielleicht geht es auch mit dem HM

[Daniel R. (daniel92)]

Das probiere ich Zuhause dann aus! =)

Ziyat T. schrieb:
> Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
> 00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1

Könntest du bitte ein Auszug von deinem Code durch geben?

Ich würde es ca. so abschicken. (Habe aktuell noch nicht viel 
abgeschickt)
Kümmere mich gerade um die Einbindung in 'Home Assistant' über MQTT. 
Dort will ich es als Entität einbinden und später mit Grafana noch 
anzeigen.

payload={0x5a, 0x5a, 0x05}
request=next(hoymiles.compose_esb_packet(payload,seq=b'\x80',src=dtu_ser,dst=inverter_ser)))

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Das probiere ich Zuhause dann aus! =)
>
> Ziyat T. schrieb:
>> Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
>> 00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1
>
> Könntest du bitte ein Auszug von deinem Code durch geben?
> >>>

payload={0x5a, 0x5a, 0x05}   0x05 ist % die Limitierung also hier 5% der 
angeschlossene Nennleistung.

Ich verwende immer noch die Hubi's SW auf Arduino, es wird hier 
gesendet:

void isTime2Send () {
//-----------------
  int32_t size = 0;
  uint64_t dest = WR1_RADIO_ID;
  uint8_t UsrData[5];
  // Second timer

  if (millis() >= tickMillis) {
    static uint8_t tel = 0;
    tickMillis += 500;    //200;
    //tickSec++;
    hmPackets.UnixTimeStampTick();
/*    if (++tickSec >= 5) {   // 5
      hmPackets.UnixTimeStampTick();
      tickSec = 0;
    } */

    if (tel > 5) {   tel = 0;    }

    if (COMMAND > 0x0039)
      COMMAND= 0x0036;

    if (tel == 0) {// Limitierung Command 0x51
      //set SubCmd and  UsrData
      UsrData[0]=0x5A;UsrData[1]=0x5A;UsrData[2]=0x0a;// 10% limit
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, 
DTU_RADIO_ID >> 8, 0x51, UsrData,3);
    }
    else {
      UsrData[0]=0x0;//set SubCmd and  UsrData
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, 
DTU_RADIO_ID >> 8, COMMAND, UsrData,1);
    }
   // DEBUG_OUT.print(F("size: ")); DEBUG_OUT.print(size);

    SendPacket(dest, (uint8_t *)&sendBuf, size);
    tel++;
    COMMAND++;
/*    for (uint8_t warte = 0; warte < 2; warte++) {
      delay(1000);
      hmPackets.UnixTimeStampTick();
    }*/
  } //if millis
}

[Günter H. (gnter_h534)]

Stefan T. schrieb:
> Ich würde daher empfehlen drei Plätze
> vorzusehen, für den Elko, für den Tantalum und einen für die Lötbrücke,
> am besten die Lötbrücke fest verdrahten zum raus-cuttern, wenn man die
> Elkos und/oder Tantalum einbaut.

Wenn die beschriebene Lötbrücke/Stelle zum Raus-Cuttern nur die 
Kondensatoren betrifft, braucht man das nicht vorzusehen: Bei 
Kondensatoren reicht bestücken oder nicht bestücken.

[Daniel R. (daniel92)]

Daniel R. schrieb:
> Das probiere ich Zuhause dann aus! =)

Habe ein HM-1500!

Folgende Antwort habe ich erhalten:
Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 05 70 ab 7a
Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 05 70 ab 7a
Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 
00 00 00 00 00 00 00 00 00 01 81 eb 9b

Edit:

Habe das ganze mal mit '\x5a\x5a\x01' (1% P-Limit?) gemacht.
Bekomme dann das hier, was könnte das alles sein?:

Poll inverter 116174403329
2022-06-21 15:49:21.612117 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc
2022-06-21 15:49:22.848184 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc
2022-06-21 15:49:22.888219 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
2022-06-21 15:49:23.391443 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
 payload has valid modbus crc
 payload has 14 bytes

Field view: int
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>B       128     0     0     0     0     0     0     0     0     0     0     0     0     1

Field view: shorts
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>H           32768           0           0           0           0           0           1
>H                     0           0           0           0           0           0

Field view: longs
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>L                  2147483648                       0                       0
>L                                 0                       0                       0
>L                                       0                       0                       1
>L                                             0                       0
 type utf-8  : utf-8 decode error
 type ascii  : ascii decode error
Poll inverter 116174403329
2022-06-21 15:49:23.395573 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc
2022-06-21 15:49:23.441496 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b

[IsnoAhoy (Gast)]

Hallo Ziyat T.,
Gratuliere zur MI-1500 Limitierung!

@Daniel R.,
Ziyat schickt ein Cmd 0x51, Du schickst nach wie vor ein 0x15 Cmd das 
kann also auch mit dem HM-1500 nur schiefgehen.

Und die Implementierung für HM-1500 etc. steckt wie für alle Hoymiles 
Generation 3 Geräte in der usart_nrf3.c, die die weiterhin genutzten 
Grundfunktionen der MI- und HM-Geräte der Generation 2 in usart_nrf.c 
erweitern / vervollständigen.
Lad den ganzen Code doch mal in VSCode oder einer anderen IDE Deines 
Vertrauens?

@Günther H.,
danke für die Korrektur! Irgendjemand schrieb was von Drahtbrücke 
einlöten. Aber so ein Kurzschluss zwisch +3V3 und GND ist natürlich 
elektronischer Blödsinn =^!

[Daniel R. (daniel92)]

IsnoAhoy schrieb:
> Ziyat schickt ein Cmd 0x51, Du schickst nach wie vor ein 0x15 Cmd das
> kann also auch mit dem HM-1500 nur schiefgehen.

Das ist mir auch aufgefallen, habe es dann korriegiert und erneut 
getestet.

Um denn WR in seiner Leistung zu drossel, sendet man ja folgenden Befehl 
ab:

              CMD                             (data )<value>
Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e
Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e
Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Nun wollte ich die Drosselung auslesen, jedoch kommt immer beim senden 
2b automatisch dazu (ohne mein willen)... Wieso?

              CMD                             (data ) <value?>
Transmit 15 | [d1] 74 40 33 29 78 56 30 01 80 (5a 5a) <2b> bb f0
Received 15 bytes channel 61: [d1] 74 40 33 29 74 40 33 29 80 (5a 5a) <2b> bb c1
Error while retrieving data: int too big to convert

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Daniel R. schrieb:
>> Das probiere ich Zuhause dann aus! =)
>
> Habe ein HM-1500!
>
> Poll inverter 116174403329
> 2022-06-21 15:49:23.395573 Transmit 16 | 15 74 40 33 29 78 56 30 01 80
> 5a 5a 01 b3 aa bc
> 2022-06-21 15:49:23.441496 Received 27 bytes channel 75: f1 74 40 33 29
> 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
>
> [/code]

Wenn dein Inverter die SN 116174403329 hat, dann müsste dein Packet zum 
Senden etwa so sein:
WR= 29 33 40 74
DTU= 78 56 30 01 (nehme ich mal an)
Command= 51 für Limitierung (früher MID)
SubCommand= 5a 5a (früher CMD aber nur 1 byte!)
UserData= 05   (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%)
ergibt CRC=90
51 74 40 33 29 78 56 30 01 5a 5a 0b 90

aber du schickst:
15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3  ???
15 ist, glaube, ein MID für Timepacket, 80 CMD für WR-Data


wenn ok, dann bekommst du als Bestaetigung CMD = 0xD1

Hier nochmals wie bei mir:
Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
Receive... 00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1

Ich glaube, du musst das Senden für Command=0x51 sep. neu programmieren.

Die bisher verwendeten Bezeichnungen MID und CMD sind nun etwas 
unglücklich, denn es gibt viele Kontroll Befehle/Commands mit 
SubCommands und Userdata, wie die Limitierung eben.

[Herbert S. (herbert_s445)]

Hallo Zusammen,

ich verfolge seit einiger Zeit diesen Thread und bin beeindruckt von der 
Professionalität und was man mit einer guten Zusammenarbeit gemeinsam 
erreichen kann ...

Jetzt versuche ich das System (esp8266 und nRF24L01) zum Laufen zu 
bringen.
Aktuelle nutze ich Version 0.4.19
ich komme leider nicht weiter, denn ich bekomme die folgende 
Fehlermeldung:

W: WARNING! your NRF24 module can't be reached, check the wiring

I: [NTP]: 2022-06-20 23:14:32
I: Inverter #1 I: no Payload received! (retransmits: 0)
I: Requesting Inverter SN 116174401924
I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 
00 05 00 00 00 00 7F EC 7C
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 
00 05 00 00 00 00 7F EC 7C
pm open,type:2 0
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 
00 05 00 00 00 00 7F EC 7C


folgendes habe ich schon versucht:
1) Tausch des NRF24 moduls
2) verschiedene Varianten der Verdrahtung (CE,CS,IRQ)
3) 10µF Kondensator zwischen GRND und 3,3V

Aber alles hat keinen Einfluss auf die Fehlermeldung.
Vielleicht kann mir jemand helfen, wäre doch schade, wenn ich kurz vor 
dem Ziel scheitere.

LG
Herbert

[Andreas Arp (Gast)]

...stärkeres Netzteil ?

[Ziyat T. (toe_c)]

@Daniel R.

Ziyat T. schrieb:
> WR= 29 33 40 74
> DTU= 78 56 30 01 (nehme ich mal an)
> Command= 51 für Limitierung (früher MID)
> SubCommand= 5a 5a (früher CMD aber nur 1 byte!)
> UserData= 05   (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%)
> ergibt CRC=90

sorry, in dem Fall ist der CRC natürlich nicht 0x90, ich meinte nur als 
Bsp.

[Daniel R. (daniel92)]

Also ich bekomme es gerade nicht ganz hin...

Transmit 15 | 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5

Statt letzten drei bytes, soll nur ein byte für CRC geschickt werden.
Aber irgendwie wird im Python code angehängt.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Also ich bekomme es gerade nicht ganz hin...
>
> Transmit 15 | 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5
>
> Statt letzten drei bytes, soll nur ein byte für CRC geschickt werden.
> Aber irgendwie wird im Python code angehängt.

- ist die CRC=0xb4 für  0x51 bis 0xb richtig?
- wurde die buffer len des Pakets zum Senden richtig übergeben?

[Daniel R. (daniel92)]

Genau da bin ich aktuell dran, aber ich finde nirgendwo eine Angabe wie 
lang das Paket seien soll. - Ich mach mal ein cut. Hab schon ewig nicht 
mehr mit Python mich ausseinander gesetzt.

Ziyat T. schrieb:
> - ist die CRC=0xb4 für  0x51 bis 0xb richtig?

Glaube ich nicht, da die CRC erst am ende angehängt wird.

Ziyat T. schrieb:
> - wurde die buffer len des Pakets zum Senden richtig übergeben?
von meiner Seite 'noch?' nicht.

Beim debuggen sehe ich das meine payload genau 3 bytes lang ist '5a 5a 
0b'.
Das passt. Nur der hintere Teil ist für mich gerade sehr gespenstig! :(

Der ganze Python script steckt ja noch in den Kinderschuhen.

Gruß

[SeekerBot (Gast)]

Hallo zusammen, ich möchte mich ganz herzlich für die tolle Arbeit 
bedanken! Ich nutze seit ein paar Tagen Ahoy-esp8266 mit einem HM1500 
und es war super easy einzurichten und alles scheint zu funktionieren.

Eine Frage: darf/soll ich in der Readme bei esp8266 den HM1500 ergänzen? 
In anderen Worten, ist die Datei veraltet oder gibt es einen Grund, 
warum ihr den HM1500 nicht aufführt?

Und ich kann sogar etwas beitragen: ich habe ein kleines Gehäuse 
entworfen für den 3D Drucker... die Dateien findet Ihr auf 
https://www.printables.com/model/229686-box-case-housing-for-wemos-d1-mini-and-nrf24l01-fo 
zum selber drucken, anpassen, drucken lassen... Und als Dankeschön von 
mir an alle Programmierer: wer hier beigetragen hat und so ein Gehäuse 
gerne hätte braucht sich nur zu melden. :)

Vielen Dank und Grüße

Seekerbot

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

anbei nochmal ein Screenshot aus den RF_communication_protocol_v6.5.xlsx 
als Wink mit der Dokumentation des Herstellers.

Daniel R. schrieb:
> Genau da bin ich aktuell dran, aber ich finde nirgendwo eine Angabe wie
> lang das Paket seien soll. - Ich mach mal ein cut. Hab schon ewig nicht
> mehr mit Python mich ausseinander gesetzt.
>
> Ziyat T. schrieb:
>> - ist die CRC=0xb4 für  0x51 bis 0xb richtig?

Gute Frage Ziyat, die Antwort muß Daniel sich noch geben: Das ist auf 
jeden Fall um zwei Bytes zu lang!
51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5

So lang sollte es maximal sein und anstelle von 0xb4 muß da definitiv 
die richtige CRC-8 hin, sonst verwirft es der WR gleich wieder und 
antwortet mit nem Fehler:
<51>  <74 40 33 29> <78 56 30 01> <5a 5a>  <0b>  <b4>
<CMD> <WR Addresse> <DTU Adresse> <SubCmd> <10%> CRC8
1,2,3,4, ... 12 Bytes plus ein Byte CRC8.

Warum steht da bei Dir Daniel eigentlich 78 56 30 01 und nicht die sonst 
übliche DTU Addresse 78 56 34 12 ?

[Maik R. (bastelbarney)]

IsnoAhoy schrieb:
> Wenn
> ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und
> Raspberry Pi hochladen.

Das wäre sehr cool!

Ich habe meine NodeMCU auf einem freien Rest Breadboard 
zusammengesteckt, wobei die NodeMCU ja dann leider "unter" der Platine 
zu verdrahten ist (Fotos) weil sie zu breit für Breadboards ist. Die 
Kabelfarben zum nRF24 habe ich 1:1 übernommen, die waren im 
Wemos-Fritzing schon top gewählt! Aber die Drahtbrücken für das 
Breadboard hatte ich nicht in den nötigen Farben. Hier ging nur, was 
noch in der Kiste übrig war.

Vielleicht ist meine Fotosammlung eine Anregung für Zögerliche, endlich 
auch loszulegen? Ja, ja, Breadboard und Brücken sind unzuverlässig, ich 
weiss. Aber es läuft und nichts hält länger als ein Provisorium...

Der Breadboard-Aufbau läuft auch in kleinster Sendeleistung um eine 
Hausecke herum (Poroton und Klinker) und entweder durch die Panels oder 
um die Panels herum. Es sind ca. 10 m Entfernung zum HM-1500. und in 4 m 
Entfernung funkt noch ein DTU-WLite.
Allerdings benutze ich für die AHOY-nRF24 eine über 50 Jahre alte, 
hölzerne Statue zweier lokaler Superhelden ;-) vielleicht macht's das XD

[Stefan T. (isnoahoy)]

Hallo Herbert S.,

schau doch mal bitte im Github Issue #36 vorbei. Da diskutieren wir das 
bzw. ähnliche Probleme bei der Schaltung mit der ESP8266 Software.

ESP8266: Discussion Verkabelung / Pinout #36
https://github.com/grindylow/ahoy/issues/36

Das hier sagt eindeutig, daß er das NRF24 Modul nicht erreichen kann:
W: WARNING! your NRF24 module can't be reached, check the wiring

Die darauf folgenden anderen Versuche mit der fehlenden / falschen 
Konfiguration zu senden schlagen natürlich fehl.
Schau doch mal bitte im Setup Menü nach den dort hinterlegten Pin 
Einstellungen und speichere alles noch Mal. Eventuell muß man auch alle 
0xFF oder sonstigen Werte aus den anderen Feldern nochmal entfernen und 
die Settings speichern und den ESP rebooten (Flag ganz unten links).

Wichtig wäre auf jeden Fall welches ESP8266 Modul Du verwendest und 
welches nRF24L01+ Modul Du hast.

Vielleicht kannst Du dort auch mal Deine Schaltung und die Konfiguration 
(Screenshot aus der Setup Seite) hochladen ?

[Maik R. (bastelbarney)]

Ziyat T. schrieb:
> Richtig, in den Dokus hab ich auch nichts extra für HM gesehen, aber
> das Modbus-Doku beschreibt die gleiche Limitierung-Register für alle
> WR-Modelle, vielleicht geht es auch mit dem HM

Wie oben erwähnt, läuft mein HW-15000 mit AHOY / ESP8266 ver 0.4.19, 
selbst compiliert (nutze ohnehin gelegentlich ArduinoIDE oder VSCode) 
und ich kann gerne Patches oder andere Programme von Euch übernehmen und 
ausprobieren.

Habe ein Messgerät auf der Hutschiene, kann also recht schnell in echt 
sehen, was Änderungen bewirkt haben. Nur leider den RS485 am Stromzähler 
verplombt bekommen :,-(

Was ich mangels DTU-Pro nicht kann, ist sniffen, welche Kommandos der 
senden würde.

Abends zwischen 18:00 und Sonnenuntergang kann ich oft noch was testen.
Einfach bescheid sagen...

[Maik R. (bastelbarney)]

Herbert S. schrieb:
> Vielleicht kann mir jemand helfen, wäre doch schade, wenn ich kurz vor
> dem Ziel scheitere.

Ich nutze diese NodeMCU von AZ-Delivery (weil sie hier rumliegen):

"AZDelivery 3 x NodeMCU Lolin V3 Module ESP8266 ESP-12F WiFi WiFi 
Development Board mit CH340"

und

"NRF24L01+ PA LNA SMA" von Makershop.de.

Ganz primitiv auf einem Breadboard gesteckt, also eher "schlecht" 
verdrahtet, wenn man Bedenken bzgl. der Spannungsstabilität am NRF24 
hat.
(Fotos: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")

Kein Elko, keine Tantalperle, keine separate 3V3 Versorgung!
CSN => D8
CE => D4
IRQ => D3
Sendeleistung auf Min oder Low (bei mir egal).

Lief sofort (nachdem ich ein Micro-USB-Kabel ausgewechselt habe, aber 
mit dem vorigen Kabel war schon der COM-Port in der Systemsteuerung und 
ArduinoIDE nicht sichtbar - also eher nicht das Problem, das Du hast). 
Habe damit ab und zu Falsch-Anzeigen und in der Statistik etwa 20% 
Fehler, aber läuft erstmal.

Vielleicht MOSI und MISO vertauscht?

[Stefan T. (isnoahoy)]

Hallo Maik R.,

>> Wenn ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und
>> Raspberry Pi hochladen.
> Das wäre sehr cool!

habe mal schematics und fritzing für Arduino, Raspberry Pi und ESP8266 
(NodeMCU) in mein github eingecheckt.

https://github.com/grindylow/ahoy/pull/80/commits/6015cbe0729ec13661a7229fdb15b90b587395d9

Mal sehen wann Lukas den PR mergen kann.

> Allerdings benutze ich für die AHOY-nRF24 eine über 50 Jahre alte,
> hölzerne Statue zweier lokaler Superhelden ;-) vielleicht macht's das XD

Ja die sind schick, nur leider sieht man auf dem Photo die Gesichter der 
Beiden nicht =^D

Hier im Anhang die Bildchen von meinem Aufbau mit NodeMCU. Auf meinem 
großen Breadboard passt der ESP gerade so zwischen zwei Reihen, daß noch 
bißchen mehr Platz für die Kabel übrig ist. Das ist ein echter Nachteil 
von dem Modul: der Platz auf dem Breadboard =^D

[Daniel R. (daniel92)]

Stefan T. schrieb:
> Gute Frage Ziyat, die Antwort muß Daniel sich noch geben: Das ist auf
> jeden Fall um zwei Bytes zu lang!
> 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5

Richtig, das habe ich gestern auch so geschrieben. Vielleicht mit 
anderen worten (irgendwann sieht man den Wald vor lauter Bäumen nicht 
mehr => hab eine Pause gebraucht).


> So lang sollte es maximal sein und anstelle von 0xb4 muß da definitiv
> die richtige CRC-8 hin, sonst verwirft es der WR gleich wieder und
> antwortet mit nem Fehler:
> <51>  <74 40 33 29> <78 56 30 01> <5a 5a>  <0b>  <b4>
> <CMD> <WR Addresse> <DTU Adresse> <SubCmd> <10%> CRC8
> 1,2,3,4, ... 12 Bytes plus ein Byte CRC8.

Richtig, daran werde ich mich heute nochmal hinsetzen.

> Warum steht da bei Dir Daniel eigentlich 78 56 30 01 und nicht die sonst
> übliche DTU Addresse 78 56 34 12 ?

Ui, das ist ja Interessant! Ähm, hmm... auf der Seite 5 in diesem Thread 
war es noch richtig bei mir in der Log. Danke für denn Hinweis, ich 
werde mal drauf schauen. =)

Edit: Stimmt jetzt weiß ich es wieder! Hatte vorher das ganze in die 
'Home Assistant' eingebunden und zu Testzwecken habe ich den Wert 
geändert. Wahrscheinlich vor euphorie dann vergessen es wieder zu 
ändern. Hupps. ^^

[Herbert S. (herbert_s445)]

Hallo Stefan T.,

vielen Dank für die Hilfe. Habe das System mittlerweile am Laufen.  Ich 
hatte die Kabel für MISO und MOSI vertauscht.

LG

Herbert

[Daniel R. (daniel92)]

Hallo zusammen,
manchmal hilft es eine Nacht darüber zu schlafen. :)
Hab meinen Fehler gefunden... trotzdem keine Rückantwort.

WR= 74 40 33 29
DTU= 78 56 34 12
Command= 51
SubCommand= 5a 5a
UserData= 05   (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%)
CRC= 72

Poll inverter 116174403329
2022-06-22 14:58:37.633634 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72
2022-06-22 14:58:38.870592 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72
2022-06-22 14:58:40.107719 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72

Laut Excel Protokoll gab es denn Befehl zum auslesen der eingestellen 
Leistung. - Das kam dabei bei mir heraus:

2022-06-22 15:07:10.486528 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a 5a f7
2022-06-22 15:07:11.721448 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a 5a f7
2022-06-22 15:07:11.760218 Received 12 bytes channel 61: d1 74 40 33 29 74 40 33 29 5a 5a d1

Ich lese das hierbei so: CMD | WR | WR | 5a 5a | CRC?

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Laut Excel Protokoll gab es denn Befehl zum auslesen der eingestellen
> Leistung. - Das kam dabei bei mir heraus:
>
> [code]
> 2022-06-22 15:07:10.486528 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a
> 5a f7

Hallo Daniel
Nach meiner Lesung, es gibt keinen Befehl zum Auslesen der Limitierung.
Das command=0xD1 ist die Bestaetigung/Antwort auf 0x51.
Anfrage mit 0x51, Antwort drauf 0xD1, es wird immer bei der Antwort 
8.Bit gesetzt.

Also somit kannst du diesen Befehl nicht schicken:
> 2022-06-22 15:07:11.721448 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a
> 5a f7
Wenn du ihn schickst, bekommst einfach ein Echo.

[Ziyat T. (toe_c)]

Limitierung:

Es ist mir noch was aufgefallen:
Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
00 1284227201 0064 0C 2  D1 63707160 63707160 5A5AD1ADE9 1
51 cmd=D1

Die 0xD1 Antwort bekomme ich nur wenn ich das 0x51 über CH61 sende.
Ich muss es noch laengere Zeit beobachten....

[Daniel R. (daniel92)]

Ähm, ich schau mal ob es bei mir auch damit zusammen hängt mit CH61.

Ziyat T. schrieb:
> Nach meiner Lesung, es gibt keinen Befehl zum Auslesen der Limitierung.

Ahh glaube jetzt verstehe ich was das Protokoll in der Excel Tabelle 
meint, wenn ich denn Befehl abgeschickt wurde, bekommt man eine Quittung 
zurück. Die ist gleich wie der Befehl abgeschickt wurde, nur ohne 
SubCMD.


Edit: So, ich schicke es auf CH61 raus. Leider ohne erfolg. =(

Edit: Habe nun folgende CH durch probiert.
tx_channel_list = [3,23,40,61,75]

[Holger S. (skusi)]

Hallo zusammen,

ich habe das Platinen Layout nun um die Kondensator Möglichkeit und den 
Spannungsregler für den RF24 erweitert. Vielen Dank für die Hinweise und 
die Links zu den Erklärungen.

Bevor ich nun die Dingen fertigen lasse, macht mir noch Sorge das mein 
Prototype den ich auf einem Breadboard aufgebaut habe sehr häufig neu 
bootet. Auch nachdem ich nun den Spannungsregler und den Elko 100uF 
nachgerüstet habe schafft der Wemos keine langen UpTimes. Das längste 
waren so ca 6 Stunden.

Spannungsversorgung ist derzeit noch ein USB Netzteil

Liegt das an der Breadboard Verkabelung ?
Wie sind Eure Erfahrungen mit der UpTime ?

Glücklicherweise gehen ja bei einem reboot die Werte nicht verloren, 
aber das ja auch nicht so bleiben.

Sonst läuft alles recht reibungslos. Ich habe nur 3 fails bei meinen 3 
HM-300 Invertern. Diese kommen immer beim Booten zu Stande wenn die 
ersten Abfragen in lehre gehen.

[Stefan R. (rossiman)]

Hallo Leute,
beeindruckend was ihr hier macht und schon erreicht habt. Ich verfolge 
diesen Thread schon seit Beginn.
Nun habe ich mir das ahoy 0.4.19 bi binary auf einen ESP8266 geflashed. 
Zusammen mit einem NRF24L01+ Long Range mit Antenne hat das sofort 
funktioniert und läuft stabil. Vielen Dank an Euch.

Ich habe zwei HM-600 mit jeweils 2 PV Module und einen HM-300, den ich 
für einen Pufferspeicher einsetzen möchte. Derzeit verwende ich die 
Batterie meines Elektrorollers. Eine Leistungsbegrenzung des HM-300 wäre 
dafür perfekt.

Ich arbeite viel mit ESP8266 und Raspberry aber nur low-code. (ESPEasy, 
Tasmota, Node Red, FHEM, ..)

Wäre es möglich eine Version zu bauen, die über MQTT Raw Daten an die 
Wechselrichter sendet und empfängt? Ich könnte mich dann beim Testen 
beteiligen.

Grüße, Stefan

[Daniel M. (daniel_m821)]

Habe jetzt für den MI/TSUN das ganze soweit, dass ich:
- alle Pakete sehe
- immer wieder, noch unzyklisch, requests sende
- die Fehlermeldungen reduziert habe (wie auch immer das passiert ist)
- einen Teil der Payload des Inverter in die Payload übertragen bekomme
- den Teil der Payload angezeigt bekomme

Payload Inverter:

Received 18 bytes channel 75: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 
Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 44 00 15 09 52 13 8A 02 A0 07 DD 01 A5 DF 

Received 18 bytes channel 61: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B 
Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 3E 00 15 09 52 13 8A 02 9C 08 51 01 A5 02

Payload zusammengebaut:

Payload (32): 00 03 00 00 00 00 00 00 8B 01 3E 00 15 09 52 13 8A 00 03 00 00 00 00 00 00 91 01 44 00 15 09 52

Decode (auf Konsole):

17:34:13.185 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:13.185 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:13.185 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:13.185 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:13.185 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:13.219 -> I: Vordach/ch0/Freq: 50.010 Hz
17:34:14.222 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:14.222 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:14.222 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:14.222 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:14.222 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:14.222 -> I: Vordach/ch0/Freq: 50.010 Hz
17:34:15.193 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:15.193 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:15.193 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:15.193 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:15.193 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:15.193 -> I: Vordach/ch0/Freq: 50.010 Hz
17:34:16.227 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:16.227 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:16.227 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:16.227 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:16.227 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:16.227 -> I: Vordach/ch0/Freq: 50.010 Hz

hmDefines enum:

enum {INV_TYPE_1CH = 0, INV_TYPE_2CH, INV_TYPE_4CH, MI_INV_TYPE_1CH, MI_INV_TYPE_2CH, MI_INV_TYPE_4CH};

hmDefines Werte:

//MI-Version
    { FLD_UDC, UNIT_V,   CH1, 9, 2, 10   },
    { FLD_IDC, UNIT_A,   CH1, 11, 2, 10   },
    { FLD_UAC, UNIT_V,   CH1, 13, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH1, 15, 2, 100  },
    { FLD_PAC, UNIT_W,   CH1, 17, 2, 10   },
    { FLD_YD,  UNIT_WH,  CH1, 19, 2, 1    },
    { FLD_T,   UNIT_C,   CH1, 21, 2, 10   },
    //{ FLD_YT,  UNIT_KWH, CH1, 24, 0, 1    },
    { FLD_IRR, UNIT_PCT, CH1, CALC_IRR_CH, CH1, CMD_CALC },

    { FLD_UDC, UNIT_V,   CH2, 34, 2, 10   },
    { FLD_IDC, UNIT_A,   CH2, 36, 2, 10   },
    { FLD_UAC, UNIT_V,   CH2, 38, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH2, 40, 2, 100  },
    { FLD_PAC, UNIT_W,   CH2, 42, 2, 10   },
    { FLD_YD,  UNIT_WH,  CH2, 44, 2, 1    },
    { FLD_T,   UNIT_C,   CH2, 46, 2, 10   },
//    { FLD_YT,  UNIT_KWH, CH1, 24, 0, 1    },
    { FLD_IRR, UNIT_PCT, CH2, CALC_IRR_CH, CH2, CMD_CALC },

//    { FLD_UAC, UNIT_V,   CH0, 26, 2, 10   },
//    { FLD_IAC, UNIT_A,   CH0, 34, 2, 100  },
    { FLD_PAC, UNIT_W,   CH0, 17, 2, 10   },
    { FLD_T,   UNIT_C,   CH0, 21, 2, 10   },
    { FLD_PAC, UNIT_W,   CH0, 42, 2, 10   },
    { FLD_T,   UNIT_C,   CH0, 36, 2, 10   },
    { FLD_UAC, UNIT_V,   CH0, 13, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH0, 15, 2, 100  }

Ich habe die Werte sowohl in einem eigenen Abschnitt als auch im 2-Kanal 
HM drin und wechsle die SN zwischen 1041 und 1141.

Die Erkennung im Webinterface für 10xx funktioniert mit meiner 
Modifikation leider nicht, mittlerweile bekomme ich auf allen 3 
möglichen Einträgen 4 Kanäle angezeigt, hier schaue ich noch.

Die Payload wird nicht so zusammengebaut, wie ich ich es erwartet habe, 
in den meissten Fällen kriege ich entweder die Event-Daten oder die 
Leistungsdaten und bei denen wird jedoch noch nach 3-4 Werten 
abgeschnitten.
Der erste Teil kommt meißt mit einer Länge 7 (statt 9) rein, der 2. wird 
mit 3 Werten angehängt, es fehlt ein Stück:

Received 18 bytes channel 75: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B 

Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 38 00 2C 09 3C 13 88 05 37 08 18 01 C0 D1 

Payload (7): 00 03 00 00 00 00 00 
Payload (15): 00 03 00 00 00 00 00 00 8B 01 38 00 2C 09 3C 
Payload (24): 00 03 00 00 00 00 00 00 8B 01 38 00 2B 09 3E 13 88 00 03 00 00 00 00 00

Zwischendurch klappt das auch mit dem 2. Kanal, das ist allerdings eher 
Glückssache.
Angezeigt/Dekodiert wird nur auf Kanal 1, egal welche Werte kommen.

Auswertung:

if(0 != len) {
                     Inverter<> *iv = mSys->findInverter(&p->packet[1]);
                     if(NULL != iv) {
                        uint8_t *pid = &p->packet[0]; //9
                         if(*pid == 0x88) { // A Event
                            DPRINTLN(DBG_INFO, F("A Event"));
                             memcpy(mPayload[iv->id].data[0], &p->packet[9], len-9);
                             //DBGPRINT(String('mPayload[iv->id].data[1]', HEX) + String("\n"));
                             mPayload[iv->id].len[0] = len-9; 
                         }
                         if(*pid == 0x89) { // A Data
                            DPRINTLN(DBG_INFO, F("A DATA"));
                             memcpy(mPayload[iv->id].data[1], &p->packet[9], len-16);
                             //DBGPRINT(String('mPayload[iv->id].data[0]', HEX) + String("\n"));
                             mPayload[iv->id].len[1] = len-16;
                         }
                         if(*pid == 0x91) { // B Event (or Data ?)
                            DPRINTLN(DBG_INFO, F("B DATA"));
                             memcpy(mPayload[iv->id].data[3], &p->packet[9], len-16);
                             mPayload[iv->id].len[3] = len-16;
                         }
                         if(*pid == 0x92) { // B Data (or Event ?)
                            DPRINTLN(DBG_INFO, F("B EVENT"));
                             memcpy(mPayload[iv->id].data[2], &p->packet[9], len-9);
                             mPayload[iv->id].len[2] = len-9;
                         }

                         if( (*pid == 0x88) || (*pid == 0x89) || (*pid == 0x91) || (*pid == 0x92) ) {
                              if((*pid == 0x88) && (mPayload[iv->id].maxPackId < 1)) { //1
                                 mPayload[iv->id].maxPackId = 1;
                                 mLastPacketId = *pid;
                              }
                              if((*pid == 0x89) && (mPayload[iv->id].maxPackId < 2)) { //3
                                mPayload[iv->id].maxPackId = 2;
                               // if(*pid == 0x89)
                                     mLastPacketId = *pid;
                              }
                              if((*pid == 0x91) && (mPayload[iv->id].maxPackId < 3)) { //2
                                mPayload[iv->id].maxPackId = 3;
                               // if(*pid == 0x91)
                                     mLastPacketId = *pid;
                              }
                              if((*pid == 0x92) && (mPayload[iv->id].maxPackId < 4)) { //4
                                mPayload[iv->id].maxPackId = 4;
                                mLastPacketId = *pid;
                                 }
                              }
                        } //iv
                    } //0 = len
[c/]

Die Antworten sind:
0x88 - A Event
0x89 - A Data
0x91 - B DATA
0x92 - B Event

Die Längen 9 bzw. 16 sind die gesamte Payload, die ich bekomme. Irgendwo sind für die Gesamtleistung noch ein High- und Low-bit versteckt, ich nehme an, das sind die letzten beiden, die mitgesendet werden. Mit der Bitverschiebung werde ich mich aber erstmal nicht beschäftigen. 

Den Invertertype in hmSystem.h habe ich etwas erweitert:
[c]
if(p->serial.b[5] == 0x11) {
                switch(p->serial.b[4]) {
                    case 0x21: p->type = INV_TYPE_1CH; break;
                    case 0x41: p->type = INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("HM 2 Channel")); break;
                    case 0x61: p->type = INV_TYPE_4CH; break;
                    default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 11") + String(p->serial.b[4], HEX)); break;
                }
            }
            else if(p->serial.b[5] == 0x10) {
                switch(p->serial.b[4]) {
                    case 0x21: p->type = MI_INV_TYPE_1CH; break;
                    case 0x41: p->type = MI_INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("MI 2 Channel")); break;
                    case 0x61: p->type = MI_INV_TYPE_4CH; break;
                    default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 10") + String(p->serial.b[4], HEX)); break;
                }
            }
            else
                DPRINTLN(DBG_ERROR, F("inverter type can't be detected!"));

Die Debug-Info taucht nur nirgends auf der Konsole auf, in debug.h ist 
debug als Level eingestellt. Ich weiß also nicht, ob der Part wirklich 
greift.

Am meissten Kopfschmerzen macht mir aktuell die unvollständige Payload 
und das nicht richtige dekodieren der Werte.
Ich habe zwischenzeitlich mit den maxPackId und mit den *pid 
verschiedene Varianten ausprobiert, keine führte zum Erfolg.

Was habe ich übersehen?

edit: Payload zusammenhängende Werte im Log gefunden

[Esp_loeter (Gast)]

Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit 
Trigger auf Spg.Abfall. —-> die 3.3V sind stabil

[Daniel R. (daniel92)]

Hallo Daniel M.,

erstmal Respekt! Schön das wir alle zusammen irgendwie voran kommen. :)
Bevor ich es vergesse, wäre es sinnvoll je nach Hersteller eine eigene 
Klasse zu erstellen. Oder?

- TSUN
- Hoymiles (MI,HM,...)

Für Arduino/ESP könnte es später etwas knapp werden mit dem Speicher, 
oder was meint Ihr dazu?


Ich schau mir mal dein Code an, da ich selbst kein TSUN habe kann ich 
nichts nachprüfen. Aber vielleicht kommt jemand später dazu. =)

@grindylow: Ich bin mir nicht 100% sicher, aber wäre es möglich im 
Github unter Project ein Backlog anzulegen damit man weiß was noch alles 
zu machen ist? - So kann man das ganze bisschen sauber führen. 8-)

z.B.: https://github.com/users/DanielR92/projects/2/views/1

Gruß Daniel

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> erstmal Respekt! Schön das wir alle zusammen irgendwie voran kommen. :)
> Bevor ich es vergesse, wäre es sinnvoll je nach Hersteller eine eigene
> Classe zu erstellen. Oder?
>
> - TSUN
> - Hoymiles (MI,HM,...)

Ja, zieht sich mit den Außenseitern und Altmodellen halt wie Kaugummi, 
aber solang es Spaß macht :)

Das mit den eigenen Klassen erstellem ist auf jeden Fall nötig. Wenn ich 
was lauffähiges habe, kann man das theoretisch vereinzeln, bis dahin ist 
es für mich einfacher.
Ich bin kein Softwareentwickler und weiß nicht, was ich tue, also 
versuchen zu verstehen, modifizieren und schauen, was passiert (der 
Compiler hasst mich mittlerweile).

>
> Für Arduino/ESP könnte es später etwas knapp werden mit dem Speicher,
> oder was meint Ihr dazu?

Jep, das wird definitiv eng.

>
> Ich schau mir mal dein Code an, da ich selbst kein TSUN habe kann ich
> nichts nachprüfen. Aber vielleicht kommt jemand später dazu. =)

TSUN/MI sind Baugleich in der Kommunikation.
Falls du (oder wer anderes) willst, kannst du auch per Anydesk direkt 
bei mir schauen. Macht das Debuging wahrscheinlich einfacher.

Ein Kollege hat sich jetzt einen HM1500 bestellt, an dem werd ich Ahoy 
ausprobieren :)

[Daniel R. (daniel92)]

Hi Daniel M.,

habe selbst ein HM-1500. Es läuft schon ziemlich stabil bei mir. Arbeite 
hier direkt mit einem Raspberry statt ESP. Ich kann schnell denn Code 
ändern ohne immer alles neu zu kompilieren und zu warten bis es auf dem 
ESP läuft. :)

Ich hatte schon früher die Idee mit discord, habe es aber nicht 
angesprochen. Da jeder auch seine "Freizeit" hat und man eher selten 
wahrscheinlich zusammen kommt um gemeinsam dran zu arbeiten.

[Holger S. (skusi)]

So, hab mal den Abend damit verbracht mein Layout als Einzelstück zu 
fertigen. Dabei hab ich dann auch den Tipp mit dem Abschirmen des RF 
Moduls umgesetzt. Mit einem Schrumpfschlauch und etwas Alu Klebeband 
ging das ganz gut. Morgen werde das Ganze in das Gehäuse einbauen und 
die Version gegen meinen Breadboard Aufbau tauschen. Mal sehen wie sich 
das dann mit den Reboots verändert.

Hier mal ein paar Impressionen:

[Richard K. (laserrichi)]

Esp_loeter schrieb:
> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit
> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil

das klingt ja gut, auch mit max. Sendeleistung ?

wieviel mV hattest du den Trigger ?

[ESP_loeter (Gast)]

Richard K. schrieb:
> Esp_loeter schrieb:
>
>> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
>> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit
>> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil
>
> das klingt ja gut, auch mit max. Sendeleistung ?
> wieviel mV hattest du den Trigger ?

Trigger stand auf 3.2V, Sendeleistung auf Max.

[Daniel R. (daniel92)]

@skusi: Nicht schlecht. :)

[Ziyat T. (toe_c)]

MI-1500 Limitierung:

Limitierung mit absolut Wattzahl funktioniert auch, hier z.B. 500W 
Limit:

Send... CH61 51|63707160|72228412|5A5A|64|1388|6A
Command|WR|DTU|SubCommand|100%|500W|CRC

510.9W PV:2 123.2W 42.9V 2.9A 304.0Wh 227.3V 50.0Hz 52.5C  Sts:3 FCnt:0
510.9W PV:3 253.4W 39.2V 6.7A 474.0Wh 226.7V 50.0Hz 52.4C  Sts:3 FCnt:0
510.9W PV:4 0.5W 39.2V 0.0A 2.0Wh 226.7V 50.0Hz 52.4C  Sts:3 FCnt:0
511.0W PV:1 133.9W 42.9V 3.2A 304.0Wh 226.2V 50.0Hz 52.5C  Sts:3 FCnt:0

[Daniel R. (daniel92)]

Hi Ziyat T.,

das ist sehr cool. :D
Natührlich super für die MI-Nutzer da hier die Dokumente vorhanden sind.

Ich nutze ein HM, da hat es leider nicht funktioniert.

Wobei, ich glaube ich kenne nun mein Fehler!
Die Watt anzahl muss noch mit 10 multipliziert werden. Korrekt?
Zusätzlich frage ich mich, die Prozent Angabe die sagt eigentlich was 
aus?
Ich dachte hier trägt man von zb. 1500W nur 10% ein um dann 150W zu 
erhalten.

Bei dir steht es weitherhin auf 100%, jedoch im nächste Byte 500W.
Ich bin da etwas verwirrt.^^

Das heißt ich müsste folgendes senden:
value = 10(%) * 10 => 100 = 0x00 0x64
value = 50(%) * 10 => 500 = 0x01 0xF4
value = 75(%) * 10 => 750 = 0x02 0xEE
...

Transmit 14 |  [51] [74 40 33 29] [78 56 34 12] [5a 5a] [xy%] [val|val] 
CRC

Kann das jemand von HM-Nutzer bestätigen (bin aktuell nicht Zuhause)?


Danke für die Infos vorab! :)

[Günter H. (gnter_h534)]

Esp_loeter schrieb:
> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit
> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil

Gut, dass das einmal gemessen wurde.

Leider gibt es nicht den Wemos D1 mini. Siehe z. B. :
https://github.com/bbqkees/Wemos-the-Clone-Wars/blob/master/README.md

Zum Thema "reboot": Es gibt Hinweise, dass bei manchen Clones der 
verbaute Spannungsregler der Grund für häufiges Rebooten ist.
(Quelle: https://www.letscontrolit.com/forum/viewtopic.php?t=6603)

Das könnte das unterschiedliche Verhalten in Bezug auf Rebooten bei den 
verschiedenen Usern sein.

@Holger S.
Sehr kompaktes Layout.
Einige Anmerkungen:
- Den 3.3V-Spannungsregler weiter vom AC-Eingang weg platzieren, der 
Abstand zwischen AC-Eingang und der übrigen Schaltung erscheint mir sehr 
klein zu sein. Besonders dann, wenn eine externe Antenne geplant ist.
- Datenblatt HiLink_3W_Power_Supply Seiten 7-8, Kap. 8 "Typical 
Application Circuit". Dort ist ausgeführt: "Fuses and varistors are the 
basic protection circuits (required)" sowie "For certification, safety 
capacitors and common mode inductors cannot be omitted". (Danke an den 
Google-Übersetzter)

[Ziyat T. (toe_c)]

Hallo Daniel R.

Variante mit %:
[51] [74 40 33 29] [78 56 34 12] [5a 5a] [xy%] CRC

Variante mit abs(Watt*10, 1 dec):
[51] [74 40 33 29] [78 56 34 12] [5a 5a] [100%] [val=P-lo|val=P-hi] CRC
Ich glaube hier wird 100% ignoriert.

hier 1388=500,0W
Send... CH61 51|63707160|72228412|5A5A|64|1388|6A

Das mit der Prozentzahl ist sehr mühsam.
Ich steuere meine DTU-Pro über Modbus(zero export), dort geht es nur mit 
Prozent.
Mann muss die angeschlossene PVs Total P als 100% betrachten.
Ich habe den MI-1500 aber nur 3PVs mit je 450W brutto, total bekomme ich 
(gemessen mit Verlust) etwa 1100W unter "meine" Sonne am Sommer/Mittag. 
Produktion ist nicht linear, darum habe ich eine Tabelle:
100%  1100
90%  1050
80%  996
70%  900
60%  820
50%  750
45%  700
40%  610
30%  460
25%  380
20%  310
17%  261
15%  230
13%  200
12%  182
11%  170

[Ziyat T. (toe_c)]

@Günter H.
@Holger S.
@Esp_loeter
Ich habe auch mal mit Wemos1 und NRF24L01 + PA + LNA/Antenne probiert.
Bei 3 versch. nrf24 Modulen, konnte ich nur mit einem senden und 
empfangen, die anderen 2 nur empfangen? Ich dachte zuerst an 
Spannungsproblem.
Allerdings, die 2 Module hatte ich lange mit RF24_PA_MAX betrieben, 
danach ging auch das ESP kaputt..

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Mann muss die angeschlossene PVs Total P als 100% betrachten.

Vielen Dank für die Infos.
Ok das ist auch sehr Interessant.

Ich würde sagen, jetzt kann es langsam dran gehen den ganzen Code sauber 
zu machen und die ersten Klassen zu generieren? :)

Um für die User mit ESP/Arduino speicher zu sparen, wäre die Frage ob 
man alle Kombination (HM/MI/TSUN/...) unter einem Hut bringen kann. Oder 
ob es sogar Notwendig ist diese zu splitten?

Ich hoffe man bekommt alles unter. Wobei ich denke hier muss man das 
ganze anders heran gehen.

Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es 
sich handelt (Marke, Typ?)

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ich würde sagen, jetzt kann es langsam dran gehen den ganzen Code sauber
> zu machen und die ersten Klassen zu generieren? :)

Da bin ich gespannt;-)
HM und MI haben völlig andere Tx/Rx-Message Struktur und Polling, so wie 
ich beurteilen kann, bisherige SW sind alle auf HM zugeschnitten. Habe 
mal versuch den MI in die HM-SW zu integrieren, geht nicht so einfach, 
ich konnte nicht, habe aufgegeben, und das ist echt schade.

[Daniel R. (daniel92)]

Ich meine das sollten wir hinbekommen.
Wäre es möglich das du deine Änderung als MI-Version irgendwie hier 
bereitstellen könntest?

Ich bin nähmlich dabei erstmal ein UML aufzustellen. Finde ich erstmal 
einfacher, damit jeder weiß wie es später aussehen könnte. :)

Was meint ihr dazu?

[Günter H. (gnter_h534)]

Daniel R. schrieb:
> Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es
> sich handelt (Marke, Typ?)

Hier

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

wurden vor zwei Monaten Typen und Seriennummern zusammengestellt.

[Daniel R. (daniel92)]

Danke.

Ich hab zwecks UML angefangen, aber konnte kein gutes Tool/Designer 
findet indem man das ganze schön Darstellen kann.

Hab mal ganz grob denn Anfang gemacht. Ich schau mir gerade von Gitee 
noch deren Klassen durch wie Sie das gelöst haben.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ich meine das sollten wir hinbekommen.
> Wäre es möglich das du deine Änderung als MI-Version irgendwie hier
> bereitstellen könntest?

Deise SW ist orig. vom Hubi, ich habe für den MI-1500 abgaendert und als 
Arbeits-/Debug-SW zu verstehen.
Nur für ArduinoUno.

[Thomas B. (tbnobody)]

Hallo zusammen,

ich habe auch begonnen Firmware für den ESP32 zu schreiben.
Es ist in der aktuellen Form schon komplett funktionsfähig und läuft 
stabil (NodeMCU32 + NRF24 mit zusätzlichem 10uF Kondensator).

Vielleicht kann man da auch Anregungen für eine Klassenstruktur finden. 
Ich habe versucht die Hoymiles Implementierung eigenständig als Library 
zu gestalten.
Die Web GUI ist in Vue.js geschrieben und wird zur Firmware Binary 
hinzugelinkt. Bei dieser aufwändigeren Projektstruktur und auch zwecks 
Dependency Verwaltung eignet sich die Arduino IDE hiefür natürlich nicht 
mehr. Das Projekt basiert auf PlatformIO.

Es gibt noch etliche Stellen die nicht perfekt sind, einer 
Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte 
erstmal was lauffähiges haben.
Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU
Im docs Ordner gibt es auch ein paar Screenshots der WebGUI.

In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking 
Changes" geben was die Namen der MqTT Topics anbelangt.
Die Payload Erzeugung habe ich auch schon in die Inverter Klassen 
verlegt. Dies ist jedoch mangels Test noch nicht commited.

Über Anregungen und/oder PRs würde ich mich freuen.

Grüße
Thomas

[John P. (brushlesspower)]

Günter H. schrieb:
> Daniel R. schrieb:
>> Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es
>> sich handelt (Marke, Typ?)
>
> Hier
>
> https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx
>
> wurden vor zwei Monaten Typen und Seriennummern zusammengestellt.

Wenn man mal quer ließt:

HM beginnt mit 11
MI beginnt mit 10

250 Watt -> xx20
300 bis 400 Watt  -> xx21
500 Watt -> xx40
600 bis 800 Watt -> xx41
1000 Watt -> xx60
1200 bis 1500 Watt -> xx61

[Stefan R. (rossiman)]

Hallo Thomas,
stark, dass du das angehst. Sobald du jemanden zum Testen benötigst kann 
ich helfen. Ich habe einen HM300 und zwei HM600 im Einsatz. Die Ahoy 
0.4.19 funktioniert bei mir 100% stabil ohne Kondensator.
Grüße, Stefan

[John P. (brushlesspower)]

Hallo Thomas,

habe dein ESP32 Projekt ausprobiert.

Soweit hat alles funktioniert, vielen Dank. Dann brauche ich keinen 
ESP8266 bestellen sondern kann einen der vielen ESP32 nehmen.

Leider habe ich grad keinen WR hier, daher kann ich nicht vollständig 
testen.

[Daniel R. (daniel92)]

Hallo Thomas,

ja das sieht schonmal stark aus. =)
Ich bin aktuell nicht Zuhause. Habe zum testen ein HM-1500.

Würde es mir anschauen, aufjedenfall wäre es Klasse wenn man alle 
Hoymiles + TSUN in einem Paket bekommt und somit eine breite Maße 
abdecken kann.

Ich weiß nicht wie groß der Flash ist, aber meine das der ESP32 größer 
ist. Daher sollte das passen oder?

Jetzt kommt aber die Master frage: zwei Githubs zu pflegen macht kein 
Sinn, beide sind soweit ich es sehe (Ahoy habe ich selbst schon 
getestet) soweit ganz gut. Nur welche sollte man für die Zukunft 
pflegen?

Ahoy ist soweit ich weiß sehr aktiv und hat aktuell ein großen Andrang.
Was meint ihr?

Gruß

[Stefan R. (rossiman)]

Nur ein Projekt würde schon besser sein, aus meiner Sicht. Ich würde 
mich über die Implementierung der Leistungsbegrenzung mittels MQTT 
freuen. Wenn der ESP32 besser geeigne ist, dann werde ich mir einen 
kaufen. Die GUIs von Thomas sehen schon gut und konsistent aus. 
Allerdings benötigt der ESP32 3 mal so viel Strom als der ESP8266.
Vielleicht könnten sich die Hauptentwickler dazu abstimmen.
Stefan

[Daniel R. (daniel92)]

Hallo Stefan,

jetzt kann man das noch nicht sagen welches der bessere ist.
Ich glaube es wird sich mit der Zeit zeigen.

Je nach dem wie wir alle zusammen das Projekt programmieren (auf 
effizient getrimmt) desto weniger Speicher wird dafür benötigt.

Auch hier wäre es eventuell Sinnvoll vielleicht auf einige Libarys die 
alles aufblähen raus zu schmeisen. Oder?

Ich behaupte jetzt erstmal das man am ESP8266 bleiben kann. ;)

[Thomas K. (Gast)]

Hallo alle zusammen,

ich verfolge die aktivitäten hier schon seit einer Woche.
Hut ab vor den hier erbrachten Leistungen.

ich habe beide Programme (hubi und Ahoi) mit einem ESP8266 am laufen.
habe lediglich aus früheren Versuchen einen 10uF Kondensator an dem NRF 
Modul.

Diese hier beschriebenen Abstürze bzw. Reboots des ESP konnte ich bis 
jetzt noch nicht beobachten. allerdings habe ich in der Vergangenheit 
schon öfter feststellen müssen, das ein "Handyladegerät" ungeeignet ist 
um  Funkgeschichten mit Strom zu versorgen.
Bei mir hängt das meistens zum testen am Laptop oder einer ähnlichen 
Stromquelle bei der der PE angeschlossen ist, wie weiter oben schon 
erläutert.

ich bin auch brennend an einer Lösung zur Leistungsbegrenzung  des 
HM-600 interresiert.

ich habe die ganze Zeit vergeblich versucht, auf der DC Seite den Strom 
mit einem PWM DC-Wandler zu begrenzen. das funktioniert aber nicht so 
toll, da der MPPT- Tracker mit dem Steilen abfallen der Spannung nicht 
zurecht kommt.

[Richard K. (laserrichi)]

Thomas K. schrieb:
> Diese hier beschriebenen Abstürze bzw. Reboots des ESP konnte ich bis
> jetzt noch nicht beobachten. allerdings habe ich in der Vergangenheit
> schon öfter feststellen müssen, das ein "Handyladegerät" ungeeignet ist
> um  Funkgeschichten mit Strom zu versorgen.
> Bei mir hängt das meistens zum testen am Laptop oder einer ähnlichen
> Stromquelle bei der der PE angeschlossen ist, wie weiter oben schon

So toll Schaltnetzteile auch sind vom Wirkungsgrad, haben sie eben auch 
durch die Taktung von einigen 10khz bis einigen 100khz leider auch viel 
Schmutz auf den Leitungen.
Oberwellen, Interferenzen usw... alles wird getaktet und das sorgt für 
Probleme.

Ich hatte einen wemos d1 mini versucht mit einem Blitzsensor as3935 zu 
betreiben und bin kläglich gescheitert, der ESP hatte einfach zu sehr 
gestört und mit noch so gut gefilterten Spannungsversorgungen und 
Abschirmungen ging es einfach nicht. Denn die Blitzerkennung läuft mit 
500khz Band und Ferritkern Spule als Antenne.

Die Abschirmung die skusi hier auf seinen Bildern gezeigt hat finde ich 
sehr gut, ich werde das auch mal umsetzen um zu sehen ob ich dann auch 
mit max. Power senden kann, denn das geht bei mir ungeschirmt nicht ohne 
massenhafte Funkfehler.

[Richard K. (laserrichi)]

Nachtrag:

die Abschirmungsmethode die Holger S. (skusi) hier auf seinen Fotos 
zeigt ist perfekt !!!
Ich habe es soeben umgesetzt und kann von min low high bis max mit allen 
Einstellungen sauber Senden und Empfangen, auch ohne extra Kondensator 
und Versorgungsspannung.

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> Danke.
>
> Ich hab zwecks UML angefangen, aber konnte kein gutes Tool/Designer
> findet indem man das ganze schön Darstellen kann.
>
> Hab mal ganz grob denn Anfang gemacht. Ich schau mir gerade von Gitee
> noch deren Klassen durch wie Sie das gelöst haben.

Hi,

das ganze ist soweit gut, allerdings brauchst du für TSUN nichts extra 
machen, TSUN ist ein umgelabelter MI. China standart Copy+Paste. Du 
kannst also MI/TSUN als Klasse machen :)

[Ralf B. (ralf_b210)]

Moin,

hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
     Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird 
verschenkt)
     Da sollte man seine Energie inwestieren warum das so  ist.
     Ist ein alter Feraris verbaut dreht der rückwärts (doppelt 
gespart).

[Thomas K. (Gast)]

Hallo Ralf

das problem ist, dass bald keiner mehr einen "alten" Zähler hat.
Der überschüssige Strom, der tagsüber (für lau) ins Netz gespeist würde, 
lässt sich aber auch bequem in einem Akku Speichern und dann findet 
dieser z.B. nachts noch seine Verwendung, um die Grundlast zu decken.

Bei mir zum Beispiel ist die Grundlast den ganzen Tag irgendwo zwischen 
150 und 230 Watt.

Ich habe Aktuell 4 Solarpanels mit mit je 370Watt --> also quasi 1480Wp
diese Energie speise ich in einen LiFePo4 Akku mit 4,4kWh Kapazität ein.
Parallel dazu, soll ein Wechselrichter davon die ca.200W für die 
Grundlast einspeisen.

Der Rest wird in den Akkus für die Nacht gespeichert.
Wenn ich mich nicht verkalkuliert habe, müsste der Akku dann die 16 
Stunden überbrücken können in denen die Sonne nicht scheint.

Um die Energie nicht zu Verschwenden (bzw. dem Netzbetreiber zu 
schenken) wollte ich meinen Shelly 3EM auslesen und den Wechselrichter 
auf
NULL EINSPEISUNG einregeln.

[Ben (Gast)]

Hallo Zusammen,

Ich bin neu im Club und habe heute meinen HM-600 erhalten. Er hängt 
aktuell noch an eine Fritz Steckdose, deshalb weiß ich, dass auch 
fleißig produziert wird.
Ich habe mir auch bereits einen Wemos D1 Mini mit NRF… geholt, verkabelt 
und die Software aufgespielt. WLAN ist verbunden, MQTT connected und der 
Inverter ist ebenfalls verbunden.
Aber jetzt gehen die Probleme los:

1. Inverter ‚Hm600‘ is availabe and is not producing. -> Tut er aber 
nachweisbar.

2. MQTT Probleme
New connection from das.ist.meine.ip on port 1883
New client connected from das.ist.meine.ip as AHOY-DTU (c1, k15, 
u‘mqtt‘).
Client AHOY-DTU has exceeded timeout, disconnecting

3. Die GUI auf dem Wemos D1 ist extrem langsam.

Hat jemand ein paar Tipps für mich?

AHOY Version 0.4.19
NRF24L01+ Platine mit externer Antenne
MQTT Version 1.5.7 (läuft seit Jahren problemlos auf einem RPI)

Viele Grüße
Ben

[Petra R. (petra-kathi)]

Hallo Thomas,

> Der überschüssige Strom, der tagsüber (für lau) ins Netz gespeist würde,
> lässt sich aber auch bequem in einem Akku Speichern und dann findet
> dieser z.B. nachts noch seine Verwendung, um die Grundlast zu decken.

Hier möchte ich mich mal kurz einklinken, weil ich das mittelfristig 
auch gerne so machen würde. Allerdings fehlt mir ein wenig die 
Vorstellung, wie das regelungstechnisch ablaufen soll und wie das (um 
wieder zum hiesigen Thema zurückzukommen) über die Ansteuerung eines 
Wechselrichters (hier: HM-1500 mit 3 Panels) zu organisieren wäre?

Konkret: Wie müsste die Ansteuerung erfolgen, wenn bei überschüssiger 
Produktion der Akku geladen werden soll? Ich begreife noch nicht, wie 
der Wechselrichter definiert, wohin der produzierte Strom denn nun 
gehen soll. Bzw., wie der Akku merken soll, dass er bitteschön gerade 
laden soll?

Wenn das hier am Thema vorbei sein sollte: Gerne auch Erhellung per 
Linknennung!  ;-)

Hier läuft seit ca. 2 Monaten eine leicht modifizierte Version eines 
älteren Ahoy.py auf 'nem Raspi, die auch noch nie Probleme mit dem 
Strombezug des NRF24+ hatte. Allerdings reicht bei mir die schwächste 
Sendeleistung aus.

Tschüssi,
Petra

[Ziyat T. (toe_c)]

Ralf B. schrieb:
> Moin,
>
> hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
>      Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird
> verschenkt)
>      Da sollte man seine Energie inwestieren warum das so  ist.
>      Ist ein alter Feraris verbaut dreht der rückwärts (doppelt
> gespart).

Hallo
Weil es nicht überall auf dieser Welt die Rückspeisung so handgehabt 
wird wie in Deutschland, darum darf/muss ich NULL einspeisen.

[Daniel R. (daniel92)]

Daniel M. schrieb:
> China standart Copy+Paste

Stimmt da hast du recht. :)

[Ziyat T. (toe_c)]

Petra R. schrieb:
> Wenn das hier am Thema vorbei sein sollte: Gerne auch Erhellung per
> Linknennung!  ;-)
>
Bitte nicht hier ;-)
Aber hier gibts tonnenweise
https://www.facebook.com/groups/170429543515117/

[Ziyat T. (toe_c)]

@Stefan R. (rossiman)
@Daniel R. (daniel92)
Bei dem Thema Wemos1/esp8266 ist mir das noch aufgefallen:
Wenn jemand den WR steuern möchte, muss man  die Leistung (+/-) beim 
Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein 
RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Wenn jemand den WR steuern möchte, muss man  die Leistung (+/-) beim
> Zaehler über Modbus abfragen

Naja kommt drauf an wie man das realisieren möchte.
Mir würde es reichen wenn man via MQTT das ganze realisieren. Da ich es 
via Raspberry nutze. Klar der Zähler ist auch via Modbus/S1 Angebunden. 
Denn würde ich jedoch auch direkt am Pi verbinden.

Wir wissen ja nicht wie die gegebenheiten sind. Ich behaupte mal das 
jeder ein Zähler direkt am UV(Unterverteiler) haben und von dort dann 
weiter verarbeiten. :)

> Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein
> RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.

NRF24 läuft doch über SPI und wenn man einen 'MAX3140' Wandler nutzt, 
kann man auch via SPI kommunizieren.  Somit fehlt uns kein Pin mehr. =)

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> Mir würde es reichen wenn man via MQTT das ganze realisieren. Da ich es
> via Raspberry nutze. Klar der Zähler ist auch via Modbus/S1 Angebunden.
> Denn würde ich jedoch auch direkt am Pi verbinden.
>
> Wir wissen ja nicht wie die gegebenheiten sind. Ich behaupte mal das
> jeder ein Zähler direkt am UV(Unterverteiler) haben und von dort dann
> weiter verarbeiten. :)

MQTT ist eine gute Idee. Modbus via einem weiteren Pfennig-Wemos mit 
RS458-Schnittstelle ist keine Raketenwissenschaft.
Ich hab z.B. SDM630 als zentralen Zähler direkt nach dem vom Versorger 
sowie für alle 3 Etagen einen extra, für Garage, Nebenanlagen und die 
Wallbox.
Insgesamt also 7 Stück, wo ich mit Modbus rankomme.

Hier ist es langfristig das Ziel, die Energieflüsse zu messen und 
Verbräuche zu erfassen.

Wäre später interessant, die abzufragenden Register (im Quellcode) 
konfigurieren zu können oder vllt verschiedene Profile für die gängigen 
Zähler/Messgeräte zu haben.

S1 kann man machen, finde ich aber zu ungenau. Wenn du es sowieso per 
Raspi hast, ist es kein Problem.

[Daniel R. (daniel92)]

S1 habe ich nur mit reingenommen, da es vielleicht jemand da draußen 
gibt der ein Zähler schon verbaut hat und nicht noch extra was 
Invenstieren möchte. :)

Die Register vom deinem Zähler sind im Datenblatt zu finden. :)
https://bg-etech.de/download/manual/SDM630Register1-5.pdf

daher kein Problem die Daten weiter zu vearbeiten.

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> S1 habe ich nur mit reingenommen, da es vielleicht jemand da draußen
> gibt der ein Zähler schon verbaut hat und nicht noch extra was
> Invenstieren möchte. :)

Verständlich, zumal die Zähler gerade schwierig zu bekommen sind.
S1 wäre aber, meiner Meinung nach, nur eine Zwischenlösung. Wer das 
macht wird früher oder später neugieriger werden. PV macht einfach 
süchtig.

> Die Register vom deinem Zähler sind im Datenblatt zu finden. :)
> https://bg-etech.de/download/manual/SDM630Register1-5.pdf
>
> daher kein Problem die Daten weiter zu vearbeiten.

Weiß ich :)
Es gibt noch andere Varianten von Janitza, Finder, Eltako, Victron und 
Co, die alle irgendwie anders belegt sind. Falls noch Platz im Code ist, 
könnte man hier für die üblichen Verdächtigen schon fertige Belegungen 
hinterlegen.

Meine 7 Stück wollen irgendwie nicht zusammen auf einer Leitung laufen, 
nach einer gewissen Zeit rebooten die und springen im Zählerstand ein 
Stück zurück, Eastron zuckt mit den Schultern und weiß nicht warum. Das 
war der Stand Ende 2019.
Genug OT :)

[RoHS-CE (Gast)]

WOW ... total fix eine EMV Prüfung erfolgreich bestanden ... und eine CE 
und RoHS Erklärung gibts bestimmt auch dazu

https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=17732479

https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-wechselrichter/2141424109-168-8859

[Ralf B. (ralf_b210)]

Ziyat T. schrieb:
> Ralf B. schrieb:
>> Moin,
>>
>> hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
>>      Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird
>> verschenkt)
>>      Da sollte man seine Energie inwestieren warum das so  ist.
>>      Ist ein alter Feraris verbaut dreht der rückwärts (doppelt
>> gespart).
>
> Hallo
> Weil es nicht überall auf dieser Welt die Rückspeisung so handgehabt
> wird wie in Deutschland, darum darf/muss ich NULL einspeisen.

Moin,
deshalb schrieb ich:
>>      Da sollte man seine Energie inwestieren warum das so  ist.

Ich bin absolut der Meinung das dieser Strom zu vergüten ist.

Die Nulleinspeisung für nen Akku zu nehmen ist eine schöne aber sehr 
teure Lösung. 2. WR und nen Lifopo4 mit 2,4 kW sind immo ca 2k€.
ob sich das rechnet ?

Btw
Ich selber habe 10 kWp und 14,5 kw Speicher im Keller.
Ist ein schönes Gefühl wenn der Strom von da kommt.

Die HM1200 die ich jetzt noch verbauen will sind für die SchattenPV.

[Lukas P. (lumapu)]

RoHS-CE schrieb:
> WOW ... total fix eine EMV Prüfung erfolgreich bestanden ... und eine CE
> und RoHS Erklärung gibts bestimmt auch dazu
> https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=17732479
> 
https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-wechselrichter/2141424109-168-8859

Leute vergesst den Gedanken mit Ahoy Geld zu verdienen! Die Lizenz 
erlaubt es nicht, dass Ahoy verkauft wird!
Lesen hilft und heulen wenn sich der Anwalt meldet geht gar nicht.

Ich finde es schei**e, dass sich hier irgendwelche ganz schlauen meinen 
es verkaufen zu müssen. Wir stecken echt viel Zeit rein und machen das 
als Community. Ich sehe das eher so: jeder steuert was bei und gemeinsam 
schaffen wir großes - für uns -

[isnoAhoy (Gast)]

Hallo Thomas B.,
habe mir mal Deinen Code angesehen und versucht die Bibliotheken für den 
Build mit dem ESP8266 auszutauschen. Ich strauchele an dem selben Punkt 
den wir auch schon umgekehrt festgestellt hatten:
* Beim ESP32 kann man ISR Routinen auch mit std::bind Klassen 
aufrufen/als Callback einbinden.
* Beim ESP8266 geht dies nur wenn die ISR Routine global als static void 
deklariert ist, also noch nicht als Methode einer Klasse.

Ansonsten ist der Code sehr übersichtlich und aufgeräumt. Hut ab / 
Chapeau!

Es dürfte dadurch vielleicht sogar etwas einfacher werden dies um die 
Inverter MI-/TSUN- zu erweitern.

Schwierigkeit bei beiden (Ahoy ESP8266 / OpenDTU ESP32) ist m.E. daß das 
Senden aktuell nur ein Kommando vorsieht. Bei MI-/TSUN- Wechselrichtern 
muß man aber alle vier Status/Data Pakete einzeln anfragen um die 
Informationen zu bekommen. Bei HM- Wechselrichtern geht das alles mit 
der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete 
sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen.

Auch gibt es bei MI-/TSUN- Wechselrichtern keine CRC-Modbus / CRC-16 
Prüfsumme innerhalb der Payload, es existiert nur die Paket-eigene CRC-8 
Prüfsumme.

Der Code dürfte m.E. auch nicht zu viel Speicher verbrauchen, ist ja 
alles im PROGMEM bzw. Flash memory abgelegt und davon hat selbst der 
ESP8266(-12E/F) mit 4M m.E. reichlich, zumindest für die 2x3 
Wechselrichter Modelle, die wir bisher kennen.

Speicher-intensiv wird höchstens, wenn geplant sein sollte Daten zum 
Tages-/Wochenverlauf mehrerer Wechselrichter direkt im lokalen 
Flash-Filesystem des ESP abzulegen. Das könnte mit den entsprechenden 
Schreiboperationen einer RoundRobinDB auch schnell zu Fehlern führen.

[Heinz R. (heijz)]

Thomas K. schrieb:
> Um die Energie nicht zu Verschwenden (bzw. dem Netzbetreiber zu
> schenken) wollte ich meinen Shelly 3EM auslesen und den Wechselrichter
> auf
> NULL EINSPEISUNG einregeln.

was ein Unsinn, dann ist sie doch genau so verschwendet?

Du erzeugst sie halt nicht mehr, wirfst sie weg statt sie dem 
Netzbetreiber zu schenken
Selber hast Du keinerlei Vorteil davon, gönnst halt dem Netzbetreiber 
den Vorteil auch nicht


Die einzig interessante Anwendung die ich mir für eine 
Leistungsbegrenzung bei HM-Wechserichtern vorstellen kann:  Wenn man 
damit Akkukapazität ins Netz einspeisst...

[RoHS-CE (Gast)]

Hallo,
ich hoffe, es ist langsam mal Schluss hier mit Diskussionen, die nix mit 
der Protokoll Entschlüsselung zu tun haben.

Hier geht es um die Protokoll Entschlüsselung, Tests und da ist noch 
viel zu tun !

[Stefan R. (rossiman)]

Ziyat T. schrieb:
> @Stefan R. (rossiman)
> @Daniel R. (daniel92)
> Bei dem Thema Wemos1/esp8266 ist mir das noch aufgefallen:
> Wenn jemand den WR steuern möchte, muss man  die Leistung (+/-) beim
> Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein
> RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.
Ich würde den WR über einen ESP8266 nur über MQTT steuern und lesen. Für 
die Leistungserfassung am Hauszähler habe ich schon einen ESP8266 mit 
Tasmota. Der bekommt die Daten über Infrarot Diode und sendet sie wieder 
über MQTT. Die Regelung mache ich mit Node Red auf dem Raspi meiner 
Heimautomatisierung. Für die Hoymiles Schnittstelle wäre für mich 
deshalb auch eine ESPEasy Plugin total ok. Für mich passt aber natürlich 
auch das was hier gebaut wird. Ich nutze aber die ESPs nur als 
Schnittstelle zu Sensoren und Aktoren.

[Maik R. (bastelbarney)]

Hi Leute,

mir ist da ein kleiner Bug im AHOY aufgefallen. Und weil ich Eure Arbeit 
schon nutze, dachte ich mir: "los, hilf auch mal!"

Aber irgendwie bin ich dermaßen QtCreator und VS verwöhnt, dass ich 
gerne den Code im Single-Step-Debugger durchlaufen wollte. Geht das mit 
dem 8266? In der Ardu-IDE is ja nix. Geht sowas mit VSCode? Oder läuft 
der Code auf dem 8266 direkt aus dem Flash? dann ja wohl eher nix mit 
single-Stepping ...

[isnoAhoy (Gast)]

Hallo Maik R.,
für single-step debugging direkt auf der Hardware brauchst Du einen JTAG 
oder Serial Wire Debug (SWD) Port. Mir ist nicht bekannt, daß die 
Espressif Chips ESP8266 und ESP32 sowas anbieten. Aber eine Suche nach 
OpenOCD (On Chip Debugger) und ESP8266 fördert sogar ein paar Seiten zu 
Tage:

esp8266-openocd/TODO
https://github.com/sysprogs/esp8266-openocd/blob/master/TODO

ESP32 JTAG Debugging
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/index.html

Man müsste mal einen ST-Linkv2 an die ESP Module / Chips klemmen und das 
versuchen. Wie man dann den GDB im VSCode mit Platform IO zum laufen 
bekommt, wäre ein weites Thema. Hier ist ein Beispiel:

Debugging ESP8266 code with OpenOCD and Visual Studio
https://visualgdb.com/tutorials/esp8266/openocd/

ESP8266 Development Log 00: Environment Setup
https://blog.thexyzlab.studio/esp8266-development-log-00-environment-setup/

Hier gibt es auch ein Pinout für den o.a. JTAG Port, aber alles in allem 
scheint es mit dem ESP32 einfacher und besser unterstützt zu sein.

WIFI-JTAG
https://github.com/emard/wifi_jtag

[Daniel M. (daniel_m821)]

isnoAhoy schrieb:
> für single-step debugging direkt auf der Hardware brauchst Du einen JTAG
> oder Serial Wire Debug (SWD) Port. Mir ist nicht bekannt, daß die
> Espressif Chips ESP8266 und ESP32 sowas anbieten.

Ich hab hier noch 2 unbenutzte M5Stack Core2 rumfliegen, da tickert ein 
ESP32 drin rum.
Wäre das eine Option zum Testen?

[Daniel R. (daniel92)]

isnoAhoy schrieb:
> Bei HM- Wechselrichtern geht das alles mit
> der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete
> sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen.

Moment, nochmal ganz kurz das war mir gerade etwas viel Infos.
Ich habe letztens versucht da weiter zu kommen...

Wie darf ich das mit der Zeit verstehen? Wird hier ein Timestamp 
mitgeschickt von der aktuellen Uhrzeit oder wie das zu verstehen? Wenn 
jemand da mehr Infos für mich hat, gern her damit. :)

Vielleicht findet man dadurch eine Kombination aus dem alten MI und den 
neuen HM, wo man statt '100%' nur die Zeit dafür einsetzt.

Command|WR|DTU|SubCommand|Time|500W|CRC so vielleicht?

Gruß

[ST2 (Gast)]

Ich habe mal eine Frage an die HM-1500 Experten hier im Forum.

Ich hatte mir einen HM-800 bestellt allerdings irrtümlich einen HM-1500 
geliefert bekommen. Bevor ich den wieder zurückschicke und noch länger 
auf einen HM-800 warten muß, weil der zur Zeit beim Händler nicht 
lieferbar ist, dachte ich mir, dass ich den HM-1500 auch verwenden 
könnte. Allerdings liefern die von mir ins Auge gefassten Solarmodule 
bei Pmax 12,5 A und das ist mehr als die 11,5 A pro Kanal die der 
HM-1500 maximal verträgt (der HM-800 kann 12,5 A pro Kanal). Der HM-1500 
hat doch so wie der HM-800 auch nur 2 MPPT Tracker, also die Spannung an 
den zwei rechten bzw. den zwei linken Kanälen ist immer gleich geregelt, 
d.h. mann könnte doch die zwei rechten bzw. die zwei linken Kanäle 
parallel mittel MC4 Splitter an ein Solarmodul schalten, um ihn dann wie 
einen HM-800 zu betreiben. Ist zwar overkill, aber das sollte doch 
funktionieren und der Microinverter wird nicht so warm und ich könnte 
sogar Module mit Imax >12,5 A verwenden?

Vielen Dank für die Hilfe.

Grüße,
Stefan

[Postitiveselektron (Gast)]

ST2 schrieb:
...
> könnte. Allerdings liefern die von mir ins Auge gefassten Solarmodule
> bei Pmax 12,5 A und das ist mehr als die 11,5 A pro Kanal die der
> HM-1500 maximal verträgt (der HM-800 kann 12,5 A pro Kanal). Der HM-1500
...

Hallo Stefan,
warum wird hier ein Thread geentert mit Fragen, die mit der Überschrift 
nix zu tun hat ?
Mach dafür ein extra Thread auf.
Gleiche Fragestellung war vor einigen Tagen schon in einer anderen 
Gruppe.

[ST2 (Gast)]

@Positron Sorry, ich dachte, dass meine Frage viel mit der 
Threadüberschrift zu tun hat, es geht schließlich um "Hoymiles HM-XXXX 
Wechselrichter", die sowohl den HM-800 als auch den HM-1500 umfassen, 
beide lassen sich über Nordic Protokoll auslesen und die hierbei 
gesammelten Erkenntnisse lassen Rückschlüsse über die Anzahl der MPPT 
Tracker und die interne Verschalung der 4 DC Channles beim HM-1500 zu. 
Ich konnte leider keinen anderen Thread mit der gleichen Fragestellung 
finden.

[Daniel M. (daniel_m821)]

ST2 schrieb:
> @Positron Sorry, ich dachte, dass meine Frage viel mit der
> Threadüberschrift zu tun hat, es geht schließlich um "Hoymiles HM-XXXX
> Wechselrichter", die sowohl den HM-800 als auch den HM-1500 umfassen,
> beide lassen sich über Nordic Protokoll auslesen und die hierbei
> gesammelten Erkenntnisse lassen Rückschlüsse über die Anzahl der MPPT
> Tracker und die interne Verschalung der 4 DC Channles beim HM-1500 zu.
> Ich konnte leider keinen anderen Thread mit der gleichen Fragestellung
> finden.

Hallo ST2,

elektrisch ist das sicher kein Problem. Du kannst mit dem Auslesen des 
WR auch überwachen, was er tut. Hier wäre es in deinem Fall wichtig, 
dass du beobachtest, was der WR tut.
Sobald du die Splitter im Einsatz hast, sollte sich der Strom auf beide 
Eingänge aufteilen.
Bereite dir bitte ein Monitoring auf der Basis der Software vor und 
beobachte damit deinen WR.

Klar ist es nicht schön, andere Threads zu entern, allerdings ist es in 
dem Fall durchaus möglich, abseits der eigentlichen Fragestellung eine 
Lösung für ein Problem zu finden.

Sobald du dein System aufgesetzt hast, wäre es schön, Informationen über 
die Performance zu bekommen. Berichte bitte über die AC-Leistung und die 
beiden integrierten Tracker, wie die laufen.
Gerne auch mit MQTT logging. Deine Frage ist mir in anderen Kreisen 
schon oft begegnet.

Nachtrag:
Ich finde es wichtig, sich nicht nur auf das Protokoll zu versteifen 
sondern auch zu verstehen, was am Ende rauskommt. Daten sind das eine, 
aber wenn man diese nicht richtig interpretieren kann, ist es halt 
unschön.
Solche Spezialfälle gibt es immer wieder und genau hier ist das 
Protokoll und die Software eine Hilfe, die zum Erfolg führen kann.
In Bezug auf z.B. einen Akku am WR anstelle von Modulen, eine 
Leistungsbegrenzung und die damit verbundenen weiteren Möglichkeiten, 
die sowohl der WR als auch Software bringen können, finde ich genau 
diese Art Messdaten durchaus interessant für die zukünftige Entwicklung.
Da steckt Potential drin :)

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> isnoAhoy schrieb:
>> Bei HM- Wechselrichtern geht das alles mit
>> der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete
>> sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen.
>
> Moment, nochmal ganz kurz das war mir gerade etwas viel Infos.
> Ich habe letztens versucht da weiter zu kommen...
>
> Wie darf ich das mit der Zeit verstehen? Wird hier ein Timestamp
> mitgeschickt von der aktuellen Uhrzeit oder wie das zu verstehen? Wenn
> jemand da mehr Infos für mich hat, gern her damit. :)

Hier 
https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt 
findest du alles für den HM. Speziell Zeile 399.

15:72220200:72220200:80:0B:00:6209049b:00 00 00 00 00 00 00 00 F2 68 
F0

[Tarifarbeiter (Gast)]

Lukas P. schrieb:

> Leute vergesst den Gedanken mit Ahoy Geld zu verdienen! Die Lizenz
> erlaubt es nicht, dass Ahoy verkauft wird!
> Lesen hilft und heulen wenn sich der Anwalt meldet geht gar nicht.


Also ich sehe hier: https://github.com/grindylow/ahoy/blob/main/LICENSE

GNU General Public License v3.0

Damit ist es sehr wohl erlaubt Geld zu machen.
Bei Github gibt es sogar kleine rote und grüne Häkchen die auf dem 
ersten Blick erklären wie die zitierte Lizenz zu nutzen ist.

Das nächste mal muss man halt ein proprietäres Lizenz wählen, dann darf 
auch die Anwalt Keule kommen.

[Lukas P. (lumapu)]

Das stimmt, das Repository ist per GNU 3.0 lizenziert.

Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3

Finde es gut wenn wir dieses Thema klar verständlich für alle umsetzen 
können. Verbesserungen sind willkommen, Ziel soll sein:

- jeder darf die FW bauen / verändern
- jeder darf beitragen
- es darf kein Geld mit dem Wissen  Software  PCB Layout / Gehäuse 
verdient werden

Ich kenne auch ein anderes Projekt, das ein ähnliches Problem hat und es 
mit dieser Zeile in jedem File kenntlich gemacht hat (auch nach dem pull 
des Codes): https://github.com/pa-pa/AskSinPP

Der ESP präsentiert die Lizenz übrigens auch direkt auf der Index.html

[Ziyat T. (toe_c)]

Lukas P. schrieb:
> Das stimmt, das Repository ist per GNU 3.0 lizenziert.
>
> Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt:
> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3
>
Es waere ev. besser direkt in hier:
https://github.com/grindylow/ahoy/blob/main/LICENSE
auf diese:
Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
zu verweisen

[Tarifarbeiter (Gast)]

Lukas P. schrieb:
> Das stimmt, das Repository ist per GNU 3.0 lizenziert.
>
> Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt:
> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3
>
> Finde es gut wenn wir dieses Thema klar verständlich für alle umsetzen
> können. Verbesserungen sind willkommen, Ziel soll sein:
>
> - jeder darf die FW bauen / verändern
> - jeder darf beitragen
> - es darf kein Geld mit dem Wissen  Software  PCB Layout / Gehäuse
> verdient werden
>
> Ich kenne auch ein anderes Projekt, das ein ähnliches Problem hat und es
> mit dieser Zeile in jedem File kenntlich gemacht hat (auch nach dem pull
> des Codes): https://github.com/pa-pa/AskSinPP
>
> Der ESP präsentiert die Lizenz übrigens auch direkt auf der Index.html

Tatsächlich.
Ja dann habe ich mich geirrt.
Ich fände es auch gut wenn die Lizenz prominenter zu sehen wäre. Dieses 
Projekt ist jetzt "heiß" genug dafür.

Beste Grüße

[IsnoAhoy (Gast)]

Also ich persönlich bin für die GNU GPL v2/3 wie bereits ursprünglich im 
Projekt von Grindylow  Martin  Petersilie vorgesehen. Eine LICENSE 
Datei wäre natürlich schön. Da ich aber bisher kaum Code beigetragen 
habe unterwerfe ich meine Zusätze der Doku auch gerne einer anderen 
Lizenz.
Wenn also einige der Haupt-Contributoren (Lukas P., Thomas B. -> 
ESP8266/32, bzw. Jan-Jonas S. Python) hier eine ggf restriktivere Lizenz 
CC-SA-NC also non-commercial wünschen um zB Copy-Cat und unnötige 
Support-Anfragen zu verhindern dann ist das 1. verständlich und 2. auch 
gerechtfertigt da sie den größten Anteil am Code haben.
Andererseits werden die Support-Anfragen dadurch nicht weniger oder 
qualitativ besser und den Fragestellern sieht man es am Issue / 
Kommentar nicht direkt an ob sie das Ding gekauft oder selbst 
zusammengebastelt haben.
Vielleicht hilft es auch wenn wir hier einen „Selbstkostenpreis“ als 
Richtschnur oder Bill Of Materials im Readme.md definieren um 
unerwünscht hohe Preise von 50 Euro auf Kleinanzeigen als ebensolche 
herauszustellen ?

* Wemos D1 plus 4,65 EUR
* nRF24L01+ Modul 3,65 EUR

bzw. Optional statt der Komponenten oben
* NodeMCU v3.4 6,85 EUR
* nRF24L01+ PA Modul 5,75 EUR
plus
* Wemos Proto Board 3,74 EUR oder
* Platine ca. 2,00 EUR laut Oliver R.
* 100uF Elko Kondensator 25V 0,35-1,79 EUR
* Gehäuse 3D Druck einige Euros zugl Versand
ZB hier mit geringen Versandkosten und klarem Preis. Wieviel Gramm wiegt 
denn ein Gehäuse und wie lange dauert der Druck ? Ich habe immer noch 
kein Cura auf dem Handy =^P
https://www.ebay.de/itm/3D-Druck-Service-Drucken-von-Prototypen-Figuren-uvm-Schnell-und-Preiswert-/265496132225
* Arbeitszeit, Fädeldraht und Lötzinn (unbezahlbar heutzutage =^)

Macht in Summe also schon mal ca. 15-20 Euro je nachdem welche 
Komponenten und wie viel Versandkosten dazu kommen. Auch der Paketboote 
will ja was verdienen.

@Lukas P. wieviel wäre demnach für einen komplett zusammengebauten Satz 
für Dich erträglich / verständlich ?

Abseits der Frage nach der korrekten Lizensierung wäre das ja die Frage 
die wir für uns erstmal beantworten müssten, bevor wir ein Angebot als 
moralisch „unanständig“ oder korrekt („Selbstkostenpreis“) 
klassifizieren.

Für mich wäre zwar bei ca. 30 Euro eine Grenze erreicht (-> Gschmäckle). 
Aber wenn jemand Fremdes mehr dafür bezahlen will oder ein Bekannter mir 
mehr dafür gibt weil ich ja „auch soo viel Arbeitszeit reingesteckt“ 
habe, müsste ich auch nach guten Argumenten suchen dieses nicht 
anzunehmen.

Ich weiss aber nicht ob wir die von Einigen hier produzierten 
Überschüsse (bei 5-10 Modulen sind halt die anteiligen Versandkosten 
geringer und man hat auch immer ein paar Ersatzteile im 
Materialkontinuum für andere Projekte) Einzelner hier auf der Liste 
wirklich mit dem Anwalt sanktionieren müssen.

Ich will jedenfalls nicht die Hardware für andere zusammenlöten und 
verkaufen aber wenn ich die anderen vier PA Module wiederfinde hänge ich 
bestimmt noch eines an den Raspberry Pi oder versuche mal den Hoymiles 
HM-600 mit der P8/Pinetime Smartwatch abzufragen.

[Lukas P. (lumapu)]

Hallo Stefan,

ja genau wir sind noch zu stark in den Kinderschuhen als dass man hier 
zu stark unbedarfte damit versorgen sollte (Support). Daher würde ich 
auch einen nachvollziehbaren Preis von 10-15€ akzeptieren / verstehen.

Was ich halt unterstreichen will: ich bin nicht einer der 'Dummen' um 
anderen ein verkaufsfähiges Produkt auf den Tisch zu zaubern und selbst 
leer auszugehen. Warum kann es nicht einfach offen sein und wer ein 
bisschen Lust auf basteln hat kann sich für lau eine DTU ohne Cloud 
selbst stricken - und sogar noch eigene Anpassungen vornehmen.

Besonders gefährdet als Produkt verkauft zu werden sind glaube ich nur 
die ESPs.
Wir wollen ja auch nicht hoymiles eine Konkurrenz machen, sondern eine 
Cloud freie Version, ursprünglich ging es ja nur um die Entschlüsselung 
des Protokolls ^^

[Holger S. (skusi)]

Günter H. schrieb:
> @Holger S.
> Sehr kompaktes Layout.
> Einige Anmerkungen:
> - Den 3.3V-Spannungsregler weiter vom AC-Eingang weg platzieren, der
> Abstand zwischen AC-Eingang und der übrigen Schaltung erscheint mir sehr
> klein zu sein. Besonders dann, wenn eine externe Antenne geplant ist.
> - Datenblatt HiLink_3W_Power_Supply Seiten 7-8, Kap. 8 "Typical
> Application Circuit". Dort ist ausgeführt: "Fuses and varistors are the
> basic protection circuits (required)" sowie "For certification, safety
> capacitors and common mode inductors cannot be omitted". (Danke an den
> Google-Übersetzter)

Wenn ich hier so lese, das die 3,3V vom Wemos ausreichend stabil sind, 
und man den Elko auch nicht unbedingt benötigt. Bin ich geneigt den 
Spannungsregler und die Kondensatoren rauszuschmeißen um dann Platz für 
eine Sicherung zu schaffen. Ich möchte ungerne auf ein größeres Gehäuse 
aufrüsten müssen.
Ich experimentiere derzeit mit verschienden0en Lösungen. Dabei hat sich 
übrigens schon ergeben das meine Idee mit der Schrumpfschlauch / Alu 
Klebeband Abschirmumg des RF24 den Empfang sehr verschlechtert. Ich habe 
die  Schirmung wieder entfernt, und nun werden meine 6 WR auch ziemlich 
sauber empfangen.
Einzig den Grund für die Abstürze habe ich noch nicht ergründen können. 
Ich habe nun alle meine 3 Verschiedenen Wemos d1 mini clone ausprobiert, 
und keiner schafft mehrere Stunden Uptime.

[Thomas B. (tbnobody)]

Ziyat T. schrieb:
> Deise SW ist orig. vom Hubi, ich habe für den MI-1500 abgaendert und als
> Arbeits-/Debug-SW zu verstehen.
> Nur für ArduinoUno.

Hallo Ziyat,

du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der 
Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands 
geführt. Hattest du auch mal versucht die Non-Legacy commands zu 
verwenden? (Also die, die oben auf dem Sheet "Data collection 
instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein)

Ich glaub mit meiner aktuellen ESP32 Lib sollte man das evtl. mit 
überschaubarem Aufwand umsetzen können (evtl...). Wenn ich da ein paar 
Background Infos hab muss ich mich aber nicht so durch den Arduino Code 
mühen.

[Daniel M. (daniel_m821)]

Thomas B. schrieb:

> du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der
> Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands
> geführt. Hattest du auch mal versucht die Non-Legacy commands zu
> verwenden? (Also die, die oben auf dem Sheet "Data collection
> instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein)

Hallo Thomas,
ich habe heute meine ESP32 bekommen und direkt mit deiner Version 
losgelegt.
Die sendTime-Routine etwas umgefummelt damit Daten gesendet werden:

HM_Abstract.cpp:

    payload->mainCmd = 0x09;
    payload->subCmd = 0x00;
    payload->timeout = 2000;
    payload->len = 0;

mainCmd = 0x09 ergibt Antwort 0x88 (Event/Status Modul 1) und 0x89 (PV 
Daten) auf der Payload Position 0.
Doe 0x11 ergibt die Antworten 0x91 (PV Daten) und 0x92 (Event/Status 
Modul 2).

Ziyat hat einen MI-1500, ich habe einen MI-700 Klon.
Die Befehle sind etwas unterschiedlich, die Grundlegenden Antworten sind 
aber identisch. Ziyat bekommt 8 Antworten, ich 4.

Der mainCmd 0x15 hat keine Auswirkungen auf die alten Modelle.

> Ich glaub mit meiner aktuellen ESP32 Lib sollte man das evtl. mit
> überschaubarem Aufwand umsetzen können (evtl...). Wenn ich da ein paar
> Background Infos hab muss ich mich aber nicht so durch den Arduino Code
> mühen.

Für die Backgroudinfos sind wir sicher zu haben, ich fange mal an.

Ich habe für den 2-Kanal MI folgendes in der MI_2CH.cpp, einer Kopie 
deiner HM_2CH.cpp:

#include "MI_2CH.h"

MI_2CH::MI_2CH(uint64_t serial)
    : HM_Abstract(serial) {};

bool MI_2CH::isValidSerial(uint64_t serial)
{
    return serial >= 0x104100000000 && serial <= 0x104199999999;
}

String MI_2CH::typeName()
{
    return String(F("MI-600, MI-700, MI-800"));
}

const byteAssign_t* MI_2CH::getByteAssignment()
{
    return byteAssignment;
}

const uint8_t MI_2CH::getAssignmentCount()
{
    return sizeof(byteAssignment) / sizeof(byteAssign_t);
}

Die .h habe ich angehängt, diese ist aber noch lange nicht lauffähig, 
jedoch stimmt die Reihenfolge der Bytes bereits.

Zeile 14 hat garantiert die falsche Länge.

Die Hoymiles.cpp habe ich ab Zeile 43 folgend erweitert:

std::shared_ptr<InverterAbstract> HoymilesClass::addInverter(const char* name, uint64_t serial)
{
    std::shared_ptr<InverterAbstract> i;
    if (HM_4CH::isValidSerial(serial)) {
        i = std::make_shared<HM_4CH>(serial);
    }
    else if (HM_2CH::isValidSerial(serial)) {
        i = std::make_shared<HM_2CH>(serial);
    }
    else if (HM_1CH::isValidSerial(serial)) {
        i = std::make_shared<HM_1CH>(serial);
    }
    /*if (HM_4CH::isValidSerial(serial)) {
        i = std::make_shared<MI_4CH>(serial);
    }*/
    else if (MI_2CH::isValidSerial(serial)) {
        i = std::make_shared<MI_2CH>(serial);
    }
    /*else if (HM_1CH::isValidSerial(serial)) {
        i = std::make_shared<MI_1CH>(serial);
    }*/

Leider komme ich mit dem Empfang der Payload nicht weiter.
Log:

Fetch inverter: 17872974971670
TX 9 60 53 3 16 78 56 34 12 0 27 
RX Period End
All missing
Nothing received, resend whole request
TX 9 60 53 3 16 78 56 34 12 0 27 
RX Period End
All missing
Nothing received, resend whole request

Warum unter Fetch inverter das ganze in Dezimal (?) kodiert steht, kann 
ich noch nicht nachvollziehen.

Ansonsten muss ich isnoahoy zustimmen, dein Code ist sehr übersichtlich 
und aufgeräumt. Sehr gut! :)

Wenn du nochmal Beispiele für komplette Empfangspayload brauchst, kann 
ich gerne noch welche schicken.

88 63500316 63500316 00 03 00 00 00 00 00 00 8B D8 29
89 63500316 63500316 012D 0001 095D 1389 003D 085D 00FF E550 EF
91 63500316 63500316 012D 0001 095D 1389 003D 085D 00FF E550 EF
92 63500316 63500316 00 03 00 00 00 00 00 00 91 98 81
pid WR-ID    WR-ID   Payload

Das Grundgerüst ist, soweit ich gesehen habe, identisch zu meinem, nur 
die payload-ID's zum Abfragen und Empfangen sind unterschiedlich.

Wäre es einfach Möglich, in den inverters/xxx.h und xxx.cpp die commands 
und payload-ID's hinzuzufügen?
Etwa in dieser Form:

const uint8_t MI_2CH::getPayload()
{
    mainCmd = 0x09; //Ch0 request
    mainCmd = 0x11; //Ch1 request
    PayloadID = 0x88; //Event Ch0
    PayloadID = 0x89; //PV-DATA Ch0
    PayloadID = 0x91; //PV-DATA Ch1
    PayloadID = 0x92; //Event Ch1
}

Zum genauen Ablauf von Sende/Empfangsdaten müsste Ziyat was sagen, 
mainCmd hier sind:
Ch0=0x36
Ch1=0x37
Ch2=0x38
Ch3=0x39

Leider gibt es zur Antwort keine Kommentare in der Version von Gitee.

Ein Zeit-Kommando gibt es nicht, eine CRC16 auf dem mainCmd gibt es 
nicht, nur das CRC8.
Eine CRC16 auf der Payload gibt es ebenfalls nicht, das letzte Byte auf 
0x89 und 0x91 ist Bestandteil der Gesamtproduktion des WR. Wie das 
aufgebaut ist, hab ich noch keine Ahnung. ES gibt Hinweise in der 
Gitee-Version, lass da später mal schauen.
Das einfachste dürfte sein, eine Bedingung: wenn HM-Inverter, dann 
CRC16, wenn MI, dann einfach die Payload mit (ID) nutzen.

Btw. ich habe 2 Kollegen mit Balkonkraftwerken angesteckt, ich habe 
heute 4 Module, der nächste 3 und der 3. 1 Modul abgeholt. Jeder wird 
einen HM-1500 verwenden.
Der MI-Klon wird natürlich weiterarbeiten und für Tests herhalten.

Danke für deine gute Vorlage, Thomas, ist das erste mal für mich, dass 
ich freudig durch VScode gewuselt bin :)

lg
Daniel M.

[Thomas B. (tbnobody)]

Daniel M. schrieb:

>

> HM_Abstract.cpp:
> 
>     payload->mainCmd = 0x09;
>     payload->subCmd = 0x00;
>     payload->timeout = 2000;
>     payload->len = 0;
>

Mein Plan war hier eine MI_Abstract.cpp Datei zu haben. Diese wird dann 
alle MI-Spezifischen Methoden enthalten.

> Der mainCmd 0x15 hat keine Auswirkungen auf die alten Modelle.
Ok, damit muss man wirklich das Legacy Protokoll Implementieren.

>

> #include "MI_2CH.h"
> 
> MI_2CH::MI_2CH(uint64_t serial)
>     : HM_Abstract(serial) {};
> 
> bool MI_2CH::isValidSerial(uint64_t serial)
> {
>     return serial >= 0x104100000000 && serial <= 0x104199999999;
> }
> 
>

Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern 
gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich 
wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

> Leider komme ich mit dem Empfang der Payload nicht weiter.
> Log:
>

> Fetch inverter: 17872974971670
> TX 9 60 53 3 16 78 56 34 12 0 27
> RX Period End
> All missing
> Nothing received, resend whole request
> TX 9 60 53 3 16 78 56 34 12 0 27
> RX Period End
> All missing
> Nothing received, resend whole request
>

Du wirst hier aktuell auch noch nichts empfangen können. Die 
Empfangsroutine erwartet aktuell Fragmente die jeweils eine CRC usw. 
enthalten. Das muss ich an der Stelle noch umtippen (ggf. 2. 
Empfangsmodus für Pakete die nicht als Fragmente übertragen werden). 
Aber selbst wenn das nicht implementiert ist sollte zumindest ein "Frame 
kaputt" kommen da die Fragment CRC nicht geprüft werden kann: 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/HoymilesRadio.cpp#L74

Ich habe aber noch im Hinterkopf das die DTU's für die MI's einen 
anderen Nummernkreis haben. Ggf. erfolgt deshalb keine Antwort. Da muss 
ich aber nochmal nachlesen bzw. den Code von Ziyat anschauen.

> Warum unter Fetch inverter das ganze in Dezimal (?) kodiert steht, kann
> ich noch nicht nachvollziehen.
Das scheint noch ein Problem bei mir zu sein. Muss in dieser Zeile die 
Ausgabe als Hex machen: 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/Hoymiles.cpp#L27


> Zum genauen Ablauf von Sende/Empfangsdaten müsste Ziyat was sagen,
> mainCmd hier sind:
> Ch0=0x36
> Ch1=0x37
> Ch2=0x38
> Ch3=0x39
>
> Leider gibt es zur Antwort keine Kommentare in der Version von Gitee.
Die Antworten auf die entsprechenden Anfragen sind im Excel (siehe auch 
hier 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") 
auf dem 3. Blatt von links in Zeile
106 beschrieben (Anfrage in Zeile 104)


> Danke für deine gute Vorlage, Thomas, ist das erste mal für mich, dass
> ich freudig durch VScode gewuselt bin :)
Freut mich das es mit VSCode klappt. Wenn man erstmal weiß was es tut 
ist es imho viel schöner als die Arduino IDE.

[Daniel R. (daniel92)]

Thomas B. schrieb:
> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern
> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich
> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

Ich hab mal einfach im Internet zusammen gesucht, kein Gewähr auf 
richtigkeit. :)


MI-500
104021600117:https://www.youtube.com/watch?v=uqnoU9fCvOg

MI-1500
106160914811:https://www.alpha-solar.info/images/product_images/original_images/MI-1500%20Vorderseite%20freigestellt%20klein.png

105154003229:https://images.tcdn.com.br/img/img_prod/606124/kit_hoymiles_mi1500_4_paineis_440w_monocristalino_12351_6_5e3655b2364e9548a6376ae715afcf69.jpg

[Daniel M. (daniel_m821)]

Thomas B. schrieb:

Hallo Thomas,

> Mein Plan war hier eine MI_Abstract.cpp Datei zu haben. Diese wird dann
> alle MI-Spezifischen Methoden enthalten.

das war auch mein Gedanke, irgendwo muss man aber anfangen, daher bot 
sich diese Funktion an.

> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern
> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich
> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

Jup, der Nummernkreis ist gleich, startet aber mit 10 statt 11.


> Du wirst hier aktuell auch noch nichts empfangen können. Die
> Empfangsroutine erwartet aktuell Fragmente die jeweils eine CRC usw.
> enthalten. Das muss ich an der Stelle noch umtippen (ggf. 2.
> Empfangsmodus für Pakete die nicht als Fragmente übertragen werden).
> Aber selbst wenn das nicht implementiert ist sollte zumindest ein "Frame
> kaputt" kommen da die Fragment CRC nicht geprüft werden kann:
> 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/HoymilesRadio.cpp#L74

Das ist eine gute Frage. Nachdem ich die CRC16 in der ahoy-version 
ausgeblendet habe und nicht verwende, bekomme ich zumindest valide 
Pakete.

> Ich habe aber noch im Hinterkopf das die DTU's für die MI's einen
> anderen Nummernkreis haben. Ggf. erfolgt deshalb keine Antwort. Da muss
> ich aber nochmal nachlesen bzw. den Code von Ziyat anschauen.

Die Nummer der DTU scheint dem WR relativ egal, ich bekomme mit der 
modifizierten Version von Hubi mit den den DTU-ID's antworten.

> Das scheint noch ein Problem bei mir zu sein. Muss in dieser Zeile die
> Ausgabe als Hex machen:
> 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/Hoymiles.cpp#L27

Das eilt nicht :)
Wenn man es weiß, ist es ok, normal schaut aber keiner weiter darauf.

> Die Antworten auf die entsprechenden Anfragen sind im Excel (siehe auch
> hier
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")
> auf dem 3. Blatt von links in Zeile
> 106 beschrieben (Anfrage in Zeile 104)

Jup, die Antworten sind so aufgebaut.

> Freut mich das es mit VSCode klappt. Wenn man erstmal weiß was es tut
> ist es imho viel schöner als die Arduino IDE.

VSCode ist schon angenehm im Handling, jemanden allerdings, der nicht so 
tief in der Entwicklung steckt, erschlägt es einen erstmal.
Viel schöner als die Arduino IDE ist es auf jeden Fall.

Danke und Respekt für deine Arbeit mit dem ESP32.
Natürlich auch Hubi und den anderen mit Raspi und ESP8266.
Das ganze ist nicht so einfach und trotzdem irgendwie faszinierend :)

[Ziyat T. (toe_c)]

Daniel M. schrieb:
Thomas B. schrieb:
>> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern
>> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich
>> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

Hallo zusammen
Die Frage wurde schon im Doku beantwortet:
https://github.com/lumapu/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx
HM beginnt mit 11
MI beginnt mit 10
250 Watt -> xx20
300 bis 400 Watt  -> xx21
500 Watt -> xx40
600 bis 800 Watt -> xx41
1000 Watt -> xx60
1200 bis 1500 Watt -> xx61

Die MI-1500 commands und antworten könnt ihr ja in meinen Beitraegen 
finden.

Hoffe bald auf eine Version mit MI1500;-)

Noch eine freche Frage: Könnt ihr bitte die Limitierung (CMD 0x51) auch 
einbauen, mit der mqtt-Abfrage des Smartzaehler-Wertes?

[Ziyat T. (toe_c)]

Thomas B. schrieb:

> du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der
> Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands
> geführt. Hattest du auch mal versucht die Non-Legacy commands zu
> verwenden? (Also die, die oben auf dem Sheet "Data collection
> instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein)

Bei MI-1500 gehen nur CMD=0x36-0x39
Alle Kombinationen für den MI-1500 wurde von mir bereits getestet.
Bitte siehe meine Beitraege.

[Ziyat T. (toe_c)]

Daniel M. schrieb:
Thomas B. schrieb:

>>Eine CRC16 auf der Payload gibt es ebenfalls nicht, das letzte Byte auf
>>0x89 und 0x91 ist Bestandteil der Gesamtproduktion des WR. Wie das

Doch, ohne CRC16 bekommt man auch die falschen Werte, z.B. ein PV 
5300Watt, das mach die Rechnung schwieriger;-).

[Ziyat T. (toe_c)]

@Thomas B.
@Daniel M.

Ich habe alle commands für den MI-1500 mit meiner DTU-Pro verifiziert. 
Ich habe die Kommunikation DTUPro-WR gesnifft und die cmd's und 
Antworten so herausgefungen, bevor die gite Dokus gefunden wurde. Die 
habe ich dann so implementiert.

[M. P. (matze7779)]

Hallo,

hoffentlich kann mir hier jemand helfen.
Ich habe die Software auf einem Wemos D1 mini.

Dazu dieses Modul:
https://www.amazon.de/gp/product/B09MKCZ7WT/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1

Anbei Screenshots meiner Einstellungen. Leider bekomme ich keine 
Verbindung zum HM-800.
Angeschlossen ist es nach: 
https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Das ganze befindet sich momentan ca. 4m entfernt vom Wechselrichter.

[isnoAhoy (Gast)]

Hallo Matze M.P.,

Du verwendest noch die v0.4.17 versuche es mal mit 0.4.19 es gab da 
evtl. einige Verbesserungen (ich hab das Changelog nicht im Kopf).

Probiere mal eine andere Belegung für die IRQ und CSN / CE Pins. Siehe 
dem entsprechenden GitHub issue: 
https://github.com/grindylow/ahoy/issues/36
Es gabe Hinweise, daß die IRQ Leitung an D3 / GPIO0 teilweise Probleme 
macht. Andere haben D2 & D1 statt D3 & D4 verwendet und Erfolg gehabt.
Bitte also eine Rückmeldung im o.g. Issue falls das bei Dir ebenfalls 
erfolgreich ist.

Als Drittes kannst Du noch das Kleingedruckte auf Deinen Modulen 
überprüfen ob es auch tatsächlich ein nRF24L01+ Modul ist. Es gibt wohl 
auch Module ohne das + bei denen es nicht klappen kann. Ich weiß nicht 
ob die NRF24 Bibliothek beim Booten des ESP über die Serial Console eine 
Versionsnummer des NRF Chips mit ausgibt ? Eventuell gibt es auch noch 
ein eigenes Kommando in der NRF24 Bibliothek um die Version zu prüfen ?

[M. P. (matze7779)]

Die 0.4.19 (fertiges bin) hier aus dem Thread hab ich gerade als OTA 
aufgespielt.
Leider macht der Wemos jetzt kein WLAN auf um ihn zu konfigurieren.
Mist...Jetzt komm ich nicht mehr drauf.

[Heinz R. (heijz)]

Lukas P. schrieb:
> ja genau wir sind noch zu stark in den Kinderschuhen als dass man hier
> zu stark unbedarfte damit versorgen sollte (Support). Daher würde ich
> auch einen nachvollziehbaren Preis von 10-15€ akzeptieren / verstehen.

Ich verstehe zugegeben nicht was manche hier machen - aber vielleicht 
lese ich auch zu wenig mit?

Ich habe hier einen HM-1500 - für den habe ich vor ca. 3 Monaten hier 
was runter geladen, glaube von AHOY, auf einen ESP8266 geflasht, es 
läuft und macht genau was ich will
Viele sagen wir sind im Forschungsstatus - ihr habt es doch schon 
geknackt?

Das ganze rumgeeire was wie verkauft werden kan / soll - wozu?

Ich habe hier einige solcher ESP-Lösungen im Einsatz, YC-600, 
SML-Reader, Wärmepumpe, alle schicken brav über MQTT

Meiner Ansicht nach wird es Zeit das einer ausschert, einfach was 
fertiges präsentiert
Schaut euch gerne mal das hier an:

https://github.com/Egyras/HeishaMon

Es ist wie es ist, tut was es soll, reicht so

Sorry für mein Unverständnis an dieser Stelle und Viele Grüße

[Ziyat T. (toe_c)]

Heinz R. schrieb:
> Ich habe hier einen HM-1500 - für den habe ich vor ca. 3 Monaten hier
> was runter geladen, glaube von AHOY, auf einen ESP8266 geflasht, es
> läuft und macht genau was ich will
> Viele sagen wir sind im Forschungsstatus - ihr habt es doch schon
> geknackt?
>
Es gibt nicht nur die HM-Serie von hoylmoly! Und von HM's werden bisher 
"nur" die WR-Daten geholt, der WR wird noch nicht gesteuert. Also wenn 
du nur Daten von deinem HM möchtest ist es ok. für dich, ich und einige 
möchten mehr: Unterstützung der alle MI's,TSUN, Zuverlaessigkeit, MQTT, 
zero export etc.

> Das ganze rumgeeire was wie verkauft werden kan / soll - wozu?

Alleine ich habe ziemlich viel Zeit investiert für den MI-1500, die 
anderen hier sicher noch mehr. So dürfen wir doch bisschen 
"rumgeeiren";-)

Gruss

[Daniel R. (daniel92)]

Hallo zusammen,

so ich bin aktuell wieder dran HM die Limitierung zu testen.
Folgendes habe ich nun gesendet:

2022-06-29 14:09:39.966934 Transmit 14 | 15 74 40 33 29 78 56 34 12 80 5a 5a 02 b1
2022-06-29 14:09:40.012065 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
2022-06-29 14:09:40.516145 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Jedoch steht in der Descr.: 
https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt 
(Zeile: 520)

**CMD**:
     Befehl an den WR hat Bit 7 gesetzt
       0x80 "Zeit setzen"
       0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01
       0x82 "Anfrage AC-Daten", erwartete Antwort: 0x02
       0x83 "?"
       0x85 "?"
       0xFF "?"
     Antworten vom WR haben Bit 7 gelöscht:
       0x01 "Aktuelle DC-Daten"
       0x02 "Aktuelle AC-Daten"

Habe ich es richtig verstanden, das damals Herausgefunden wurde das man 
die Zeit zuerst setzen muss und später auf Anfrage die eigentliche 
Nachricht zu schicken soll?

[Josef J. (jauntyjosef)]

Hallo!

Ich besitze einen HM-1500 und habe mich auch mal daran versucht. Leider 
scheitere ich ebenfalls. Ich habe auch schon D1&D2 anstatt D3&D4 und 2 
verschiedene nRF24L01+ Module probiert (zumindest auf einem steht das + 
dabei). Es handelt sich dabei um die Version 0.4.20.
Hat vielleicht jemand eine Idee, was ich falsch mache?

[Oswald S. (obmaroszi)]

Hallo,

ich habe dieses Forum durch Zufall gefunden und bin begeistert was Ihr 
alles erreicht habt.
Da ich noch auf meine Aufständerung für meine 2 Module warte, habe ich 
eines im Garten aufgestellt. Zum Test reicht es.(heute regnet es)
Bin noch aus der analog Zeit. Habe es jedoch geschafft das fertige bin 
File auf einen Wemos D1 mini zum laufen zu bringen.
Leider hab ich es nicht geschafft die Daten (MQTT) ins Openhab 3 
einzubinden.

Grosse Lob an alle die hier so hart Arbeiten.
Leider kann ich ausser testen nichts beitragen.

Gruß

[Daniel R. (daniel92)]

Habe mir nochmal das ganze aus Gitee angeschaut.
Mir ist was aufgefallen, kann aber nicht bestätigen ob das sinnig ist.

Mein Gedanke dazu: Der unten stehende Code beschreibt wie ein PowerLimit 
abläuft.
Ich glaube das der WR in der Lage ist sogar einzelne Strings 
kontrolliert abzuschalten, oder Einzuschalten.
Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd' 
mit Bit-Operatoren verarbeitet.
... Könnt ihr aber auch selbst unten lesen.

Was mich noch stutzig macht, was könnte 'Acq_Switch' genau bedeuten?

/***********************************************
** Function name:
** Descriptions:  set micro-inverter power instruction
** input parameters:
** output parameters:
** Returned value:
*************************************************/
uint8_t UsartNrf_Send_PackSetPowerLimitCommand(uint8_t *target_adr, uint8_t *rout_adr, int8_t MainCmd, uint16_t SubCmd)
{
    uint8_t i = 0;
    uint8_t temp_dat[UART_LEN];   //(#define UART_LEN 35)
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//head (#define STX 0x7e)
    temp_dat[0] = MainCmd;   //instruction
    memcpy(&temp_dat[1], target_adr, 4);
    memcpy(&temp_dat[5], rout_adr, 4);

    if(MIMajor[PortNO].Property.Acq_Switch == 0)
    {
        //1000w shutdown Micro-inverse control of 1-to-4 with the last 8 digits of the special control ID less than 0x50000000
        if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
        {
            temp_dat[9]  = SubCmd & 0XFF00 >> 8;      //5a5a
            temp_dat[10] = SubCmd & 0XFF;
            temp_dat[11] = 11;
            //                  temp = 35*4*10=1400=0x0578;
            temp_dat[12] = 0X05;
            temp_dat[13] = 0X78;
            temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
            i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); // forward replacement
        }
        else
        {
            temp_dat[9]  = SubCmd  >> 8;      //5a5a
            temp_dat[10] = SubCmd ;
            temp_dat[11] = Get_crc_xor(&temp_dat[0], 11); //CRC
            i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 12); //forward substitution
        }
    }
    else
    {
        temp_dat[9]  = SubCmd & 0XFF00 >> 8;      //5a5a
        temp_dat[10] = SubCmd & 0XFF;
        temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER    * (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power limit percentage
        temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8;    //High 8-bit power limit
        temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff;            //Low power limit 8 bits
        temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
        i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //forward substitution
    }

    Uart_SendBuffer[(i + 1)] = ETX; //tail
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

[Holger S. (skusi)]

Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x 
Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch 
rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den 
China Wemos Clones liegt.

Leider bekomme ich damit auch keine mehrstündigen Uptimes hin. 
Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber 
irgendwie muß man das doch sauber zum laufen bekommen.

Läuft das bei euch über Tage ohne Reboot ???

[Daniel R. (daniel92)]

Ich kann nichts dazu beitragen. Ich nutze es über Raspberry Pi.
Zusätzlich läuft es aktuell noch nicht (warte immer noch auf die PVs).

[Sigi S. (sermon)]

Holger S. schrieb:
> Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x
> Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch
> rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den
> China Wemos Clones liegt.
>
> Leider bekomme ich damit auch keine mehrstündigen Uptimes hin.
> Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber
> irgendwie muß man das doch sauber zum laufen bekommen.
>
> Läuft das bei euch über Tage ohne Reboot ???

Ja, über mehrere Wochen stabil

[Sigi S. (sermon)]

Daniel R. schrieb:
> Ich kann nichts dazu beitragen.

Was soll dann der Beitrag?
Wenn das jeder macht.....

[Daniel R. (daniel92)]

Ok der Beitrag 
'Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"; ist 
doch erstmal hinfällig. Die Funktion macht nichts anderes als wie in der 
Excel im Blatt "Control instruction" Zeile 91.

Somit könnt ihr denn Teil erstmal überfliegen. ^^

Ist ja für MI, nicht für mich HM.

[Herbert K. (avr-herbi)]

@Holger S. (skusi)

Hallo, ich habe die uralt "hubi" Version für den ESP8266 ohne MQTT 
(Stromversorgung vom PC über USB ca. 2,5m Kabel, kleiner Elko am RF 
Modul, alles total einfach auf einem Steckbrett) und ich habe damit noch 
keinen eigenständigen Reboot erlebt.

Stört evt. was aus der Umgebung ?  Motoren ? Hohe plötzliche 
Stromaufnahme von Waschmaschine, Geschirrspüler, Staubsauger ? Anlauf 
von Kompressoren ? Bohrmaschinen (oder ähnliche Motoren) wo die Kohlen 
feuern ? Oder evt. einfach der WDT, der zuschlägt, weil die 
Stromversorgung nicht sauber ist ?
Kann ja evt. auch aus der Nachbarschaft kommen ? - nur so Ideen -

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

danke daß Du Dir den Source vom Hersteller ansiehst und nicht die leider 
etwas überholten Informationen im hoymiles-format-description.txt/.md.
Es hat sich leider noch niemand gefunden, der das Format/Protokoll auf 
den aktuellen Wissensstand bringt, ich auch noch nicht =^/

Wenn Du dazu jetzt noch die hoymiles-DTU-PRO-GPRS mit der aktuelleren 
hoymiles-DTU-PRO-APP vergleichst wurde an der von Dir angesprochenen 
Stelle noch folgende Vorbedingung in User/NRF/usart_nrf.c eingebaut:

#ifdef DTU3PRO

     if((Dtu3Detail.Property.Zero_Export_Switch == 1) ||
            (Dtu3Detail.Property.DRM_Limit_Switch == 1) ||
            (Dtu3Detail.Property.Phase_Balance_Switch == 1) ||
            (Dtu3Detail.Property.SunSpec_Switch == 1))
    {
        if(MIMajor[PortNO].Property.Acq_Switch == 0)
        {
            //1000w¹Ø»ú ÌØÊâ¿ØÖÆ IDºó8λСÓÚ0x50000000µÄ1ÍÏËÄ µÄ΢Äæ¿ØÖÆ
            if((MIMajor[PortNO].Property.Id[0] < 0X50) && 
((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || 
(MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
...

Den chinesesischen Unicode Kauderwelsch aus den beiden aktuelleren Repos 
habe ich noch nicht übersetzt.

[Stefan T. (isnoahoy)]

Hallo Josef J.,

Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen. 
Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2 
und 3. Dann sollte es m.E. nach einem Reboot funktionieren.

Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen 
Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst 
angepaßt / gefixt.

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

im usart_nrf3.c findet sich übrigens noch der folgende Code:

void UsartNrf3_Send_NetCmdToNrfCmd(void)
{
    if((CurNetCmd >= NET_TURN_ON) && (CurNetCmd <= NET_ELE_ENERGY))
    {
        switch(CurNetCmd)
        {
            case NET_INVERTER_HW_INFOR:
                //case NET_TERMINAL_INFOR:
                SubCmd = InverterDevInform_Simple;
                MainCmd = REQ_ARW_DAT_ALL;
                break;

            case NET_POLL_GRID_ON_FILE:
                SubCmd = GridOnProFilePara;
                MainCmd = REQ_ARW_DAT_ALL;
                break;

            //////////////////////////////////////////////////////////////////////ÔËÐпØÖÆ

            case NET_TURN_ON:
                SubCmd = Type_TurnOn;//¿ª»ú
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_TURN_OFF:
                SubCmd = Type_TurnOff;//¹Ø»ú
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_LIMIT_ACTIVE_POEWR:
            case NET_LIMIT_POEWR:
                SubCmd = Type_ActivePowerContr ;//ÏÞÖÆÓйŠ¹ŠÂÊ
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_LIMIT_REACTIVE_POWER:
                SubCmd = Type_ReactivePowerContr ;//ÏÞÖÆÎÞ¹Š¹ŠÂÊ
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_PF_SET:
                SubCmd = Type_PFSet ;//ÏÞÖƹŠÂÊÒòÊý
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_CLEAN_GFDI:
            case NET_CLEAR_ALARM:
                SubCmd = Type_CleanState_LockAndAlarm ;//ËøËÀžæŸ¯Çå³ý
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_RESTART: //ÏÂÔسÌÐò/žŽÎ»
                MainCmd = DEVCONTROL_ALL;
                SubCmd = Type_Restart;
                break;

            case  NET_UNLOCK:
                SubCmd = Type_Unlock;
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_LOCK:
                SubCmd = Type_Lock;
                MainCmd = DEVCONTROL_ALL;
                break;

            //dong 2020-06-15
            case NET_SELF_INSPECTION:
                SubCmd = Type_SelfInspection;//×ÔŒì
                MainCmd = DEVCONTROL_ALL;
                break;

            ////////////////////////////////////////////////////////////////²ÎÊýÅäÖÃ
            case NET_ELE_ENERGY:
            case NET_SET_ENERGY:
                SubCmd = EleEnergySet;
                MainCmd = PARASET_ALL;
                break;

            case NET_SET_PASSWORD:
            case NET_CANCEL_GUARD:
                SubCmd = AntitheftParaSet;//ÉèÖÃÃÜÂë
                MainCmd = PARASET_ALL;
                break;

            ////////////////////////////////////////////////////////////////ÎÄŒþ¶à°üžüÐÂÎÄŒþ
            case NET_DOWNLOAD_PRO:
                MainCmd = DOWN_PRO;
                SubCmd = Type_Init;
                break;

            case NET_DOWNLOAD_DAT://²¢Íø±£»€ÎÄŒþ
                MainCmd = DOWN_DAT;
                SubCmd = Type_Init;
                break;

            default:
                break;
        }
    }
    else if(CurNetCmd == NET_INIT)
    {
        MainCmd = REQ_ARW_DAT_ALL;

        if(CurPollIsDebugDataTime == false)
        {
            SubCmd = RealTimeRunData_Reality;
        }
        else
        {
            SubCmd = RealTimeRunData_Debug;
        }
    }
    //dong 2020-06-15
    //    else if(CurNetCmd == NET_SELF_STAUS)
    //    {
    //        MainCmd = REQ_ARW_DAT_ALL;
    //        SubCmd = GetSelfCheckState;
    //    }
    //dong 2020-06-23
    //    else if(CurNetCmd == NET_GET_LOSS_RATE)
    //    {
    //        MainCmd = REQ_ARW_DAT_ALL;
    //        SubCmd = GetLossRate;
    //    }
    else if(CurNetCmd == NET_ALARM_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = AlarmData;
    }
    else if(CurNetCmd == NET_RECORD_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = RecordData;
    }
    else if(CurNetCmd == NET_ALARM_UPDATE)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = AlarmUpdate;
    }
    else if(CurNetCmd == NET_MI_VERSION)
    {
        SubCmd = InverterDevInform_Simple;
        MainCmd = REQ_ARW_DAT_ALL;
    }
}

in der usart_nrf3.h stehen die Defines:

#define DEVCONTROL_ALL         0x51
...
typedef enum
{
    Type_TurnOn = 0,
    Type_TurnOff = 1,
    Type_Restart = 2,
    Type_Lock = 3,
    Type_Unlock = 4,
    Type_ActivePowerContr = 11, // 0x0b
    Type_ReactivePowerContr = 12, // 0x0c
    Type_PFSet = 13, // 0x0d
    Type_CleanState_LockAndAlarm = 20,
    //dong 06-15
    Type_SelfInspection = 40,//���������ļ��Լ�
    Type_Init = 0xff,
} DevControlType;

Aber ich dachte das hätten wir schon letzte / vorletzte Woche 
festgestellt.
Bitte schau Dir das doch auch mal an ...

[Daniel R. (daniel92)]

@isnoahoy: Danke für deine Rückmeldung.
Ja da bin ich gerade dran und schaue mir das nochmal inruhe durch.

Ich versuche aktuell aus den "usart_nrf3" denn genauen Aufbau des 
Protokolls nachzuverfolgen.

[Josef J. (jauntyjosef)]

Stefan T. schrieb:
> Hallo Josef J.,
>
> Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen.
> Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2
> und 3. Dann sollte es m.E. nach einem Reboot funktionieren.
>
> Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen
> Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst
> angepaßt / gefixt.

Vielen Dank, das hatte ich gerade zufällig selber probiert. Leider ohne 
Erfolg.

[Heinrich P. (heinrich_p)]

Hallo zusammen,
und vielen Dank für euere tolle Arbeit.
Hab mir vor 2 Tagen bei komputer.de die Chips bestellt:
1 Stk.  nRF24L01+ PA SMA mit Antenne  3.20EUR
1 Stk.  ESP32 Development board NodeMCU kompatibel  6.50EUR
Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens 
mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die 
beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen. 
Nach nur 6 Jahren! Gruselig…

Grüße, Matze

[Daniel R. (daniel92)]

Kann jemand was dazu sagen wie man das zu verstehen hat?

Habe folgendes nachgestellt:
case NET_LIMIT_ACTIVE_POEWR: // NET_LIMIT_ACTIVE_POEWR = 24,
case NET_LIMIT_POEWR:     // NET_LIMIT_POEWR = 3,
   SubCmd = Type_ActivePowerContr; //Limit active power = 11,
   MainCmd = DEVCONTROL_ALL;   // #define DEVCONTROL_ALL 0x51
   break;

2022-06-29 18:13:17.628811 Transmit 11 | 51 74 40 33 29 78 56 34 12 0b 7c
2022-06-29 18:13:17.684810 Received 11 bytes channel 61: d1 74 40 33 29 74 40 33 29 81 50
Error while retrieving data: unpack requires a buffer of 2 bytes

Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten 
nachzusenden?

https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt
(Zeile: 520)

Ist ja ähnlich aufgebaut.
Ich habe zwar in der Vergangenheit gelesen das jmd. herausgefunden hat 
(oder mutmaßt) das wenn die ID vom WR zweimal hintereinander steht, soll 
es sich um ein Verworfenes Packet handeln.

[Harald Franz (Gast)]

Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die 
mit abgespeichert wurden. Copy-paste Fehler.

[Hfhausen (Gast)]

Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die 
mit abgespeichert wurden. Copy-paste Fehler.

[Stefan T. (isnoahoy)]

Hallo Josef J.,

Hfhausen schrieb:
> Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die
> mit abgespeichert wurden. Copy-paste Fehler.

Das könnte auch eine Ursache sein, probier das doch mal aus bzw. 
überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten 
Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und 
Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default 
Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte:
https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584

Desweiteren wäre es hilfreich den ESP8266 per USB Kabel am 
Computer/Laptop angeschloßen zu lassen. Wenn Du unter Tools > Port den 
Anschluß prüfst und dann die Serial Console aufmachst, solltest Du nach 
einem Reset ein etwas ausführlicheres Debug Log bekommen. Die Statistik 
auf der WebSeite in Deinem Screenshot sagt an der Stelle leider nicht 
mehr aus. Das Debug Log enthält auch Informationen zum Anschluß des 
nRF24L01+ und dessen Einstellungen.

[Ziyat T. (toe_c)]

Daniel R. schrieb:

> Ich glaube das der WR in der Lage ist sogar einzelne Strings
> kontrolliert abzuschalten, oder Einzuschalten.
> Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd'
> mit Bit-Operatoren verarbeitet.
> ... Könnt ihr aber auch selbst unten lesen.
>
>         temp_dat[9]  = SubCmd & 0XFF00 >> 8;      //5a5a
>         temp_dat[10] = SubCmd & 0XFF;
>         temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 /
> (EVERY_PORT_POWER    *
> (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power
> limit percentage
>         temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8;
> //High 8-bit power limit
>         temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff;
> //Low power limit 8 bits
>         temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
>         i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15);
> //forward substitution
>     }
Das habe ich schon beschrieben und implementiert, siehe meinen Beitrag 
v. früher:
- nach % limitieren
 SubCMD=5a5a:limit percentage:,CRC
- nach abs.Leistung limitieren:
SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC

[dax (Gast)]

mein esp8266 lief nie länger als 1h.
Fehler beim Debuggen:

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Exception (29):
epc1=0x4000df64 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 
depc=0x00000 
000

>>>stack>>>

ctx: sys
sp: 3fffec10 end: 3fffffb0 offset: 0190
3fffeda0:  00000005 3ffee120 00000002 40100524
3fffedb0:  402329d7 3ffefb6c 3ffea5ef 4023296c
3fffedc0:  00000002 40232913 00000002 40231a68
3fffedd0:  40231a91 3fffee80 3ffee120 00000016
3fffede0:  4022f4f4 3fffee80 3ffedfc8 3ffed9c0
3fffedf0:  3ffeb1d8 3fffee80 3fffee80 00000000
3fffee00:  2d525744 5f363131 46393345 00004334
3fffee10:  00000000 3ffecc90 00000020 40100bdc
3fffee20:  4022b859 4022cd31 3ffed8d0 00000000
3fffee30:  ffffffc0 3ffedadc 3ffeb1e8 3ffee120
3fffee40:  3ffed020 00000020 00000000 402301ef
3fffee50:  00000000 3ffefb6c ffffffc0 00000000
3fffee60:  00000000 3ffee120 3ffee800 304baf06
3fffee70:  4023bfc2 3ffefb6c 0000000e 3ffee014
3fffee80:  00000000 00310a0a 00640100 00000053
3fffee90:  3ffeb1fc 000000d6 3ffeb21f 3ffeb1f0
3fffeea0:  00000000 3ffeb1fc 3ffeb20c 3ffeb219
3fffeeb0:  00000000 00000000 3ffeb292 3ffeb2a8
3fffeec0:  3ffeb25b 3ffeb277 00000000 3ffeb225
3fffeed0:  00000000 00000000 00000020 00000000
3fffeee0:  3ffefe14 4022fc5e 3ffed020 3ffefb6c
3fffeef0:  00000000 3ffee120 3ffed020 3ffeb1d8
3fffef00:  3ffeb1d8 000000fe 00000000 00000020
3fffef10:  00000000 3ffeb1e2 40243313 3ffed020
3fffef20:  3ffeb1cc 3fffdcc0 3ffe9730 3ffe9730
3fffef30:  00000080 3ffed020 00000000 3ffe85d8
3fffef40:  40242bd3 3fffdab0 00000000 40211f56
3fffef50:  3ffe9730 40000f49 3fffdab0 40000f49
3fffef60:  40000e19 0005aef1 00000000 00000005
3fffef70:  60000600 aa55aa55 000000ed 40105539
3fffef80:  4010553f 00000000 00000005 40100b8c
3fffef90:  4010000d 8742b1f0 0005aef1 401000ac
3fffefa0:  00000000 3fffef3c 00000000 3ffffec8
3fffefb0:  3fffffc0 00000000 00000000 feefeffe
3fffefc0:  feefeffe feefeffe feefeffe feefeffe
3fffefd0:  feefeffe feefeffe feefeffe feefeffe
3fffefe0:  feefeffe feefeffe feefeffe feefeffe
3fffeff0:  feefeffe feefeffe feefeffe feefeffe
3ffff000:  feefeffe feefeffe feefeffe feefeffe
3ffff010:  feefeffe feefeffe feefeffe feefeffe
3ffff020:  feefeffe feefeffe feefeffe feefeffe
3ffff030:  feefeffe feefeffe feefeffe feefeffe
3ffff040:  feefeffe feefeffe feefeffe feefeffe
3ffff050:  feefeffe feefeffe feefeffe feefeffe
3ffff060:  feefeffe feefeffe feefeffe feefeffe
3ffff070:  feefeffe feefeffe feefeffe feefeffe
3ffff080:  feefeffe feefeffe feefeffe feefeffe
3ffff090:  feefeffe feefeffe feefeffe feefeffe
3ffff0a0:  feefeffe feefeffe feefeffe feefeffe
3ffff0b0:  feefeffe feefeffe feefeffe feefeffe
3ffff0c0:  feefeffe feefeffe feefeffe feefeffe
3ffff0d0:  feefeffe feefeffe feefeffe feefeffe
3ffff0e0:  feefeffe feefeffe feefeffe feefeffe
3ffff0f0:  feefeffe feefeffe feefeffe feefeffe
3ffff100:  feefeffe feefeffe feefeffe feefeffe
3ffff110:  feefeffe feefeffe feefeffe feefeffe
3ffff120:  feefeffe feefeffe feefeffe feefeffe
3ffff130:  feefeffe feefeffe feefeffe feefeffe
3ffff140:  feefeffe feefeffe feefeffe feefeffe
3ffff150:  feefeffe feefeffe feefeffe feefeffe
3ffff160:  feefeffe feefeffe feefeffe feefeffe
3ffff170:  feefeffe feefeffe feefeffe feefeffe
3ffff180:  feefeffe feefeffe feefeffe feefeffe
3ffff190:  feefeffe feefeffe feefeffe feefeffe
3ffff1a0:  feefeffe feefeffe feefeffe feefeffe
3ffff1b0:  feefeffe feefeffe feefeffe feefeffe
3ffff1c0:  feefeffe feefeffe feefeffe feefeffe
3ffff1d0:  feefeffe feefeffe feefeffe feefeffe
3ffff1e0:  feefeffe feefeffe feefeffe feefeffe
3ffff1f0:  feefeffe feefeffe feefeffe feefeffe
3ffff200:  feefeffe feefeffe feefeffe feefeffe
3ffff210:  feefeffe feefeffe feefeffe feefeffe
3ffff220:  feefeffe feefeffe feefeffe feefeffe
3ffff230:  feefeffe feefeffe feefeffe feefeffe
3ffff240:  feefeffe feefeffe feefeffe feefeffe
3ffff250:  feefeffe feefeffe feefeffe feefeffe
3ffff260:  feefeffe feefeffe feefeffe feefeffe
3ffff270:  feefeffe feefeffe feefeffe feefeffe
3ffff280:  feefeffe feefeffe feefeffe feefeffe
3ffff290:  feefeffe feefeffe feefeffe feefeffe
3ffff2a0:  feefeffe feefeffe feefeffe feefeffe
3ffff2b0:  feefeffe feefeffe feefeffe feefeffe
3ffff2c0:  feefeffe feefeffe feefeffe feefeffe
3ffff2d0:  feefeffe feefeffe feefeffe feefeffe
3ffff2e0:  feefeffe feefeffe feefeffe feefeffe
3ffff2f0:  feefeffe feefeffe feefeffe feefeffe
3ffff300:  feefeffe feefeffe feefeffe feefeffe
3ffff310:  feefeffe feefeffe feefeffe feefeffe
3ffff320:  feefeffe feefeffe feefeffe feefeffe
3ffff330:  feefeffe feefeffe feefeffe feefeffe
3ffff340:  feefeffe feefeffe feefeffe feefeffe
3ffff350:  feefeffe feefeffe feefeffe feefeffe
3ffff360:  feefeffe feefeffe feefeffe feefeffe
3ffff370:  feefeffe feefeffe feefeffe feefeffe
3ffff380:  feefeffe feefeffe feefeffe feefeffe
3ffff390:  feefeffe feefeffe feefeffe feefeffe
3ffff3a0:  feefeffe feefeffe feefeffe feefeffe
3ffff3b0:  feefeffe feefeffe feefeffe feefeffe
3ffff3c0:  feefeffe feefeffe feefeffe feefeffe
3ffff3d0:  feefeffe feefeffe feefeffe feefeffe
3ffff3e0:  feefeffe feefeffe feefeffe feefeffe
3ffff3f0:  feefeffe feefeffe feefeffe feefeffe
3ffff400:  feefeffe feefeffe feefeffe feefeffe
3ffff410:  feefeffe feefeffe feefeffe feefeffe
3ffff420:  feefeffe feefeffe feefeffe feefeffe
3ffff430:  feefeffe feefeffe feefeffe feefeffe
3ffff440:  feefeffe feefeffe feefeffe feefeffe
3ffff450:  feefeffe feefeffe feefeffe feefeffe
3ffff460:  feefeffe feefeffe feefeffe feefeffe
3ffff470:  feefeffe feefeffe feefeffe feefeffe
3ffff480:  feefeffe feefeffe feefeffe feefeffe
3ffff490:  feefeffe feefeffe feefeffe feefeffe
3ffff4a0:  feefeffe feefeffe feefeffe feefeffe
3ffff4b0:  feefeffe feefeffe feefeffe feefeffe
3ffff4c0:  feefeffe feefeffe feefeffe feefeffe
3ffff4d0:  feefeffe feefeffe feefeffe feefeffe
3ffff4e0:  feefeffe feefeffe feefeffe feefeffe
3ffff4f0:  feefeffe feefeffe feefeffe feefeffe
3ffff500:  feefeffe feefeffe feefeffe feefeffe
3ffff510:  feefeffe feefeffe feefeffe feefeffe
3ffff520:  feefeffe feefeffe feefeffe feefeffe
3ffff530:  feefeffe feefeffe feefeffe feefeffe
3ffff540:  feefeffe feefeffe feefeffe feefeffe
3ffff550:  feefeffe feefeffe feefeffe feefeffe
3ffff560:  feefeffe feefeffe feefeffe feefeffe
3ffff570:  feefeffe feefeffe feefeffe feefeffe
3ffff580:  feefeffe feefeffe feefeffe feefeffe
3ffff590:  feefeffe feefeffe feefeffe feefeffe
3ffff5a0:  feefeffe feefeffe feefeffe feefeffe
3ffff5b0:  feefeffe feefeffe feefeffe feefeffe
3ffff5c0:  feefeffe feefeffe feefeffe feefeffe
3ffff5d0:  feefeffe feefeffe feefeffe feefeffe
3ffff5e0:  feefeffe feefeffe feefeffe feefeffe
3ffff5f0:  feefeffe feefeffe feefeffe feefeffe
3ffff600:  feefeffe feefeffe feefeffe feefeffe
3ffff610:  feefeffe feefeffe feefeffe feefeffe
3ffff620:  feefeffe feefeffe feefeffe feefeffe
3ffff630:  feefeffe feefeffe feefeffe feefeffe
3ffff640:  feefeffe feefeffe feefeffe feefeffe
3ffff650:  feefeffe feefeffe feefeffe feefeffe
3ffff660:  feefeffe feefeffe feefeffe feefeffe
3ffff670:  feefeffe feefeffe feefeffe feefeffe
3ffff680:  feefeffe feefeffe feefeffe feefeffe
3ffff690:  feefeffe feefeffe feefeffe feefeffe
3ffff6a0:  feefeffe feefeffe feefeffe feefeffe
3ffff6b0:  feefeffe feefeffe feefeffe feefeffe
3ffff6c0:  feefeffe feefeffe feefeffe feefeffe
3ffff6d0:  feefeffe feefeffe feefeffe feefeffe
3ffff6e0:  feefeffe feefeffe feefeffe feefeffe
3ffff6f0:  feefeffe feefeffe feefeffe feefeffe
3ffff700:  feefeffe feefeffe feefeffe feefeffe
3ffff710:  feefeffe feefeffe feefeffe feefeffe
3ffff720:  feefeffe feefeffe feefeffe feefeffe
3ffff730:  feefeffe feefeffe feefeffe feefeffe
3ffff740:  feefeffe feefeffe feefeffe feefeffe
3ffff750:  feefeffe feefeffe feefeffe feefeffe
3ffff760:  feefeffe feefeffe feefeffe feefeffe
3ffff770:  feefeffe feefeffe feefeffe feefeffe
3ffff780:  feefeffe feefeffe feefeffe feefeffe
3ffff790:  feefeffe feefeffe feefeffe feefeffe
3ffff7a0:  feefeffe feefeffe feefeffe feefeffe
3ffff7b0:  feefeffe feefeffe feefeffe feefeffe
3ffff7c0:  feefeffe feefeffe feefeffe feefeffe
3ffff7d0:  feefeffe feefeffe feefeffe feefeffe
3ffff7e0:  feefeffe feefeffe feefeffe feefeffe
3ffff7f0:  feefeffe 00000000 feefeffe 00000100
3ffff800:  000000d0 00000000 40105385 00000100
3ffff810:  000000d0 00000000 40105385 000000ee
3ffff820:  00000129 00000001 40105385 3ffed7f8
3ffff830:  3ffed780 00000001 40105385 3ffed7f8
3ffff840:  3ffe9635 40105437 3ffed0c0 00000100
3ffff850:  00000005 00000000 00000020 401001c8
3ffff860:  00007fff 00000000 00000005 000000fe
3ffff870:  0000005c 00000001 40105385 3ffed7f8
3ffff880:  3ffed780 3ffed020 401033c2 00000100
3ffff890:  00007fff 01698d04 3ffed9c0 40102f08
3ffff8a0:  40104f6a 3ffed7f8 00000000 401001c8
3ffff8b0:  00007fff 401048b9 3ffed7f8 00000100
3ffff8c0:  3ffe9ec8 7fffffff 00002200 00000001
3ffff8d0:  40104e6d 3ffed7f8 3ffeccd8 00040000
3ffff8e0:  53002200 00000030 00000005 401021a0
3ffff8f0:  40105145 00080000 00000002 3fffc278
3ffff900:  40103412 3ffed0c0 00000022 00000014
3ffff910:  00007fff 00000000 3ffed9c0 40102f08
3ffff920:  3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffff930:  401030e4 3fffc200 00000022 00000100
3ffff940:  40219018 00000030 00000010 ffffffff
3ffff950:  40219013 00000030 00303032 3ffffc52
3ffff960:  00000003 00000003 4021b6bc 3ffffba0
3ffff970:  00000000 00000000 3ffffb33 3ffffc50
3ffff980:  3ffffc50 00000002 00000003 00000030
3ffff990:  40245675 00000030 00000010 ffffffff
3ffff9a0:  00002000 00000000 3ffed480 00000020
3ffff9b0:  3ffed4a0 00000042 3fff353e 0000008a
3ffff9c0:  00000002 00000000 0000000a 00000000
3ffff9d0:  00000002 00000000 40243d2f 00000000
3ffff9e0:  ffffffff 00000000 3ffe9781 00000000
3ffff9f0:  40243d7e 3ffeccd8 3ffefb6c 00000001
3ffffa00:  40243e8a 3ffeccd8 3ffefb6c 3ffeccd8
3ffffa10:  00000005 00000005 00000008 3fff3620
3ffffa20:  3ffe9632 40242e3b 3ffeccd8 3fff3604
3ffffa30:  00000000 4022c477 3ffee120 3ffefb6c
3ffffa40:  00000000 00000002 00000000 3ffeccd8
3ffffa50:  3fff363a 40105a7b 3fff1f0c 3ffef57c
3ffffa60:  3ffefe14 00000000 3ffffba0 4021b780
3ffffa70:  4021b6bc 4021d7e5 3fff1f0c 3ffef57c
3ffffa80:  00000005 00000000 00000020 401001c8
3ffffa90:  3ffffb2f 00000000 00000005 401021a0
3ffffaa0:  3ffe9635 40105437 3ffed020 4021da13
3ffffab0:  40102d2b 3ffed020 00000000 4021de6e
3ffffac0:  fffffff5 3000f717 3ffed96c 40102f08
3ffffad0:  3ffe9ed4 00000000 00000000 3ffef8b0
3ffffae0:  fffffff5 3000f717 401033c2 00000100
3ffffaf0:  3ffe9ed4 7fffffff 00002200 00000001
3ffffb00:  00000001 00000080 00302064 3ffe8368
3ffffb10:  3ffe9ed4 00000000 0000001f 3000f717
3ffffb20:  3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffb30:  401030e4 3fffc200 00000022 401001c8
3ffffb40:  402120b4 00000030 00000008 ffffffff
3ffffb50:  40213564 000c3500 00000647 13a71553
3ffffb60:  00000003 4020eb18 0000007f 00000080
3ffffb70:  000000b0 3fffc6fc 00000001 3ffffc91
3ffffb80:  00000003 00000000 fffffffc 00000030
3ffffb90:  fffffff5 2f5066c1 401033c2 00000100
3ffffba0:  3ffe9ed4 7fffffff 00002200 00000001
3ffffbb0:  00000001 00000080 3ffed020 401001c8
3ffffbc0:  3ffe9ed4 3ffed020 3fffc228 2f5066c1
3ffffbd0:  3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffbe0:  401030e4 3fffc200 00000022 ffffffff
3ffffbf0:  4021353d 00000030 00000010 ffffffff
3ffffc00:  00000000 00000002 3ffffc51 40213564
3ffffc10:  3ffffc52 4020eb18 3fffc228 40105cd1
3ffffc20:  00000000 00000000 0000001f 401001c8
3ffffc30:  00000002 40252c3c 3fffc228 40105cd1
3ffffc40:  4000050c 40252c3c 00000000 4020fce0
3ffffc50:  402023ad 00000030 0000001c ffffffff
3ffffc60:  402023aa 0000002f 00000013 00000190
3ffffc70:  60000120 00000000 0000007f 00000080
3ffffc80:  00000000 3ffe87fc 0000a7f0 3fff12b8
3ffffc90:  0000000b 3fff12e0 3fff12a4 00000030
3ffffca0:  40100348 00000000 00000004 401010e8
3ffffcb0:  40100348 00000000 00000004 401010e8
3ffffcc0:  40100348 00000000 00000004 401010e8
3ffffcd0:  40100348 00000001 00000004 401010e8
3ffffce0:  00000005 00000000 00000020 401001c8
3ffffcf0:  40100348 00000022 00000005 401021a0
3ffffd00:  3ffe9635 40105437 3ffed020 4020c230
3ffffd10:  40102d2b 3ffed020 0000001f 401001c8
3ffffd20:  00000000 304c3b2f 3ffed9c0 40102f08
3ffffd30:  3ffe9ed4 00000000 00000000 401001c8
3ffffd40:  00000000 304c3b2f 401033c2 00000100
3ffffd50:  3ffe9ed4 7fffffff 00002200 00000001
3ffffd60:  00000001 00000080 3fffc228 40105cd1
3ffffd70:  3ffe9ed4 00000030 00000010 304c3b2f
3ffffd80:  3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffd90:  401030e4 3fffc200 00000022 fffffffe
3ffffda0:  40000671 00000030 00000010 ffffffff
3ffffdb0:  00000000 7d0ada90 0e4bd28b 00000000
3ffffdc0:  00004bc6 7d0ada90 00000000 fffffffe
3ffffdd0:  000033c3 3fffc6fc 2c80da90 304c43d7
3ffffde0:  4bc6a7f0 3ffeec70 3ffef178 00000030
3ffffdf0:  40204d64 00000030 00000010 ffffffff
3ffffe00:  40204d64 3ffef30c 2ade07a0 40237b0d
3ffffe10:  00000000 00000000 00000000 fffffffe
3ffffe20:  ffffffff 3fffc6fc 00000001 3ffef164
3ffffe30:  00000000 00000000 0000001f 401001c8
3ffffe40:  00000000 304aab27 3fffc228 4020b5a2
3ffffe50:  00000001 4bc6a7f0 75c28f5c 0e4bd288
3ffffe60:  00000001 00000000 4bc6a7f0 00000000
3ffffe70:  3ffeec70 00000000 401002dd 00000001
3ffffe80:  000c5d40 00000000 00001388 4020c1c5
3ffffe90:  00000001 4bc6a7f0 7d70a3d7 0e4bd291
3ffffea0:  00000001 00000000 4bc6a7f0 00000000
3ffffeb0:  00000000 00000000 401002dd 00000001
3ffffec0:  000c5d40 3fff12b8 3ffef164 3ffef178
3ffffed0:  3ffeec70 00000000 3ffef164 3ffef178
3ffffee0:  3ffeec70 3ffeef70 3ffef164 40204f7c
3ffffef0:  00000000 3fffdad0 3ffef178 00000030
3fffff00:  00000000 3fffdad0 3ffef178 00000030
3fffff10:  6f697461 feef006e feefeffe 0000effe
3fffff20:  00000000 0023002f 00000000 00000000
3fffff30:  0024002f 00000000 00000000 0017001f
3fffff40:  00000000 00000000 0010001f 00000000
3fffff50:  30372e30 00572030 000000b0 3ffef178
3fffff60:  007a1200 2b2c49c4 00000000 3fff1704
3fffff70:  00000000 3fff16ec 3fff16ec 00000010
3fffff80:  00000000 00000000 00000001 401001c8
3fffff90:  3fffdad0 00000000 3ffef164 401001e9
3fffffa0:  feefeffe feefeffe 3ffef164 4021211a
<<<stack<<<

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

[Ziyat T. (toe_c)]

Daniel R. schrieb:
>

2022-06-29 18:13:17.628811 Transmit 11 | 51 74 40 33 29 78 56 34 
> 12 0b 7c
> 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: d1 74 40 33 29 
> 74 40 33 29 81 50
> Error while retrieving data: unpack requires a buffer of 2 bytes
>

>
> Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten
> nachzusenden?

Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du 
nachzusenden?
nach CMD 0x51 sollte d1:WR|WR:5a:5a:d1 kommen und fertig, danach kommt 
nichts mehr.
Und warum bei dir eine 0x81 kommt verstehe ich nicht.

[Ziyat T. (toe_c)]

@Daniel R.
- nach abs.Leistung limitieren:
SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC

Limitleistung wird mit 1 DEC als int gesendet, zB. 123.4 Watt schickst 
du als 1234, darum hi/low bytes

[Daniel R. (daniel92)]

Nur zu Info ich habe immer noch ein HM.
Aktuell schaut es so aus:

2022-06-29 22:32:05.965908 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24
2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24
2022-06-29 22:32:08.439419 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24

Testweise auch mit 20%

2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32
2022-06-29 22:34:48.077215 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32
2022-06-29 22:34:49.311756 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32
2022-06-29 22:34:50.547037 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32

Bekomme halt kein Recieve.

Ziyat T. schrieb:
> Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du
> nachzusenden?

Ich hab es aus den Infos so verstanden das man erstmal ein Datenpaket 
zum WR schickt. Wenn dieser mit 0x81 Antworter können die nächsten Daten 
raus verschickt werden.

Hatte ich hier im unteren Absatz geschrieben: 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Nur zu Info ich habe immer noch ein HM.
Ja ich weiss, vielleicht gehts ja auch mit HM

> Testweise auch mit 20%
> [code]2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34
> 12 5a 5a 14 01 50 32

Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach 
% willst, musst du nach 0x14 die crc schicken, keine bytes mehr.

>2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01 
50 24

Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte 
0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24 
richtig?

[Daniel R. (daniel92)]

Hallo Ziyat,

erstmal danke das du dir Zeit für mich nimmst! :)


Ziyat T. schrieb:
>> Testweise auch mit 20%
>> 2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34
>> 12 5a 5a 14 01 50 32
>
> Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach
> % willst, musst du nach 0x14 die crc schicken, keine bytes mehr.

Das würde dann bei mir so aussehen:

2022-06-30 05:43:01.828959 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 14 63

Auch hier bekomme ich kein Antwort vom WR.

>>2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01
> 50 24
>
> Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte
> 0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24
> richtig?

Das weiß ich nicht, ich habe bei der CRC Algorithmus nichts geändert.
Nutze von Ahoy die rpi Version. - Wenn ich nur die Daten (DC/AC) vom WR 
Anfordern möchte, geht das ohne Probleme. Daher vermute ich das die CRC 
Berechnung passen wird.

[Stefan T. (isnoahoy)]

Hallo dax,
ja wir beobachten das Problem der ESP8266 Variante schon seit längerem 
mit Argwohn. Wir haben auch schon einige Male einen Stack Trace in 
Github hochgeladen aber außer des/r nun stark optimierten Interrupt 
Handler haben wir bisher noch keinen Plan warum es so häufig zu WDT 
(Watch Dog Timer) Resets kommt.

* Loosing WiFi connection after X minutes #15
https://github.com/grindylow/ahoy/issues/15

hier findet sich auch eine Anleitung verlinkt, nach der Du mit dem 
Binary Deinen Stack Trace decodieren kannst.

* Zeitkritikalität in der Haupt-Loop? #24
https://github.com/grindylow/ahoy/issues/24

hier haben wir uns dem Thema Interrupt und State Machine gewidmet.

* ESP8266: Discussion Verkabelung / Pinout #36
https://github.com/grindylow/ahoy/issues/36

hier hat Lukas P. zuletzt berichtet daß es bei ihm nach Vertauschen (!) 
der Pins für CE und IRQ stabiler lief.

* Stabilität ESP8266 #83
https://github.com/grindylow/ahoy/issues/83

und hier diskutieren wir aktuell ob wir auch an der nRF24 Bibliothek 
Anpassungen vornehmen müssen/sollen.

Alternativ zu den oben genannten Issues kannst Du gerne mal eines der 
anderen "Tools" ausprobieren (z.B. die offenbar problemlos laufende 
Raspberry Pi Variante von Jan-Jonas S., oder Hubi's Code für den 
ESP8266) oder die m.E. sehr saubere ESP32 Implementierung von Thomas B. 
unter https://github.com/tbnobody/OpenDTU

Bei mir steckt der Code m.E. immer wieder in der WebServer Routine fest, 
da er einige Requests beantworten muß und dann stürzt er ab. Das ließe 
sich evtl. durch die AsyncWebServer Variante ersetzen, wie bei OpenDTU ? 
Oder es liegt daran, daß er mit zu häufigen Anfragen an RF24, MQTT und 
WebServer einfach überlastet wird. Er steckt meist in irgendwelchen 
ummalloc Routinen beim WDT Reset und daher vermute ich daß es etwas mit 
dem etwas zu offenherzigen Einsatz der String Klasse zu tun haben 
könnte, hier wird nämlich fleißig vom Flash/Progmem ins RAM kopiert um 
dann wieder an die Adresse des Zielstrings (z.B. beim + / Concatenieren) 
die Einzelstrings zu kopieren. Das kann evtl. auch einige CPU Zyklen 
brauchen.

[Stefan T. (isnoahoy)]

Hallo Ziyat T. & Daniel R.,

ja und ja beim MI-XXXX Wechselrichter heißt das Command 0x51 in 
usart_nrf.c/.h CONTROL_LOCK_MI__LIMIT_POWER_ONOFF und beim 
HM-Wechselrichter wird laut usart_nrf3.c/.h 0x51 als DEVCONTROL_ALL 
definiert.

D.h. das Kommando sieht beim HM-XXXX etwas anders aus nach dem SubCmd.
Bei der Antwort kommt wie Daniel R. bereits geschrieben hat 
ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80) also 0xD1.

Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX 
Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und 
erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL 
(REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden 
SubCmd's definiert als:

typedef enum
{
    InverterDevInform_Simple = 0,
    InverterDevInform_All = 1,
    GridOnProFilePara = 2,
    HardWareConfig = 3,
    SimpleCalibrationPara = 4,
    SystemConfigPara = 5,
    RealTimeRunData_Debug = 11, // 0x0B
    RealTimeRunData_Reality = 12, // 0x0C
    RealTimeRunData_A_Phase = 13, // 0x0D
    RealTimeRunData_B_Phase = 14, // 0x0E
    RealTimeRunData_C_Phase = 15, // 0x0F //�澯����-����δ���͸澯
    AlarmData = 17,  // 0x11 //�澯����-ȫ������澯
    AlarmUpdate = 18, // 0x12
    RecordData = 19, // 0x13
    InternalData = 20, // 0x14
    GetLossRate = 21, // 0x15
    //dong 2020-06-15
    GetSelfCheckState = 30, // 0x1E
    InitDataState = 0xff,

} DataType;

Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum 
Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S. 
hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw 
AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem 
Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter 
hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert 
hatten.

@Daniel R. 0x81, 0x82, 0x84 etc. sind die Paketkennungen des jeweils 
letzten Antwortpaketes auf eine RealTimeRunData_Debug 0x0B SubCmd 
Anfrage gewesen. Dabei wird das SubCmd-Feld in der Antwort durch einen 
Paketzähler ersetzt und beim letzten Paket das Komplement (Paketzähler | 
0x80) mitgeliefert, damit die DTU weiß dass dies das letzte Fragment / 
Paket war.

> 2022-06-29 18:13:17.628811 Transmit 11 | >51< <74 40 33 29> <78 56 34 12> >0b< 
<7c>
> 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: >d1< <74 40 33 29> <74 
40 33 29> >81< <50>

Warum in Deiner Antwort als vorletztes Byte vor der CRC8 der Wert 0x81 
auftaucht: Vielleicht ist es ja die Antwort 1 und als Komplement 
(Antwort | 0x80) = 0x81 ?

Ob das einfach Okay oder gesetzt oder etwas ganz Anderes bedeutet 
müsstest DU anhand der Methoden im usart_nrf(3).c Code mal herausfinden.

[Herbert K. (avr-herbi)]

Stefan T. schrieb:

Danke Stefan T. (isnoahoy) ! Das hatte ich bisher übersehen.

> typedef enum
> {
>     InverterDevInform_Simple = 0,
>     InverterDevInform_All = 1,
>     GridOnProFilePara = 2,
>     HardWareConfig = 3,
>     SimpleCalibrationPara = 4,
>     SystemConfigPara = 5,

>     RealTimeRunData_Debug = 11, // 0x0B

>     RealTimeRunData_Reality = 12, // 0x0C
>     RealTimeRunData_A_Phase = 13, // 0x0D
>     RealTimeRunData_B_Phase = 14, // 0x0E
>     RealTimeRunData_C_Phase = 15, // 0x0F
>     AlarmData = 17,  // 0x11
>     AlarmUpdate = 18, // 0x12
>     RecordData = 19, // 0x13
>     InternalData = 20, // 0x14
>     GetLossRate = 21, // 0x15
>     //dong 2020-06-15
>     GetSelfCheckState = 30, // 0x1E
>     InitDataState = 0xff,

Hallo,
hat jemand auch Payload Beschreibungen für die anderen Antworten ausser
"RealTimeRunData_Debug = 11, // 0x0B"  ?

Hab gerade mal "17=AlarmData" am Laufen über alle WR mit Hubis Uralt 
Code und bekomme zur Zeit je WR bis zu 3 Payloads als Antwort 
(01,02,83).

[Günter H. (gnter_h534)]

Stefan T. schrieb:
> Hallo dax,
> ja wir beobachten das Problem der ESP8266 Variante schon seit längerem
> mit Argwohn.

Mein "Rekord" sind 1 Tag - 18 Std. Betriebszeit ohne Reset (Wemos D1 
mini, separate 3,3V-Versorgung mit entsprechenden Kondensatoren für 
nRF24L01+-Modul). Aber auch immer wieder Resets nach deutlich kürzeren 
Zeitspannen.

Es gibt bei meinem Aufbau Resets, bei denen das System einfach neu 
startet, aber auch "Abstürze", bei denen die Versorgungsspannung 
unterbrochen werden muss, um einen Neustart zu ermöglichen.

Die Probleme mit der Stabilität von Aufbauten mit ESP8266-basierten 
Boards gibt es auch in anderen Projekten, z. B. dieser "Esp8266 Nodemcu 
Gaszähler Thingspeak"; spätestens nach einem Tag war ein Reset notwendig 
(https://fipsok.de/Projekt/gaszaehler-esp8266-nodemcu).

In einem anderen Projekt zur Erfassung des Gasverbrauchs wird 
ausgeführt:
"Mehrere erste Versuche mit nur einem Mikrocontroller vom Typ ESP8266 
waren nicht erfolgreich, weil bei gleichzeitiger Benutzung der Webseite 
leider die Zählimpuls-Erkennung über Interrupt nicht ausreichend 
zuverlässig war. Die aktuelle Lösung verwendet deshalb zusätzlich zum 
verwendeten ESP8266 noch einen ATTINY84 Mikrocontroller für die 
zuverlässige Zählfunktion für insgesamt 4 Kanäle." 
(https://www.stall.biz/project/pulsecounter-2-komfortabel-verbraeuche-von-strom-wasser-gas-und-solar-messen). 
Den Teil mit dem Wemos D1 mini-Board habe ich getestet, er lief stabil. 
Das Projekt habe ich aber nicht weiterverfolgt, weil es Probleme mit der 
Impulserfassung am Gaszähler gab.

Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim 
Kompilieren mit Visual Studio Code und der PlatformIO Extension...

[Thomas B. (tbnobody)]

Günter H. schrieb:
> Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim
> Kompilieren mit Visual Studio Code und der PlatformIO Extension...

Hallo Günter,
Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was 
passiert nicht?

[Claus T. (Gast)]

Hallo,
inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich 
mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN 
konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen.
Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die 
HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung 
für den TSUN dabei?
Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an 
meiner ESP-Verkabelung.
Muss man für die WR-Hardware in der SW vor dem compilieren noch was 
ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt.
Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier 
der Auszug der serial-Konsole:

10:43:56.941 -> ...............................
10:44:01.668 -> I: add inverter: MI-800, SN: 11417xxxxxxxx
10:44:04.451 -> I: RF24 Amp Pwr: RF24_PA_MIN
10:44:04.451 -> I: Radio Config:
10:44:04.451 -> SPI Frequency        = 1 Mhz
10:44:04.451 -> Channel            = 3 (~ 2403 MHz)
10:44:04.451 -> RF Data Rate        = 250 KBPS
10:44:04.451 -> RF Power Amplifier    = PA_MIN
10:44:04.451 -> RF Low Noise Amplifier    = Enabled
10:44:04.451 -> CRC Length        = 16 bits
10:44:04.451 -> Address Length        = 5 bytes
10:44:04.451 -> Static Payload Length    = 32 bytes
10:44:04.451 -> Auto Retry Delay    = 250 microseconds
10:44:04.483 -> Auto Retry Attempts    = 0 maximum
10:44:04.483 -> Packets lost on
10:44:04.483 ->     current channel    = 0
10:44:04.483 -> Retry attempts made for
10:44:04.483 ->     last transmission    = 0
10:44:04.483 -> Multicast        = Disabled
10:44:04.483 -> Custom ACK Payload    = Disabled
10:44:04.483 -> Dynamic Payloads    = Enabled
10:44:04.483 -> Auto Acknowledgment    = Disabled
10:44:04.483 -> Primary Mode        = RX
10:44:04.483 -> TX address        = 0xdeadbeef01
10:44:04.483 -> pipe 0 (closed) bound    = 0xdeadbeef01
10:44:04.483 -> pipe 1 ( open ) bound    = 0x1234567801
10:44:04.520 -> pipe 2 (closed) bound    = 0xc3
10:44:04.520 -> pipe 3 (closed) bound    = 0xc4
10:44:04.520 -> pipe 4 (closed) bound    = 0xc5
10:44:04.520 -> pipe 5 (closed) bound    = 0xc6
10:44:04.520 -> I:
10:44:04.520 ->
10:44:04.520 -> ----------------------------------------
10:44:04.520 -> I: Welcome to AHOY!
10:44:04.520 -> I:
10:44:04.520 -> point your browser to http://192.168.10.229
10:44:04.520 -> I: to configure your device
10:44:04.520 -> I: ----------------------------------------
10:44:04.520 ->
10:44:10.573 -> I: [NTP]: 2022-06-30 10:44:04

Auf der Website kommt die Fehlermeldung
…Receive failed…
Inverter 1 not (correctly) configured
Inverter 2 not (correctly) configured

Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert 
und ob der TSUN schon unterstützt wird.
Danke.
Grüße
Claus T.

[Daniel R. (daniel92)]

Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung 
ist mir was aufgefallen und denke es ist für die neue Generation 
verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine 
Abfrage ob es sich um eine DTU3PRO handelt.
Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein 
"DRM_Limit_Switch; //DRM power limit".

Für mich ist das ein Indikator das es ein Flag im System zu setzen ist, 
das aussagt ob eine Limitierung nun erlaubt sei oder nicht.
Dies bezüglich habe in der *.c Datei geschaut und siehe da, in der 
Funktion (Zeile 1717) eine "UsartNrf_Send_PackSetPowerLimitCommand":

Hier zeigt sich im Speicher der DTU abgefragt wird, ob der WR sich in 
einem gewissen Zustand ist.

if((Dtu3Detail.Property.Zero_Export_Switch == 1) || (Dtu3Detail.Property.DRM_Limit_Switch == 1) || (Dtu3Detail.Property.Phase_Balance_Switch == 1) || (Dtu3Detail.Property.SunSpec_Switch == 1))
    {
        if(MIMajor[PortNO].Property.Acq_Switch == 0)
        { ...

Ist dieser 0, dann wird folgender Befehl abgeschickt:

//1000w shutdown Micro-inverse control of 1-to-4 with the last 8 digits of the special control ID less than 0x50000000
            if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
            {
                temp_dat[9]  = (u8)(SubCmd  >> 8);      //5a5a
                temp_dat[10] = (u8)(SubCmd & 0XFF);
                temp_dat[11] = 11;
                //                  temp = 35*4*10=1400=0x0578;
                temp_dat[12] = 0X05;
                temp_dat[13] = 0X78;
                temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC
                i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution
            }
            else
            {
                temp_dat[9]  = (u8)(CONTROL_OFF_SUB >> 8);      //5a5a
                temp_dat[10] = (u8)(CONTROL_OFF_SUB & 0XFF);
                temp_dat[11] = Get_crc_xor((u8 *)&temp_dat[0], 11); //CRC
                i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 12); //forward substitution
            }

Wenn nicht dann:

temp_dat[9]  = (u8)(SubCmd  >> 8);      //5a5a
            temp_dat[10] = (u8)(SubCmd & 0XFF);
            temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage
            temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8);    //High 8-bit power limit
            temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff);            //Low power limit 8 bits
            temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC
            i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution

Interessant ist, wenn alles nicht zutrifft wird folgendes verschickt:

temp_dat[9]  = (u8)(SubCmd >> 8);      //5a5a
        temp_dat[10] = (u8)(SubCmd & 0XFF);
        temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage
        temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8);    //High 8-bit power limit
        temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff);            //Low power limit 8 bits
        temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC
        i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution

Ich werde mal das ganze weiter anschauen und probieren.

EDIT:

5A 5A FF <[Property.Power_Limit * 10 / (300 * 
(UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))]> [H 
8-bit P limit] [LP limit 8 bits] CRC

[Josef J. (jauntyjosef)]

Stefan T. schrieb:
> Das könnte auch eine Ursache sein, probier das doch mal aus bzw.
> überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten
> Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und
> Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default
> Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte:
> https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584

Vielen herzlichen Dank!
Darin befindet sich die Lösung. Jetzt funktioniert. Musste CE und IRQ 
vertauschen. (also nicht nach dem Schaltbild, das auf GitHub ist!)

Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem 
darstellen.

Jetzt kämpfe ich nur noch mit Wlan Problemen. Bei mehr als 3-4 Meter 
Entfernung von Wlan Router, bricht die Verbindung in unregelmäßigen 
Abständen ab (meist aber schon nach 4-5 Sekunden). Habe schon 
verschiedene Netzteile und Kabel getestet und mit Kondensatoren 
experimentiert. Werde jedenfalls noch weiter testen.

[Günter H. (gnter_h534)]

Thomas B. schrieb:
> Hallo Günter,
> Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was
> passiert nicht?

Danke für die Rückmeldung. Vorweg: Ich bin "kein Programmierer". Bekomme 
die Arduino IDE (gerade so) zum Laufen.

PC mit Windows 10 Pro 21H2

Installation von Visual Studio Code und der PlatformIO Extension 
innerhalb Visual Studio Code problemlos, Source Code als zip-Datei 
heruntergeladen, entpackt und platformio.ini geöffnet, upload_port und 
monitor_port angepasst.

Dann "PlatformIO: Upload" angeklickt - danach kamen die Fehlermeldungen, 
s. Anhänge. Die Zahlen sollen die zeitliche Reihenfolge widerspiegeln.

Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0 
für Windows" heruntergeladen und installiert. Weiter als zur 
Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen.

Gruß Günter

[Thomas B. (tbnobody)]

Günter H. schrieb:
> Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0
> für Windows" heruntergeladen und installiert. Weiter als zur
> Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen.

Hallo Günter,

du bist dann in das gleiche Problem gelaufen wie hier: 
https://github.com/tbnobody/OpenDTU/issues/3

Ich werde heute Abend noch eine Ausnahme implementieren, damit man den 
Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP 
heruntergeladen hat.

[Daniel R. (daniel92)]

Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord 
umzuleiten?

Da hier auch über andere Themen gesprochen werden die für das Projekt 
relevant sind, würde ich vorschlagen statt ein seperaten Thread 
aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier 
bleiben?

Nur eine Idee. :)

[Daniel M. (daniel_m821)]

Claus T. schrieb:
> Hallo,
> inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich
> mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN
> konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen.
> Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die
> HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung
> für den TSUN dabei?

> Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an
> meiner ESP-Verkabelung.
> Muss man für die WR-Hardware in der SW vor dem compilieren noch was
> ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt.
> Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier
> der Auszug der serial-Konsole:

> Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert
> und ob der TSUN schon unterstützt wird.
> Danke.
> Grüße
> Claus T.

Hallo Claus,
ich bin der mit dem TSOL-M800 (MI-700 Klon).
Es gibt noch MI-1500 und 1200, die etwas andere Abfragen starten.

Meine Version ist nicht annähernd lauffähig, teilweise instabil und eher 
unkomminikativ, allerdings ist deine Verkabelung ect. soweit ok.

Die älteren MI werden noch nicht unterstützt, ist allerdings in der 
Mache.

Bitte hab etwas Geduld. Ich schaue mal, dass ich meine Version zu github 
hochlade, wenn sie etwas besser läuft. Aktuell modifiziere ich noch 
dran.

Ggf. kann Daniel R. oder Ziyat eine Testversion für den MI auf dem D1 
Mini bereitstellen, die besser anzupassen ist.

Wie gesagt, etwas Geduld :)

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord
> umzuleiten?
>
> Da hier auch über andere Themen gesprochen werden die für das Projekt
> relevant sind, würde ich vorschlagen statt ein seperaten Thread
> aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier
> bleiben?
>
> Nur eine Idee. :)

Moin,

wenn du einen Einladungslink zu einem Server hast, komme ich gerne dazu 
:)

lg

[Daniel R. (daniel92)]

Discord Link habe ich via PM raus geschickt. :)

[Claus T. (Gast)]

Hallo Daniel,
danke für die Info, schön zu hören, dass meine HW funktioniert, dann 
bleibe ich weiter geduldig :-)
Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner 
nicht mit 1041… begonnen?
Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi 
hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben 
anschmeißen.
Grüße
Claus T.

[Thomas B. (tbnobody)]

Claus T. schrieb:
> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner
> nicht mit 1041… begonnen?

Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe 
sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders 
belegt?

[Ziyat T. (toe_c)]

Josef J. schrieb:

> Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem
> darstellen.
>
Doch, weil deine DTU-Pro dauernd den WR abfragt, sendet der WR antworten 
zu DTU-Pro.
Wenn du in deinem esp-ahoy die gleiche Adresse hast wie die DTU-Pro, 
wirst du nie wissen ob das esp-ahoy den WR abfragt, bzw. das Senden 
erfolgreich ist. Du bekommst die WR Antworten zu DTU-Pro gratis mit.

[Daniel R. (daniel92)]

Habe im usart-code was interessantes gefunden.
Kann jemand entschlüsseln was das seien könnte?

    //u8 Uart_SendBuffer1[] = {0x7e, 0x15, 0x50, 0x80, 0x55, 0x56, 0x50, 
0x80, 0x55, 0x56, 0x80, 0x02, 0x00, 0x5E, 0x04, 0x7D, 0x5E, 0x2A, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5B, 0x10, 0xD2, 0x7f};
    //u8 Uart_SendBuffer1[] = 
{0x7e,0x15,0x50,0x80,0x55,0x55,0x50,0x80,0x55,0x55,0x80,0x12,0x00,0x00,0 
x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x13,0xb9,0x2d,0x7 
f};

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung
> ist mir was aufgefallen und denke es ist für die neue Generation
> verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine
> Abfrage ob es sich um eine DTU3PRO handelt.
> Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein
> "DRM_Limit_Switch; //DRM power limit".
>

Eigenlich alles steht im RF_communication_protocol-V6.5.xlsx.
Es gibt folg Limitierungen in der Praxis:
- zero export: prozentual oder absolut Wert der Nenneistung, gesteuert 
in Verbindung mit einem Modbus Smart-Meter
- Fest limiterte WR: prozentual oder absolut Wert der Nenneistung, 
eingegeben im smiles-cloud
-DRM(Demand Response Mode): der WR wird vom Gridanbieter kontrolliert 
off/0%/50%/no limit.z.B in Australien, in der EU weiss nicht. Es wird 
über die DTU-Pro, mit RS485(Modbus oder Sunspec) oder mit einem DRM-Port 
direkt kommuniziert.

[Richard K. (laserrichi)]

Thomas B. schrieb:
> Claus T. schrieb:
>> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner
>> nicht mit 1041… begonnen?
>
> Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe
> sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders
> belegt?

Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 
los und monitore das schon eine ganze Weile.

[Daniel M. (daniel_m821)]

Claus T. schrieb:
> Hallo Daniel,
> danke für die Info, schön zu hören, dass meine HW funktioniert, dann
> bleibe ich weiter geduldig :-)
> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner
> nicht mit 1041… begonnen?
> Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi
> hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben
> anschmeißen.
> Grüße
> Claus T.

Sehr interessant. Meiner hat mit 1041 begonnen, ja.
Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen 
einzutragen.

Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es 
bringt was raus.

Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das 
geht.

Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren.
https://github.com/tbnobody/OpenDTU
Allerdings ist es auch bisher nur für die HM-Serie.

lg

[Daniel M. (daniel_m821)]

Richard K. schrieb:
> Thomas B. schrieb:
>> Claus T. schrieb:
>>> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner
>>> nicht mit 1041… begonnen?
>>
>> Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe
>> sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders
>> belegt?
>
> Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141
> los und monitore das schon eine ganze Weile.

Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein 
umgelabelter HM-Serie?
Ich trau den Chinesen alles zu ;)

[Günter H. (gnter_h534)]

Thomas B. schrieb:
> Hallo Günter,
>
> du bist dann in das gleiche Problem gelaufen wie hier:
> https://github.com/tbnobody/OpenDTU/issues/3
>
> Ich werde heute Abend noch eine Ausnahme implementieren, damit man den
> Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP
> heruntergeladen hat.

Hallo Thomas,

nach deinem Hinweis konnte ich den git clone herunterladen - frage bitte 
nicht, wie das letztlich gelungen ist.

Wie auch immer: Das System arbeitet perfekt (HM600), über die Stabilität 
kann ich naturgemäß noch keine Angaben machen.

[Claus T. (Gast)]

Hallo Daniel,

Daniel M. schrieb:
> Sehr interessant. Meiner hat mit 1041 begonnen, ja.
> Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen
> einzutragen.
Ich habe am meinem TSOL-M800 an jedem der beiden MPPT-Eingängen ein 
370Wp Modul angeschlossen, also beide Inverter laufen. So habe ich sie 
auch in der ahoy-SW eingetragen, bei
Inverter
Inverter 0
AddressNameMax Module Power (Wp) 440 440
Module Name  CS3L-370 CS3L-370
Inverter 1
Alles weitere leer.
Und jetzt noch getestet, die beiden rechten Felder gelöscht.
AddressNameMax Module Power (Wp) 440 0
Module Name  CS3L-370
Bringt aber auch nix, wobei die Rechte Module Power wird automatisch 0.

>
> Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es
> bringt was raus.
>
> Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das
> geht.
Gut, dann kann ich die testen.

>
> Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren.
> https://github.com/tbnobody/OpenDTU
> Allerdings ist es auch bisher nur für die HM-Serie.
Und dafür muss ich VisualStudio mit PlatformIO installieren, was ich 
schon mal für ein anderes Projekt probiert hatte und gescheitert bin. 
Ist aber ein Grund für einen neuen Versuch :-)

Die Art des WR wird bei ahoy über die Seriennummer erkannt?

[Thomas B. (tbnobody)]

Claus T. schrieb:
> Ist aber ein Grund für einen neuen Versuch :-)
Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur 
ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS 
Code installieren und die PlatformIO Extension zu laden)

Claus T. schrieb:
> Die Art des WR wird bei ahoy über die Seriennummer erkannt?
Genau. Wie in allen anderen Implementierungen aktuell auch. Die 
Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht 
eindeutig (siehe 
https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx)

[Hans W. (hans_w801)]

Holger S. schrieb:
> Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x
> Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch
> rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den
> China Wemos Clones liegt.
>
> Leider bekomme ich damit auch keine mehrstündigen Uptimes hin.
> Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber
> irgendwie muß man das doch sauber zum laufen bekommen.
>
> Läuft das bei euch über Tage ohne Reboot ???

Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger 
als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert 
auch keine Daten mehr. Hilft nur noch ein reboot...

[DerUnbekannteMann (Gast)]

Hans W. schrieb:
> Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger
> als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert
> auch keine Daten mehr. Hilft nur noch ein reboot...

Betreibe einen NodeMCU mit rf-Modul ohne Cap mit ahoy an meinem HM-800 
seit mittlerweile > 3 Wochen ohne Reboot. Großartige Arbeit übrigens @ 
Dev's!

[Richard K. (laserrichi)]

Daniel M. schrieb:

>> Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141
>> los und monitore das schon eine ganze Weile.
>
> Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein
> umgelabelter HM-Serie?
> Ich trau den Chinesen alles zu ;)

Ja da steht wirklich TSUN  TSOL-M800 drauf, und die 1141 passt auch zu 
dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau 
612W scheinbar begrenzt.
Hab die Version 0.4.19 am laufen.

Für alle die reboots haben, stellt mal das Intervall von 5 sekunden 
einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5 
Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es 
damit zusammen.

[Daniel R. (daniel92)]

> Ja da steht wirklich TSUN  TSOL-M800 drauf, und die 1141 passt auch zu
> dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau
> 612W scheinbar begrenzt.
> Hab die Version 0.4.19 am laufen.

Laut Datenblatt hat es eine Spitzenwirkungsgrad des Wechselrichters von 
etwa 96,7%. Ich glaub meine Rechnung ist falsch aber wenn ich das ganze 
Überschlage, sollte etwa folgendes raus kommen:

370W*2= 740W
(740W/100) * 96,7 = 715,58WAC ?

Für mich heißt es das lt. Rechnung 84,42W fehlen und nach deinen Angaben 
sogar 188W fehlen. Wenn wir noch bei beiden ca. 20-50W mal für Toleranz 
abziehen (pi*Daume) dann fehlen bei dir trotzdem gute 130W.

Hmm, eventuell wurde hier falsche Firmware oder wie du gesagt hast schon 
vorab begrenzt. - Keine Ahnung... :/


> Für alle die reboots haben, stellt mal das Intervall von 5 sekunden
> einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5
> Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es
> damit zusammen.

Das sollte man eventuell mal sich merken/Anpinnen. Glaube das hatte 
bisher keiner im Verdacht? :)

[Richard K. (laserrichi)]

Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft 
worden.
Und das tut der auch brav. Ich habe das beim Aufzeichnen auch so 
festgestellt.
Ob dieser das jetzt auf Einspeiseleistung macht oder auf Panelleistung 
kann man so nicht sagen, denn ich sehe eine harte Begrenzung bei beidem.

Im Anhang sieht man das an dem aufgezeichneten Tag immer wieder mal die 
Sonne weg war wegen einzelnen Wolken, dann ist ja das Panel kühler und 
wenn die volle Bestrahlung kommt dann liefern die Panels auch mehr 
Leistung.
Und da sieht man ganz deutlich das die Leistung gedeckelt ist.

Und ich würde behaupten das diese Serie evtl. auch in der Begrenzung 
regelbar ist, oder es ist in der Firmware schon so begrenzt.

[Andi_Solar (Gast)]

Hallo zusammen

Über die Suche im WWW bin ich auf diesen  Thread gestossen. Ich bin 
überrascht wieviele Leute es doch gibt, die sich gegen ein 
"Fremdüberwachungscloud" gibt und wieviel Aufwand und Arbeit da 
reingesteckt wird. Vielen Dank dafür.

Seit kurzem läuft bei mir auch ein HM-600 mit einem Stick DTU, den ich 
aber nur leihweise habe.
Wenn ich das ganze hier richtig verstanden habe, gibt es hier 3 
Varianten? Welche Variante ist die mir der ich am sichersten die Daten 
in den Iobroker bringe?
Ich bin kein Softwaremensch, ein ESP oder Arduino flashen geht, aber 
sobald es um komplexe Software geht weiss ich nicht mehr weiter. Darum 
die Frage.

Gruss Andi

[Daniel R. (daniel92)]

Richard K. schrieb:
> Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft
> worden.

An sich kann man die alle regeln, da schon festgestellt wurde das TSUN 
eine kopie von Hoymiles ist. :)
Da an sich Zero-Export funktion auch noch möglich ist müssen die sich 
regeln lassen können.

Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter 
hoch treiben. ;)

@Andi: An sich kommt alles drauf an. Wenn du bereits ein Raspi hast und 
der 24/7 läuft würde ich denn nutzen. Wenn du aber ein ESP8266/32 in der 
Schublade hast, kann man denn auch gut nutzen. Bei allen jedoch ist ein 
NRF24L01+ nötig.

Sollte aber alles auf Github stehen: https://github.com/grindylow/ahoy/

PS: Du kannst bei allen via MQTT auf iobroker dann legen. ;)

[Andi_Solar (Gast)]

Hallo Daniel
Danke für die Hinweise. Mein Problem besteht darin, dass mein Englisch 
sehr schlecht ist und sich leider nicht immer alles sinnvoll übersetzen 
lässt.
Als Controller liegt alles bei mir rum, Rpi, ESP8266 und ESP32 als Wemos 
D1 mini. Dann organisiere ich mir mal den NRF... und beginne mal zu 
testen.

Die ESP Varianten sind mir sympatisch, den die brauchen dann keine 
Software Support mehr wenn es mal läuft. Rpi ist da halt etwas 
aufwändiger. Mein Iobroker läuft als Multihost auch auf Rpi CPU. Aber 
eben im Keller und dort geht die DTU eben nicht.

Gruss Andi

[Daniel R. (daniel92)]

Ist zwar Off-Topic, aber du könntest ja dann einfach ein ESP nehmen und 
das irgendwo in der Mitte zwischen WR und deinem Router einspannen. ;)

[Andi_Solar (Gast)]

Wie meinst du "einspannen"?

Als ich denke mir das ich einen ESP nehme und denn einfach an Stelle der 
DTU verwenden kann?

[Daniel R. (daniel92)]

Einspannen, dazwischen schalten, in dein Netzwerk joinen lassen... :D

Richtig, der ESP emuliert einfach die DTU.

[Karl-heinz S. (cletus)]

Zuerst einmal: Vielen Dank für eure Arbeit!

Ich habe mir auch vom Makershop einen NRF24L01+ PA und einen Wemos D1 
Mini geholt, geflashed und angeschlossen.

Aber er empfängt leider keine Daten vom WR. Ich habe das PinOut zweimal 
geprüft - auch IRQ/CE.

Muss ich den WR selber noch überreden, dass er sendet? Habe ich etwas 
vergessen in der Firmware zu aktivieren (Muss dort Channel Hopping an 
oder aus sein?)

Gibt es irgendwo eine Anleitung zum systematischen Debugging, z.B. ob 
das NF24-Modul überhaupt antwortet bzw. betriebsbereit ist?

EDIT: HAT sich erledigt. Ich habe keine Ahnung, was sich geändert hat, 
aber nach dem aktivieren des Loggings, dem richtigen Raten der Baudrate 
(115200) und dem connecten mit screen läuft es nun.

[Silvio R. (silre)]

Hallo zusammen,

ich habe meinen WemosD1Mini nun schon eine ganze Weile mit meinem HM700 
am laufen. Soweit funktioniert das auch, jedoch hatte ich jetzt versucht 
ihn per mqtt mit iobroker zu verbinden aber irgendwie kann er sich nicht 
mit dem mqtt Server verbinden.
Die Anmeldedaten sind jedoch definitiv korrekt aber eine Verbindung 
schlägt fehlt.
Jetzt wollte ich ein OTA Update (aktuelle Version 0.3.3) durchführen und 
frage mich aber wo ich die dafür benötigten Files finde.
Unter https://github.com/grindylow/ahoy konnte ich irgendwie nichts 
finden.
Wäre super wenn ihr mir weiterhelfen könntet, vielleicht sehe ich ja den 
Wald vor lauter Bäumen nicht.

EDIT: Hat sich erledigt. Hab eben gesehen, dass die BIN Files hier im 
Thread zur Verfügung gestellt werden.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Richard K. schrieb:
>> Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft
>> worden.
>
> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter
> hoch treiben. ;)

Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit 
einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. 
Bin gespannt ob es geht.

[Claus T. (Gast)]

Hallo Thomas,

Thomas B. schrieb:
> Claus T. schrieb:
>> Ist aber ein Grund für einen neuen Versuch :-)
Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal 
mit Erfolg.

> Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur
> ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS
> Code installieren und die PlatformIO Extension zu laden)
Ich hab’s auf meinem MacBookAir installiert, deine Anleitung hat aber 
trotzdem sehr gut geholfen. Musste noch Python 3.10 und git 
installieren.
Als serielle Schnittstelle muss man am Mac statt COM4 
/dev/cu.usbserial-1410 eingeben. Wobei das vom ESP32-USB-Chip abhängig 
ist.

>
> Claus T. schrieb:
>> Die Art des WR wird bei ahoy über die Seriennummer erkannt?
> Genau. Wie in allen anderen Implementierungen aktuell auch. Die
> Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht
> eindeutig (siehe
> https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx)
Nachdem ich unter Settings das Netzwerk und die Seriennummer meines 
Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann 
auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei 
VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32 
etwas bewegt hatte, kam auch ein „success“. Super! :-)

Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der 
Empfang nicht ganz durch die Hauswand.
Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut.

Der Wechselrichter wird als HM-600, HM-700, HM-800 erkannt, was anhand 
der Seriennummer 11417… zu erwarten war, und empfängt sauber alle Daten.

Mein TSUN TSOL-M800 ist also kein MI-xxx, sondern ein HM-6/7/800.

Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des 
Hauses keine Daten.

Dank an alle, die das Projekt schon so weit gebracht haben.
lg
Claus T.

[Herbert K. (avr-herbi)]

Oliver F. schrieb:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
...
> Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die
> erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren
> bin.

Hallo Oliver,
was ist aus dem ESP32 mit 6 x nRF Modulen denn geworden ?  Gibt es da 
Neuigkeiten ?
Viele Grüße Herbert

[Rene M. (Firma: Bitte wählen) (renmo)]

Bei mir funktioniert alles wie es soll, auch MQTT.
Nur habe ich zwischendurch immer 0 Werte bei allen Werten.
Kann man das irgendwie unterbinden?

[Silvio R. (silre)]

Also ich habe jetzt die Version 4.19 geflashed aber leider kann er 
weiterhin keine Verbindung zu mqtt herstellen.
Gibt es Broker seitig etwas zu beachten?
Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im 
Format 192.168.42.101 angegeben.
Muss beim Topic etwas beachtet werden?

[Daniel R. (daniel92)]

Hallo Silvio,

an sich nichts großes.
Probiere mal via MQTTExplorer 
(https://github.com/thomasnordquist/MQTT-Explorer) zu lauschen ob die 
Daten auch empfangen werden.

In den Einstellung bei deinem DTU muss unter MQTT auch passend die Werte 
eingepflegt werden. Denke mal das hast du auch gemacht.

[Daniel M. (daniel_m821)]

Ziyat T. schrieb:
>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter
>> hoch treiben. ;)
>
> Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit
> einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert.
> Bin gespannt ob es geht.

Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden 
können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die 
Settings im WR anpassen kann.

Soweit ich die Installationsanleitungen verstehe, gibt es da Optionen.

In dem Gitee waren auch Hinweise auf dieses "Gridfile", vorwiegend aber 
für die MI-Serie.

Habe heute meinen HM-1500 bekommen und bin gespannt, ob die EU-Version 
(nicht explizit DE) das Limit auf 600W drin hat.

Ahoy-Software hat nach Pintausch auf einem Wemos kurzzeitig 
funktioniert, ich vermute, hier hats einfach durch die Bastelumgebung 
zuviel Störzeug, was überlagert.
Die Version auf dem ESP32 hatte da (wahrscheinlich wegen der Störfelder) 
noch nicht geklappt, ich werde aber damit auch testen.

[Daniel M. (daniel_m821)]

Claus T. schrieb:

> Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal
> mit Erfolg.

Glückwunsch! :)

> Nachdem ich unter Settings das Netzwerk und die Seriennummer meines
> Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann
> auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei
> VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32
> etwas bewegt hatte, kam auch ein „success“. Super! :-)
>
> Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der
> Empfang nicht ganz durch die Hauswand.
> Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut.

Also die Nachfolgerversion meines "alten" MI-Klon.
Wenn du Daten bekommst, ist das super.

> Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des
> Hauses keine Daten.

Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ 
auf D4. Alternativ kannst du auch D8, D2, D1 probieren.

[Daniel M. (daniel_m821)]

Silvio R. schrieb:
> Also ich habe jetzt die Version 4.19 geflashed aber leider kann er
> weiterhin keine Verbindung zu mqtt herstellen.
> Gibt es Broker seitig etwas zu beachten?
> Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im
> Format 192.168.42.101 angegeben.
> Muss beim Topic etwas beachtet werden?

Für die neuere MQTT Version >2.x brauchst du zwingend Username/Passwort, 
außer du konfigurierst den Server entsprechend um.
Sonst ist der Tip mit MQTT.fx oder MQTT Explorer ganz gut zum Schauen.

Normal sollte nichts weiter beachtet werden.

[Josef J. (jauntyjosef)]

Werden die Werte für AC Power eigentlich aufgrund der Werte von DC Power 
errechnet, oder werden diese vom Wechselrichter direkt übertragen?

[Lukas P. (lumapu)]

bei der HM Serie wird AC Power und die einzelnen DC Power der Eingänge 
übertragen.

Die ESP Version errechnet die Gesamt DC Power und daraus wieder den 
Wirkungsgrad.
Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC 
Powermessung sehr genau stimmt.

Mal eine Frage in die Runde: Wie heiß werden eigentlich eure 
Wechselrichter? Gibt es eine Overtemperature Abschaltung?
Ich habe bei mir schon 73°C gesehen. Das passt auch zu meiner 
Vorstellung, dass bei ca. 1.1kW und 95.5% Wirkungsgrad ca. 50W in Wärme 
umgewandelt werden. Man muss dazu sagen, das ich auf zwei Eingängen 
Parallelschaltungen und damit verbunden hohe Ströme habe.

[Thomas B. (tbnobody)]

Lukas P. schrieb:
> Mal eine Frage in die Runde: Wie heiß werden eigentlich eure
> Wechselrichter?

Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500)

[Josef J. (jauntyjosef)]

Lukas P. schrieb:
> bei der HM Serie wird AC Power und die einzelnen DC Power der
> Eingänge übertragen.
> Die ESP Version errechnet die Gesamt DC Power und daraus wieder den
> Wirkungsgrad.
> Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC
> Powermessung sehr genau stimmt.

Vielen Dank. Momentan lese ich noch die Daten via Modbus TCP von der DTU 
Pro aus. Ich denke, dass dies aber die  DC Power sein wird (Laut Doku PV 
Power). Das muss ich mal vergleichen.

Zu den Temperaturen kann ich noch nichts sagen, da ich den WR erst seit 
einer Woche habe.

[Ziyat T. (toe_c)]

Thomas B. schrieb:
> Lukas P. schrieb:
>> Mal eine Frage in die Runde: Wie heiß werden eigentlich eure
>> Wechselrichter?
>
> Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500)

Aussen 38.5C, WR 64.9C

[Ziyat T. (toe_c)]

Daniel M. schrieb:
> Ziyat T. schrieb:
>>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter
>>> hoch treiben. ;)
>>
>> Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit
>> einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert.
>> Bin gespannt ob es geht.
>
> Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden
> können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die
> Settings im WR anpassen kann.

Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Claus T. (Gast)]

Hallo Daniel,

Daniel M. schrieb:
>> Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des
>> Hauses keine Daten.
>
> Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ
> auf D4. Alternativ kannst du auch D8, D2, D1 probieren.

hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3) 
vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png + 
AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den 
ich auch verwende.

Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal 
kontrolliert bzw. angepasst... und es läuft :-)

Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet, 
hat nix geholfen.
Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert.
Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2) 
eingestellt.

Grüße
Claus

[Ziyat T. (toe_c)]

Interrupt und ReceiveChannel

Hallo,
Ich habe von meinem MI-1500 immer wieder keine Daten mehr bekommen, habe 
den Grund untersucht.

- Unbedingt nicht nur auf CH03 hören, mein MI-1500 sendet z.B. heute 
nichts über CH03. Er sendet heute nur über CH61 und CH75 !!

- Wenn ich ohne Interrupt den NRF24 polle, sehe ich mehr Daten

So bekomme schön und regelmaessig Daten vom MI-1500

[Chris (Gast)]

Ich habe bei meinem HM-1500 schon 79°C gesehen. Das kommt mir auch etwas 
viel vor. Ist aber unter den Panels auf einem Flachdach.

[Tom M. (tom_m)]

Ich habe eine HM-1500. Max Temperatur war knapp über 60°C.
Hab jetzt ein kleinen 12V Lüfter davor gestellt mit kleinem Solar Panel. 
Seit dem bin ich bei Max 45°C.



Gruß Tom

[Daniel M. (daniel_m821)]

Hallo Claus,

Claus T. schrieb:
> hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3)
> vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png +
> AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den
> ich auch verwende.

Ich muss nochmal drüber schauen, ich habe auch den Typ im Einsatz.

> Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal
> kontrolliert bzw. angepasst... und es läuft :-)

Wenns läuft, ist top :)
Glückwunsch!

> Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet,
> hat nix geholfen.
> Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert.
> Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2)
> eingestellt.

Ich hab das auch noch nicht ganz verstanden, warum das nicht klappt. Ich 
nutze 2 identische D1 mini, identisch verkabelt und eingerichtet, selbe 
Position und das NRF Modul genauso ausgerichtet, der eine läuft, der 
andere nicht.

[Daniel M. (daniel_m821)]

Ziyat T. schrieb:
> Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe:
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Hallo Ziyat,

ich bin nicht sicher, ob für die HM-Serie ggf. weitere Parameter 
vorgesehen sind. Als die MI-Serie aktuell war, gab es keine Limits in 
der Form (soweit mir bekannt).

Mein HM-1500 (EU-Version) kennt kein 600W Limit. Ahoy auf D1 Mini und 
Thomas seine Version auf ESP32 laufen perfekt.

Mit dem MI-Klon bin ich noch nicht weiter, heute erstmal die 4 Panele 
mit dem HM aufgestellt.

lg
Daniel

[IsnoAhoy (Gast)]

Wegen getauschten Verbindungen des ESP8266 Code von Lukas P., das hat er 
ab Versiom 0.4.20 geändert:
https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584

Jetzt gilt als Default:
CS = D8(GPIO15)
CE = D3(GPIO0)
IRQ = D4(GPIO2)

Ich muss noch die Fritzing Schematics & die Beschreibung dementsprechend 
anpassen. Verstehen tue ich’s auch (noch) nicht. Bei mir hat die 30 s 
Intervallzeit mE viel mehr Erfolg als irgendeine geänderte Belegung. 
Aber wenn‘s Euch hilft =^D

Wir sollten evtl überlegen ob wir den von Ziyat T. vorgeschlagenen Weg: 
kein IRQ und auf allen Kanälen empfangen und/oder senden auch umsetzen ?
Zumindest die Raspberry Pi Variante von Jan-Jonas S. kommt schließlich 
auch ohne IRQ aus. Vielleicht ist ein gutes Timing wie im uart_nrf.c/.h 
code des Herstellers besser als ein Interrupthandler der ständig 
dazwischenkommt/-„funkt“.

[Oswald S. (obmaroszi)]

HAllo

habe teiweise resets ohne ersichtlichem Grund.
Kann jemand aus dem Log etwas lesen warum?

equesting Inverter SN 114180113742
Transmit 27 | 15 80 11 37 42 78 56 34 12 80 0B 00 62 C1 61 21 00 00 00 
05 00 00 00 00 58 2A E6
Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 
00 03 00 00 01 3C 00 41 00 CE 00 00 2E
Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 
00 03 00 00 01 3C 00 41 00 CE 00 00 2E
Received 27 bytes channel 23: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 
00 03 00 00 01 3C 00 41 00 CE 00 00 2E
Received 23 bytes channel 3: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 
03 E8 00 FA 00 D2 3E 2D CE
Received 23 bytes channel 3: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 
03 E8 00 FA 00 D2 3E 2D CE
Received 23 bytes channel 23: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 
03 E8 00 FA 00 D2 3E 2D CE
Error while retrieving data: Frame 2 missing: Request Retransmit
Transmit 11 | 15 80 11 37 42 78 56 34 12 82 7B
Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 
1B 1E 00 00 00 28 09 39 13 89 00 C4 44
Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 
1B 1E 00 00 00 28 09 39 13 89 00 C4 44
Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 
1B 1E 00 00 00 28 09 39 13 89 00 C4 44
Payload (42): 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 00 90 00 
00 1B 1E 00 00 00 28 09 39 13 89 00 C4 00 00 00 08 03 E8 00 FA 00 D2

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Exception (3):
epc1=0x401007a5 epc2=0x00000000 epc3=0x00000000 excvaddr=0x40031dd9 
depc=0x00000000

>>>stack>>>

ctx: sys
sp: 3fffec20 end: 3fffffb0 offset: 0190
3fffedb0:  00000319 00000319 3ffe85dc 401009d3
3fffedc0:  00000319 00000319 3ffe85dc 401009d3
3fffedd0:  3fff1d1c 00000020 3fff1d1c 3fff1d1c
3fffede0:  00000000 00000020 3fff1d1c 40100bb2
3fffedf0:  40104533 00000000 00000000 40100534
3fffee00:  0000011c 00000020 3fff3b3c 402253f8
3fffee10:  401033fc 3fff1d1c 3fff1d1c 4021d339
3fffee20:  000007d3 000007d3 3ffe85dc 4021de40
3fffee30:  00000000 2c9f0300 4000050c 4021e4c7
3fffee40:  3fff1d1c 00000020 3fff42ec 40100bb2
3fffee50:  0055f4e5 cc21a274 00000000 40100534
3fffee60:  3fff1d1c 3fff0400 00000006 3fff03fc
3fffee70:  3fff1d1c 3fff0400 00000005 4021e530
3fffee80:  3fff1d1c 3fff0400 00000005 40226f47
3fffee90:  00000000 00000000 4bc6a7f0 402253d1
3fffeea0:  00000019 00000000 401002dd 00000000
3fffeeb0:  3fff0000 00000152 00000020 3ffeffb0
3fffeec0:  3fff0230 3fff430a 3fff42ec 402246e9
3fffeed0:  00000014 3ffeffb0 3ffe85dc 401009d3
3fffeee0:  00000000 3fff058c 3ffeda50 3fff1c8c
3fffeef0:  3fffdc80 00000020 3fff35e4 3fff1c8c
3fffef00:  3ffeffb0 00000008 3fff42ec 4021d209
3fffef10:  3fffdc80 3fff0834 3fff35e4 4021d008
3fffef20:  4024558d 3fff0834 3fff35e4 4024559f
3fffef30:  3fff42fc 3fff42ec 00000000 3ffe85d8
3fffef40:  40241ffb 00000000 3fff35e4 40246873
3fffef50:  40000f49 3fffdab0 3fffdab0 40000f49
3fffef60:  40000e19 000593d1 00000000 00000005
3fffef70:  60000600 aa55aa55 000000f7 40105539
3fffef80:  4010553f 00000000 00000005 40100b8c
3fffef90:  4010000d 56bde7c1 000593d1 401000ac
3fffefa0:  00000000 3fffef3c 00000000 3ffffe58
3fffefb0:  3fffffc0 00000000 00000000 feefeffe
3fffefc0:  feefeffe feefeffe feefeffe feefeffe
3fffefd0:  feefeffe feefeffe feefeffe feefeffe
3fffefe0:  feefeffe feefeffe feefeffe feefeffe
3fffeff0:  feefeffe feefeffe feefeffe feefeffe
3ffff000:  feefeffe feefeffe feefeffe feefeffe
3ffff010:  feefeffe feefeffe feefeffe feefeffe
3ffff020:  feefeffe feefeffe feefeffe feefeffe
3ffff030:  feefeffe feefeffe feefeffe feefeffe
3ffff040:  feefeffe feefeffe feefeffe feefeffe
3ffff050:  feefeffe feefeffe feefeffe feefeffe
3ffff060:  feefeffe feefeffe feefeffe feefeffe
3ffff070:  feefeffe feefeffe feefeffe feefeffe
3ffff080:  feefeffe feefeffe feefeffe feefeffe
3ffff090:  feefeffe feefeffe feefeffe feefeffe
3ffff0a0:  feefeffe feefeffe feefeffe feefeffe
3ffff0b0:  feefeffe feefeffe feefeffe feefeffe
3ffff0c0:  feefeffe feefeffe feefeffe feefeffe
3ffff0d0:  feefeffe feefeffe feefeffe feefeffe
3ffff0e0:  feefeffe feefeffe feefeffe feefeffe
3ffff0f0:  feefeffe feefeffe feefeffe feefeffe
3ffff100:  feefeffe feefeffe feefeffe feefeffe
3ffff110:  feefeffe feefeffe feefeffe feefeffe
3ffff120:  feefeffe feefeffe feefeffe feefeffe
3ffff130:  feefeffe feefeffe feefeffe feefeffe
3ffff140:  feefeffe feefeffe feefeffe feefeffe
3ffff150:  feefeffe feefeffe feefeffe feefeffe
3ffff160:  feefeffe feefeffe feefeffe feefeffe
3ffff170:  feefeffe feefeffe feefeffe feefeffe
3ffff180:  feefeffe feefeffe feefeffe feefeffe
3ffff190:  feefeffe feefeffe feefeffe feefeffe
3ffff1a0:  feefeffe feefeffe feefeffe feefeffe
3ffff1b0:  feefeffe feefeffe feefeffe feefeffe
3ffff1c0:  feefeffe feefeffe feefeffe feefeffe
3ffff1d0:  feefeffe feefeffe feefeffe feefeffe
3ffff1e0:  feefeffe feefeffe feefeffe feefeffe
3ffff1f0:  feefeffe feefeffe feefeffe feefeffe
3ffff200:  feefeffe feefeffe feefeffe feefeffe
3ffff210:  feefeffe feefeffe feefeffe feefeffe
3ffff220:  feefeffe feefeffe feefeffe feefeffe
3ffff230:  feefeffe feefeffe feefeffe feefeffe
3ffff240:  feefeffe feefeffe feefeffe feefeffe
3ffff250:  feefeffe feefeffe feefeffe feefeffe
3ffff260:  feefeffe feefeffe feefeffe feefeffe
3ffff270:  feefeffe feefeffe feefeffe feefeffe
3ffff280:  feefeffe feefeffe feefeffe feefeffe
3ffff290:  feefeffe feefeffe feefeffe feefeffe
3ffff2a0:  feefeffe feefeffe feefeffe feefeffe
3ffff2b0:  feefeffe feefeffe feefeffe feefeffe
3ffff2c0:  feefeffe feefeffe feefeffe feefeffe
3ffff2d0:  feefeffe feefeffe feefeffe feefeffe
3ffff2e0:  feefeffe feefeffe feefeffe feefeffe
3ffff2f0:  feefeffe feefeffe feefeffe feefeffe
3ffff300:  feefeffe feefeffe feefeffe feefeffe
3ffff310:  feefeffe feefeffe feefeffe feefeffe
3ffff320:  feefeffe feefeffe feefeffe feefeffe
3ffff330:  feefeffe feefeffe feefeffe feefeffe
3ffff340:  feefeffe feefeffe feefeffe feefeffe
3ffff350:  feefeffe feefeffe feefeffe feefeffe
3ffff360:  feefeffe feefeffe feefeffe feefeffe
3ffff370:  feefeffe feefeffe feefeffe feefeffe
3ffff380:  feefeffe feefeffe feefeffe feefeffe
3ffff390:  feefeffe feefeffe feefeffe feefeffe
3ffff3a0:  feefeffe feefeffe feefeffe feefeffe
3ffff3b0:  feefeffe feefeffe feefeffe feefeffe
3ffff3c0:  feefeffe feefeffe feefeffe feefeffe
3ffff3d0:  feefeffe feefeffe feefeffe feefeffe
3ffff3e0:  feefeffe feefeffe feefeffe feefeffe
3ffff3f0:  feefeffe feefeffe feefeffe feefeffe
3ffff400:  feefeffe feefeffe feefeffe feefeffe
3ffff410:  feefeffe feefeffe feefeffe feefeffe
3ffff420:  feefeffe feefeffe feefeffe feefeffe
3ffff430:  feefeffe feefeffe feefeffe feefeffe
3ffff440:  feefeffe feefeffe feefeffe feefeffe
3ffff450:  feefeffe feefeffe feefeffe feefeffe
3ffff460:  feefeffe feefeffe feefeffe feefeffe
3ffff470:  feefeffe feefeffe feefeffe feefeffe
3ffff480:  feefeffe feefeffe feefeffe feefeffe
3ffff490:  feefeffe feefeffe feefeffe feefeffe
3ffff4a0:  feefeffe feefeffe feefeffe feefeffe
3ffff4b0:  feefeffe feefeffe feefeffe feefeffe
3ffff4c0:  feefeffe feefeffe feefeffe feefeffe
3ffff4d0:  feefeffe feefeffe feefeffe feefeffe
3ffff4e0:  feefeffe feefeffe feefeffe feefeffe
3ffff4f0:  feefeffe feefeffe feefeffe feefeffe
3ffff500:  feefeffe feefeffe feefeffe feefeffe
3ffff510:  feefeffe feefeffe feefeffe feefeffe
3ffff520:  feefeffe feefeffe feefeffe feefeffe
3ffff530:  feefeffe feefeffe feefeffe feefeffe
3ffff540:  feefeffe feefeffe feefeffe feefeffe
3ffff550:  feefeffe feefeffe feefeffe feefeffe
3ffff560:  feefeffe feefeffe feefeffe feefeffe
3ffff570:  feefeffe feefeffe feefeffe feefeffe
3ffff580:  feefeffe feefeffe feefeffe feefeffe
3ffff590:  feefeffe feefeffe feefeffe feefeffe
3ffff5a0:  feefeffe feefeffe feefeffe feefeffe
3ffff5b0:  feefeffe feefeffe feefeffe feefeffe
3ffff5c0:  feefeffe feefeffe feefeffe feefeffe
3ffff5d0:  feefeffe feefeffe feefeffe feefeffe
3ffff5e0:  feefeffe feefeffe feefeffe feefeffe
3ffff5f0:  feefeffe feefeffe feefeffe feefeffe
3ffff600:  feefeffe feefeffe feefeffe feefeffe
3ffff610:  feefeffe feefeffe feefeffe feefeffe
3ffff620:  feefeffe feefeffe feefeffe feefeffe
3ffff630:  feefeffe feefeffe feefeffe feefeffe
3ffff640:  feefeffe feefeffe feefeffe feefeffe
3ffff650:  feefeffe feefeffe feefeffe feefeffe
3ffff660:  feefeffe feefeffe feefeffe feefeffe
3ffff670:  feefeffe feefeffe feefeffe feefeffe
3ffff680:  feefeffe feefeffe feefeffe feefeffe
3ffff690:  feefeffe feefeffe feefeffe feefeffe
3ffff6a0:  feefeffe feefeffe feefeffe feefeffe
3ffff6b0:  feefeffe feefeffe feefeffe feefeffe
3ffff6c0:  feefeffe feefeffe feefeffe feefeffe
3ffff6d0:  feefeffe feefeffe feefeffe feefeffe
3ffff6e0:  feefeffe feefeffe feefeffe feefeffe
3ffff6f0:  feefeffe feefeffe feefeffe feefeffe
3ffff700:  feefeffe feefeffe feefeffe feefeffe
3ffff710:  feefeffe feefeffe feefeffe feefeffe
3ffff720:  feefeffe feefeffe feefeffe feefeffe
3ffff730:  feefeffe feefeffe feefeffe feefeffe
3ffff740:  feefeffe feefeffe feefeffe feefeffe
3ffff750:  feefeffe feefeffe feefeffe feefeffe
3ffff760:  feefeffe feefeffe feefeffe feefeffe
3ffff770:  feefeffe feefeffe feefeffe feefeffe
3ffff780:  feefeffe feefeffe feefeffe feefeffe
3ffff790:  feefeffe feefeffe feefeffe feefeffe
3ffff7a0:  feefeffe feefeffe feefeffe feefeffe
3ffff7b0:  feefeffe feefeffe feefeffe feefeffe
3ffff7c0:  feefeffe feefeffe feefeffe feefeffe
3ffff7d0:  feefeffe feefeffe feefeffe feefeffe
3ffff7e0:  feefeffe feefeffe feefeffe feefeffe
3ffff7f0:  feefeffe feefeffe feefeffe feefeffe
3ffff800:  feefeffe 00000000 feefeffe 000000f9
3ffff810:  00000064 00000001 40105385 3ffee228
3ffff820:  00000002 00000000 00000020 401001c8
3ffff830:  401025d1 00000001 00000002 401021a0
3ffff840:  3ffea062 4010541f 3ffed780 000000fe
3ffff850:  00000002 00000000 00000020 401001c8
3ffff860:  00000002 00000000 00000020 401001c8
3ffff870:  401025d1 4010541f 00000002 401021a0
3ffff880:  3ffea062 4010541f 3ffed780 00040000
3ffff890:  00000001 401045fa 3ffee228 401001c8
3ffff8a0:  40104a6b 40105437 3ffeda50 401001c8
3ffff8b0:  40104533 00000000 00000002 000000fe
3ffff8c0:  40104533 00000029 00000002 00040000
3ffff8d0:  00002200 00000000 00000000 000000ff
3ffff8e0:  00000005 00000000 00000020 401001c8
3ffff8f0:  3ffee1b0 00000000 00000005 401021a0
3ffff900:  3ffea065 40105437 3ffedaf0 401001c8
3ffff910:  40102d2b 3ffedaf0 00000002 401021a0
3ffff920:  00000000 00000000 0000001f 401001c8
3ffff930:  3ffea910 00000000 3fffc228 40105cd1
3ffff940:  4000050c 2c9f0300 4000050c 3fffc278
3ffff950:  401030e4 3fffc200 00000022 ffffffff
3ffff960:  4022fdd4 00000030 00000000 ffffffff
3ffff970:  4022b896 3fff1a48 00000001 40000000
3ffff980:  00000000 bfffffff 00080240 c00c3004
3ffff990:  3ffecf00 000c3000 ff000fff 3ffeeb50
3ffff9a0:  3fff058c 00000001 3fff4f8c 00000030
3ffff9b0:  40216535 00000000 00000003 00000000
3ffff9c0:  00000000 3ffffc50 00000002 3ffffba0
3ffff9d0:  00000002 00000000 00000020 401001c8
3ffff9e0:  00000002 00000000 0000000a 00000000
3ffff9f0:  00000002 00000000 40243157 00000000
3ffffa00:  ffffffff 00000000 3ffea1b1 00000000
3ffffa10:  402431a6 00000000 3fff058c 000000fa
3ffffa20:  0000006c 00000001 40105385 3ffee228
3ffffa30:  3ffee1b0 00000005 00000002 401021a0
3ffffa40:  3ffea062 40242263 3ffed758 3fff4f8c
3ffffa50:  40104f6a 3ffee228 3ffeeb50 3fff058c
3ffffa60:  00000000 401048b9 3ffee228 3ffed758
3ffffa70:  3fff4fc2 40105a7b 3fff1a48 3ffeff98
3ffffa80:  40105081 3ffee228 00000008 00040000
3ffffa90:  53002200 4021cc0d 3fff1a48 3ffeff98
3ffffaa0:  4010513d 00080000 00000002 3ffffbc0
3ffffab0:  40103412 00000000 3ffffb10 3ffeffb0
3ffffac0:  3ffeffb0 00000000 3fff4f8c 4021ce3b
3ffffad0:  3ffeffe8 2c9f0300 4000050c 3fffc278
3ffffae0:  401030e4 3fffc200 00000022 00040000
3ffffaf0:  40000656 00000030 00000010 ffffffff
3ffffb00:  401002dd 00000000 00000000 4bc6a7f0
3ffffb10:  00000000 282a097f 3fff08e8 00000000
3ffffb20:  00004c35 3fffc6fc 47cf097f 00000000
3ffffb30:  002455a3 522d0e56 2a0304d7 00000030
3ffffb40:  4020a156 00000030 00000010 ffffffff
3ffffb50:  4020a152 00000000 00418937 00000000
3ffffb60:  00000000 3fff1e04 00000020 40100bdc
3ffffb70:  00000000 3ffe9f94 00000000 40100510
3ffffb80:  00000000 00000218 00000020 402253d1
3ffffb90:  00000006 3fff03c0 00000274 4021d2e4
3ffffba0:  00000452 00000010 3ffffc6c 4021d314
3ffffbb0:  3ffeffb0 3fff1e04 00000000 4021ff43
3ffffbc0:  00000000 0057180f 00000000 4020feb4
3ffffbd0:  00000046 7fffffff 3ffffc9c 00000000
3ffffbe0:  00000000 4bc6a7f0 6624dd2f 2a0304ee
3ffffbf0:  00000000 00000000 4bc6a7f0 00000000
3ffffc00:  00000001 3fff4064 401002dd 00000000
3ffffc10:  002455a3 3fff1e08 00000010 00000073
3ffffc20:  007a1200 77de7f91 3ffffd00 00000002
3ffffc30:  00000001 00000000 3fff2004 4020a152
3ffffc40:  00000010 00000010 00000073 3ffffcf0
3ffffc50:  3fff08e8 00000000 00000073 000000ff
3ffffc60:  000000cf 00000001 40105385 3ffee228
3ffffc70:  3ffee1b0 3ffffd14 3ffffc90 4020f5c4
3ffffc80:  04c4b400 77dea726 3fff0900 40202db8
3ffffc90:  40104f6a 00000000 00000010 000000fd
3ffffca0:  000000cf 00000001 40105385 3ffee228
3ffffcb0:  3ffee1b0 00000000 312e312f 3ffffd50
3ffffcc0:  00000005 00000000 00000020 401001c8
3ffffcd0:  401025d1 3ffee228 00000005 401021a0
3ffffce0:  4010432f 00040000 00000000 00040000
3ffffcf0:  00002200 4010432c 00040000 40105cd1
3ffffd00:  3ffee228 40103293 3ffee3fc 40102f08
3ffffd10:  00000005 00000000 00000020 401001c8
3ffffd20:  4000066d 2c9f0300 00000005 401021a0
3ffffd30:  3ffea065 40105437 3ffeda50 401001c8
3ffffd40:  40102d2b 3ffeda50 0000001f 401001c8
3ffffd50:  000000a7 8df3c376 3ffee3fc 40102f08
3ffffd60:  3ffea91c 00000000 00000000 3ffefb94
3ffffd70:  000000a7 8df3c376 401033c2 00000100
3ffffd80:  3ffea91c 7fffffff 00002200 00000001
3ffffd90:  00000001 00004a88 00000000 fffffffe
3ffffda0:  3ffea91c 3fffc6fc 00000001 8df3c376
3ffffdb0:  3ffea8ec 2c9f0300 4000050c 3fffc278
3ffffdc0:  401030e4 3fffc200 00000022 8df35128
3ffffdd0:  401060c2 00000030 00000010 ffffffff
3ffffde0:  4010028a 3ff20a00 3ffea8d8 00000000
3ffffdf0:  00004bc6 00000000 00000000 fffffffe
3ffffe00:  00000000 3fffc6fc 00000000 3ffefb80
3ffffe10:  00000000 3ffef6a0 3ffefb94 00000030
3ffffe20:  00000000 4bc6a7f0 ebc6a7ef 2a049598
3ffffe30:  007a1200 7985a96f 4bc6a700 00000000
3ffffe40:  00000000 00000000 00000001 401001c8
3ffffe50:  00000000 4bc6a7f0 eed91687 2a04959c
3ffffe60:  00000000 00000000 4bc6a7f0 00000000
3ffffe70:  3ffef6a0 3fff08e8 401002dd 00000000
3ffffe80:  002456fd 00000000 00000000 fffffffe
3ffffe90:  00000000 4bc6a7f0 f4bc6a7f 2a0495a3
3ffffea0:  00000000 00000000 4bc6a7f0 00000000
3ffffeb0:  402113ec 40100e60 401002dd 00000000
3ffffec0:  002456fd 00000000 00000000 fffffffe
3ffffed0:  ffffffff 3fffc6fc 00000001 3ffefb94
3ffffee0:  3ffef6a0 00000000 3ffefb80 4020464e
3ffffef0:  00000000 3fffdad0 3ffefb94 00000030
3fffff00:  00000000 3fffdad0 3ffefb94 00000030
3fffff10:  54646c65 6c61746f 3ffe8500 401009d3
3fffff20:  00000000 001d001f 00000000 00000000
3fffff30:  000b000f 00000000 00000000 001b001f
3fffff40:  00000000 00000000 001a001f 00000000
3fffff50:  00000000 000b000f 00000000 3ffefb94
3fffff60:  007a1200 7985b2a9 00000000 3fff1314
3fffff70:  00000000 3fff12fc 3fff1310 feefeffe
3fffff80:  00000000 00000000 00000001 401001c8
3fffff90:  3fffdad0 00000000 3ffefb80 401001e9
3fffffa0:  feefeffe feefeffe 3ffefb80 40211412
<<<stack<<<

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v000593e0
~ld
connect to network 'obmar' ...
...............................
.....................................................................
[NTP]: 2022-07-03+09:28:43
SERIAL: 11 41
add inverter: PV HM 800, SN: 114180113742
RF24 Amp Pwr: RF24_PA_HIGH
Radio Config:
SPI Frequency    = 1 Mhz
Channel      = 3 (~ 2403 MHz)
RF Data Rate    = 250 KBPS
RF Power Amplifier  = PA_HIGH
RF Low Noise Amplifier  = Enabled
CRC Length    = Disabled
Address Length    = 5 bytes
Static Payload Length  = 32 bytes
Auto Retry Delay  = 250 microseconds
Auto Retry Attempts  = 0 maximum
Packets lost on
    current channel  = 0
Retry attempts made for
    last transmission  = 9
Multicast    = Disabled
Custom ACK Payload  = Disabled
Dynamic Payloads  = Disabled
Auto Acknowledgment  = Disabled
Primary Mode    = RX
TX address    = 0xdeadbeef01
pipe 0 (closed) bound  = 0xdeadbeef01
pipe 1 ( open ) bound  = 0x1234567801
pipe 2 (closed) bound  = 0xc3
pipe 3 (closed) bound  = 0xc4
pipe 4 (closed) bound  = 0xc5
pipe 5 (closed) bound  = 0xc6


----------------------------------------
Welcome to AHOY!

point your browser to http://192.168.178.61
to configure your device
----------------------------------------

Free heap: 0x8ab8
Inverter #0 no Payload received!
Requesting Inverter SN 114180113742
Transmit 27 | 15 80 11 37 42 78 56 34 12 80 0B 00 62 C1 61 46 00 00 00 
05 00 00 00 00 6A A4 3D
Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 
00 03 00 00 01 49 00 48 00 EC 00 00 70


Manchmal geht auch die Verbindung zu Mqtt verloren.
Hab ich aber noch keinen Log .

[IsnoAhoy (Gast)]

Hallo Oswald S.,

bitte hier keine Stacktraces / Exceptions reinpasten! Wir kennen das 
Problem und versuchen es seit einiger Zeit u.a. im folgrnden Github 
Issue zu analysieren:

https://github.com/grindylow/ahoy/issues/15

Dort steht auch, wie Du Deinen Exception Code decodieren kannst. Das 
geht nur mit dem Original Hex/Binary file das auf Deinem ESP8266 
geflasht wurde. Wir können also mit den Daten gar nichts anfangen sic 
!

Wenn Du weiteren Code hier pasten willst dann verwende bitte die [ code 
] und [ / code ] Syntax (siehe unten beim Eingabefeld) um es für uns 
alle leserlich zu gestalten. Danke!

[IsnoAhoy (Gast)]

Hallo Oswald S.,

ansonsten scheint er ja einen WLAN Router zu erreichen, das nRF24L01+ 
Modul zu initialisieren und auf die Anfrage eine Antwort vom 
Wechselrichter zu bekommen und es ist soweit alles schick außer/nach dem 
Reboot.

[IsnoAhoy (Gast)]

Ach ja und das Problem mit dem Neuaufbau der MQTT Verbindung hatten wir 
vermeintlich schon gelöst:

https://github.com/grindylow/ahoy/issues/68

Vielleicht ist die WLAN Verbindung doch nicht so stabil wie man es aus 
den o.a. Logfile annehmen könnte ?
Das ist zumindest bei mir m.E. das Problem (mein Router ist im Keller 
und der ESP unterm Dach) da geht es nur in bestimmten Ecken des Zimmers 
und auch nur wenn die Nachbarn (bzw. deren WLAN Geräte) schlafen.

[Marcel A. (a-marcel)]

Hallo,

gibt es denn schon erfolge bzgl. Hoymiles und Limitierung ?

Ich habe das, was ich hier gelesen habe mal testweise eingebaut, leider 
bekomme auch ich keine Antwort oder eine Limitierung.

        void sendPowerLimitPacket(uint64_t invId, uint8_t limit, bool calcCrc = true) {
            //DPRINTLN(DBG_VERBOSE, F("hmRadio.h:sendCmdPacket"));
            memset(mTxBuf, 0, MAX_RF_PAYLOAD_SIZE);
            mTxBuf[0] = 0x51; // message id
            CP_U32_BigEndian(&mTxBuf[1], (invId  >> 8));
            CP_U32_BigEndian(&mTxBuf[5], (DTU_ID >> 8));
            mTxBuf[9]  = 0x5a;
            mTxBuf[10]  = 0x5a;
            mTxBuf[11]  = 0x32;            

            if(calcCrc) {
                mTxBuf[12] = Hoymiles::crc8(mTxBuf, 12);
                sendPacket(invId, mTxBuf, 13, false);
                DPRINT(DBG_INFO, "Transmit (Limit) " + String(13) + " | ");
                dumpBuf(NULL, mTxBuf, 13);
            }
        }

Der Request sollte 50% limitieren.

Die Payload dazu ist:

[14:52:39]I: Transmit (Limit) 13 | 51 73 10 90 25 78 56 34 12 5A 5A 32 BD

Wäre cool, wenn wir das hinbekommen, mein 2ter PWM is bereits nach 
Monaten Dauerbetrieb schon abgeraucht. Den nutze ich um die Stromstärke 
für den HM anzupassen.

Marcel

[Ziyat T. (toe_c)]

Marcel A. schrieb:
> Der Request sollte 50% limitieren.
>
> Die Payload dazu ist:
> [code]
> [14:52:39]I: Transmit (Limit) 13 | 51 73 10 90 25 78 56 34 12 5A 5A 32
> BD

Das geht anscheinend bisher nur mit "meinem" MI-1500.

Kannst du mal bitte diese Variante auch noch probieren?
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Marcel A. (a-marcel)]

Hallo Ziyat,

ich hab den test code mal angepasst auf:

void sendPowerLimitPacket(uint64_t invId, uint8_t limit, bool calcCrc = true) {
            //DPRINTLN(DBG_VERBOSE, F("hmRadio.h:sendCmdPacket"));
            memset(mTxBuf, 0, MAX_RF_PAYLOAD_SIZE);
            mTxBuf[0] = 0x51; // message id
            CP_U32_BigEndian(&mTxBuf[1], (invId  >> 8));
            CP_U32_BigEndian(&mTxBuf[5], (DTU_ID >> 8));
            mTxBuf[9]  = 0x5a;
            mTxBuf[10] = 0x5a;
            mTxBuf[11] = 0x64; // 100%
            mTxBuf[12] = 0x32; // 50W

            if(calcCrc) {
                mTxBuf[13] = Hoymiles::crc8(mTxBuf, 13);
                sendPacket(invId, mTxBuf, 14, false);
                DPRINT(DBG_INFO, "Transmit (Limit) " + String(14) + " | ");
                dumpBuf(NULL, mTxBuf, 14);
            }
        }

welches dann in folgende Payload übergeht:

[16:21:06]I: Transmit (Limit) 14 | 51 73 10 90 25 78 56 34 12 5A 5A 64 32 D9

Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste 
ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ?

Marcel

[Rene M. (Firma: Bitte wählen) (renmo)]

Wie kann man die Befehle zur Limitierung senden?

[Marcel A. (a-marcel)]

Rene M. schrieb:
> Wie kann man die Befehle zur Limitierung senden?

Ich hab seit ein paar Tagen die EspHome Version fertig und teste die 
gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich 
zufrieden damit bin). Da habe ich mir einen Schalter eingebaut der dann 
die o.g. Funktion aufruft.

Es ist derzeit noch nicht im code eingebaut und man müsste es sich immer 
selber bauen.

Damals war es möglich ein Commando in der Seriellen Konsole aufzurufen, 
weiß aber nicht wie das gemacht wurde.

Marcel

[Rene M. (Firma: Bitte wählen) (renmo)]

Ok danke.
Da bin ich schon gespannt darauf.
Danke für die tolle Arbeit an alle!

[A.D. (Gast)]

Hallo zusammen,

erst einmal vielen vielen Dank an alle die das Projekt hier ins Leben 
gerufen haben!!! Bei mir mit meinem Hoymiles HM-600 läuft das ganze 
jetzt schon ca. zwei Wochen ohne nennenswerte Probleme.
Jetzt habe ich allerdings doch mal eine Frage: Im Setup bei MQTT kann 
man da nur eine IP adresse eingeben? Eine dyndns adresse wird nicht 
angenommen und es erscheint beim nachschauen die IP 0.0.0.0

Hat da wer ein Tipp für mich?

Liebe Grüße

Andreas

[Daniel R. (daniel92)]

Die IP-Adresse von MQTT ist die Adresse zum MQTT-Server gemeint. ;)

[A.D. (Gast)]

Ja, soweit klar. Aber man kann nur eine IP adresse eingeben. Nicht z.B. 
„xyz.ddns.net“

[Tobi D. (tobidd)]

Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso 
dann eine Dyndns Adresse?

[Herbert K. (avr-herbi)]

Es spielt doch gar keine Rolle wor ein MQTT Server steht !
Das kann intern oder extern sein.

Mein Vorschlag für die Programmierer wäre:

MQTT ein/aus  wählbar

Wenn MQTT ein, dann

A) IP Addr und Timeout in ms  angebbar
B) DNS Adr. und Timeout in ms  angebbar

Reihenfolge zur Erreichbarkeit Auswahl:
(folgende Optionen nur wählbar, wenn A) bzw. B) auch ausgefüllt)

Nur A)
Nur B)
Erst A) und wenn nicht erreichbar bis Timeout dann B)
Erst B) und wenn nicht erreichbar bis Timeout dann A)

So was in der Art würde vielleicht Sinn machen. Wer einen github Account 
hat, kann das ja gerne kopieren und dort hinterlegen. Ich habe da 
aktuell keinen Account.

[Damian B. (damian_b)]

Tobi D. schrieb:
> Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso
> dann eine Dyndns Adresse?


Sie können einen Server außerhalb in der Cloud haben

[Daniel R. (daniel92)]

Herbert K. schrieb:
> Mein Vorschlag für die Programmierer wäre:
>
> MQTT ein/aus  wählbar

Schreib es auf Github als feature. :)

https://github.com/grindylow/ahoy/issues

[oxylog (Gast)]

Mir ist etwas interessantes aufgefallen, für was ich keine Lösung finden 
kann:
- Mit ahoy v0.4.14 - alles funtkioniert bestens.
- Mit ahoy v0.4.20 - "Inverter is available but is not producing"

Einstellungen sind alle gleich - getestet per OTA-Update als auch direkt 
aus Arduino auf den 8266 geladen.

Ich bin leider kein Programmierer und kann nicht so weit in die Materie 
hereinschauen wie ihr, eventuell hilft aber der Hinweis

[dax (Gast)]

Wenn die Spannung AC  = > 253 V beträgt, produziert der Wechselrichter 
nicht

[oxylog (Gast)]

dax schrieb:
> Wenn die Spannung AC  = > 253 V beträgt, produziert der Wechselrichter
> nicht

Der Wechselrichter produziert korrekt. Ich habe zwei ESP8266 mit 
NRF24l01+ hier aufgebaut um die Versionen zu testen.
Mit Version 0.4.14 bekomme ich die nachweislich korrekten Werte 
angezeigt, mit Version 0.4.20 den oben beschriebenen Fehler.
Es liegt nicht an der technischen Installation; es scheint zwischen 
beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser 
Meldung führt.

[Volker.B. (Gast)]

oxylog schrieb:
> Es liegt nicht an der technischen Installation; es scheint zwischen
> beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser
> Meldung führt.

Hast Du die Pinout Einstellungen mal angepasst?

[Jan-Jonas S. (janjonas_s)]

dax schrieb:
> Wenn die Spannung AC  = > 253 V beträgt, produziert der Wechselrichter
> nicht

Ist ja auch irgendwie erwartungsgemäß. Interessant wäre dann auch mal 
das Event-Log. Da müsste dann ein code 141 'Grid overvoltage' drin 
stehen.

[oxylog (Gast)]

Yes, die Einstellungen sind gleich wie bei meinem Testaufbau.
Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht 
solche Fehler zu vermeiden.
0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings 
führen unter 0.4.20 zur Fehlermeldung.
Kann das an einer NRF-Library-Version hängen?

[Norman Z. (comtel)]

Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon 
erfolgreich mit dem Projekt zum laufen gebracht?

[oxylog (Gast)]

oxylog schrieb:
> Yes, die Einstellungen sind gleich wie bei meinem Testaufbau.
> Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht
> solche Fehler zu vermeiden.
> 0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings
> führen unter 0.4.20 zur Fehlermeldung.
> Kann das an einer NRF-Library-Version hängen?

Ok, jetzt habe ich doch einen Ansatz gefunden. Nochmals alle 
Bibliotheken aktualisiert, nochmals kompiliert - alle Einstellungen in 
Arduino überprüft - jetzt geht es.
Sorry für den Trouble!

[Thomas B. (tbnobody)]

Norman Z. schrieb:
> Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon
> erfolgreich mit dem Projekt zum laufen gebracht?

Hier steht im Datenblatt als Kommunikationsmedium "Sub-1G wireless". Das 
ist kein Nordic Semiductor NRF24 2.4GHz Modul. Wird also nicht 
funktionieren (würde ich annehmen)

[Herbert K. (avr-herbi)]

Wechselrichter hoymiles HMT-xxxx  HMS-xxxx  DTU-Pro-S (Sub-1G 
wireless) ist vermutlich eine andere Übertragungstechnik / ein anderes 
Protokoll wie hoymiles HM-xxxx (nRF24).

Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit 
HMT-xxxx, HMS-xxxx, DTU-Pro-S.

Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt.
Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"

Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt.
Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless"

Und für Hoymiles Gateway DTU-Pro-S bitte hier diskutieren:
Beitrag "Hoymiles Gateway DTU-Pro-S mit "-S" Sub-1G wireless"

Danke fürs Verständnis.

[Gerald R. (visitor)]

Ich würde gerne mal OpenDTU mit einem HM-800 ausprobieren.

Leider gibt es von den ESP32 so viele Versionen dass ich nicht 
durchblicke.

Ist das hier der richtige?
https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1

Ich finde auf git bei tbnonody leider nirgends eine vollständige 
Bezeichnung.

[M. P. (matze7779)]

Hallo,

hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt 
sind?
Hier HM-800 an ESP8266.
Siehe Screenshot.

Ich habe auch festgestellt das wenn der MQTT Server mal weg ist (oder 
man die falsche IP vergibt) der ESP nach einiger Zeit nicht mehr 
reagiert.

[M. P. (matze7779)]

Hier noch das ioBroker Protokoll dazu.

[Daniel R. (daniel92)]

Hmm bei mir passt alles.
Welche Version hast du?

[M. P. (matze7779)]

Das ist die 0.4.20. Erst läuft auch alles normal... Dann nach einiger 
Zeit fängt das an.

[1N 4. (1n4148)]

> hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt
> sind?

Hatte ich im Zusammenspiel PubSubClient und IOBroker MQTT schon öfters, 
nicht nur beim Ahoy.

[1N 4. (1n4148)]

> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die
> gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich
> zufrieden damit bin).

Wenn du noch Tester brauchst :)

[Ziyat T. (toe_c)]

Marcel A. schrieb:
> Hallo Ziyat,

>

> [16:21:06]I: Transmit (Limit) 14 | 51 73 10 90 25 78 56 34 12 5A 5A 64 
> 32 D9
>

>
> Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste
> ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ?
>
> Marcel
Hallo Marcel
Dein Transmit waere korrekt. 100% wird, wenn danach noch ein Byte kommt 
(abs. Watt) immer ignoriert, aber ich lasse immer 100% drin, zum 
debuggen ist einfacher.
Ich denke das command:0x51  mit subcommand:0x5a5a  funktioniert bei den 
HM's nicht, du bist der 2. Tester. Schade :-(
Da ich kein HM habe, kann leider auch nicht sniffen, aber bald gibts bei 
mir einen HM-1500, dann kann ich es sicher heraus finden.
Gruss

[Daniel R. (daniel92)]

@Ziyat T. das wäre super. Ich bin nämlich mit meinem Latein am Ende. 
Habe mir die Doku nochmal angeschaut, aber irgendwann iser der Kopf nur 
noch voll. :(

[Marcel A. (a-marcel)]

1N 4. schrieb:
>> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die
>> gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich
>> zufrieden damit bin).
>
> Wenn du noch Tester brauchst :)

Sehr gerne. Du kannst meinen Fork checken: 
https://github.com/a-marcel/ahoy/tree/main/tools/esphome

Ich würde gern wissen ob es auf einem esp8266 funktioniert.

Ebenfalls habe ich Probleme die Payload in ein array zu packen und diese 
dann an den ESP Logger zu übergeben. Derzeit loggt er noch direkt zu 
Serial und das sieht man später nicht im EspHome log.

Und wenn du mit der Readme nicht klar kommst, nehme ich sehr gerne 
Kommentare an.


Bisher läuft sie seit 1 Woche gut durch. Mit kleineren Aussetzern aber 
keinen Reboot.
Vielen Dank
Marcel

[1N 4. (1n4148)]

>> Wenn du noch Tester brauchst :)
> Sehr gerne. Du kannst meinen Fork checken:
> https://github.com/a-marcel/ahoy/tree/main/tools/esphome
> Ich würde gern wissen ob es auf einem esp8266 funktioniert.

Ich versuche das mal über das IOBroker - ESPHome Plugin zu kompilieren 
:)

[Stefan T. (isnoahoy)]

Hallo Daniel R.,
hat eigentlich schon mal jemand versucht den Code von gitee.com 
(iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im 
Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an 
die HM-Wechselrichter versenden / verpacken würde ?
Das müsste doch in einer PlatformIO Umgebung oder einem STM IDE ohne 
weitere Bibliotheken gehen ... es scheint zumindest alles vorhanden.

Ich strauchle immer noch über die Vorbelegung der beiden 
Laufzeit-Variablen TotalIndex_Para und Index_Para in den 
UsartNrf3_Send_PackDevControl() Aufrufen in der 
UsartNrf_Send_DevControlUpdate() Methode:

2542:         Uart_SendBufferLen = UsartNrf3_Send_PackDevControl((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, (u16)(SubCmd << 8), (u8 *)MIMajor[PortNO].Property.Pass.Data + Index_Para, 0x81 + ((Index_Para + 4) / 16), TotalIndex_Para - Index_Para);

bzw. CurSendRecLostPackageNO und CurSendRecLastPackageNO in den Aufrufen 
in UsartNrf3_Send_DevControlUpdate:

2603:             Uart_SendBufferLen = UsartNrf3_Send_PackDevControl(target_adr, rout_adr, (u16)(SubCmd << 8), (u8 *)MIMajor[PortNO].Property.Pass.Data, (CurSendRecLastPackageNO + 1) | 0x80, TotalIndex_Para);

In UsartNrf3_Send_PackDevControl() wird dann schließlich das Paket 
zusammengebaut:

/***********************************************
** Function name: Three-generation protocol device control package
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
u8 UsartNrf3_Send_PackDevControl(u8 *target_adr, u8 *rout_adr, u16 ControlMode, u8 *ControlData, u8 nub, u8 Num)
{
    vu8 i = 0;
    vu16 TempCrc = 0;
    vu8 temp_dat[UART_LEN];
    vu16 DatCrc = 0xffff;
    memset((u8 *)temp_dat, 0, sizeof(temp_dat));
    memset((u8 *)Uart_SendBuffer, 0, UART_LEN);
    Uart_SendBuffer[0] = STX; //header
    temp_dat[0] = DEVCONTROL_ALL;   //command
    memcpy((u8 *)&temp_dat[1], target_adr, 4);//Source address
    memcpy((u8 *)&temp_dat[5], rout_adr, 4);//Destination address
    temp_dat[9] = 0x81;//

    if((nub & 0x0f) == 1)
    {
        temp_dat[10] = (u8)(ControlMode >> 8); //Control type
        temp_dat[11] = (u8)(ControlMode); //Control type
    }

    memcpy((u8 *) & (temp_dat[12]), ControlData, Num); //Control parameters

    for(i = 10; i < 12 + Num + 1; i++)
    {
        if((i - 10) % 2 == 1)
        {
            TempCrc = (u16)((temp_dat[i - 1] << 8) | (temp_dat[i]));
            DatCrc =  CalcCRC16t(TempCrc, DatCrc);
        }
    }

    temp_dat[12 + Num] = (u8)(DatCrc >> 8);
    temp_dat[13 + Num] = (u8)(DatCrc);
    temp_dat[14 + Num] = Get_crc_xor((u8 *)&temp_dat[0], 15 + Num);
    i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], (15 + Num)); //Forward replacement
    Uart_SendBuffer[(i + 1)] = ETX; // footer
    memset((u8 *)temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

Mit den folgenden Annahmen:

// STX: 0x7e
// MainCmd: 0x51 DEVCONTROL_ALL/REQ_ARW_DAT_ALL 
// target_adr: 0x73109025
// rout_adr: 0x78563412 
// SubCmd: 0x0B Type_ActivePowerContr 
// ControlMode: (u16)(SubCmd << 8): 0x0B00 
// *ControlData: (u8 *)MIMajor[PortNO].Property.Pass.Data: 0x00000000 00000000 00000000 00000000 0000 
// PowerPFDev: 0x03EB0001 // SetValut[2], Desc[2]
// nub: (CurSendRecLastPackageNO + 1) | 0x80: 0x81
// Num: TotalIndex_Para: 4 ?
// ETX: 0x7f

ergibt sich diese Paketstruktur

temp_dat[i]: -1, 0, 1..4, 5..8, 9, 10-11, 12-15, 16 
STX, MainCmd, target_adr[4], rout_adr[4], 0x81, 0x0B00, 0x00000000, ETX

und es sollte evtl. irgendwas wie das Folgende herauskommen:
0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f

Über den Wert aus PowerPFDev 0x03EB0001 bzw. Pass.Data[4] wird noch mit 
CalcCRC16t und Get_crc_xor eine/mehrere Prüfsummen gebildet.

PS: die InverterMajor Struktur sieht wie folgt aus:

InverterMajor
  Property
  Pre_Id[2] (vu8)
  Id[4] (vu8)
  Port (PortType)
  Id_In_Phase (vu8)
  Acq_Switch (vu8)
  Power_Limit (vu16)
  Pass (PassValueType)
      PowerPFDev (PowerPFDevType)
        SetValut[2] (vu8)
        Desc[2] (vu8)
      ClearAlarmDev (ClearAlarmDevType)
        WCode[2] (vu8)
      EletricSet (EletricSetType)
        Info[2] (vu8)
        Data[16] (vu8)
      PassWordSet (PassWordSetType)
        PWO[4] (vu8)
        PWN[4] (vu8)
        ATTime[2] (vu8)
      Data[18] (vu8)
  PropertyMsg[30] (vu8)

Und hier sind die für MI und HM definierten Lower Bytes der Pre_Id's die 
Id sind jeweils die lower 4 Bytes der Inverter Serial No.

Serial Number: Pre_Id[2] + Id[4]

typedef enum
{
    MI_NO       = 0,
    MI_250W     = 0x01,
    MI_500W_A   = 0x02,
    MI_500W_B   = 0x03,
    MI_1000W_A  = 0x04,
    MI_1000W_B  = 0x05,
    MI_1000W_C  = 0x06,
    MI_1000W_D  = 0x07,
    Pro_A       = 0x08,
    Pro_B       = 0x09,
    Pro_C       = 0x0a,
    Pro_D       = 0x0b,
    HM_250W     = 0x0C,
    HM_500W_A   = 0x0D,
    HM_500W_B   = 0x0E,
    HM_1000W_A  = 0x0F,
    HM_1000W_B  = 0x10,
    HM_1000W_C  = 0x11,
    HM_1000W_D  = 0x12,
} PortType;

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

alternativ geht es nach der Implementierung in 
UsartNrf_Send_PackSetPowerLimitCommand()

/***********************************************
** Function name: The second-generation protocol sets the micro-inverse power package
** Descriptions:
** input parameters:
** output parameters:
** Returned value:
*************************************************/
u8 UsartNrf_Send_PackSetPowerLimitCommand(u8 *target_adr, u8 *rout_adr, int8_t MainCmd, u16 SubCmd)
{
    vu8 i = 0;
    vu8 temp_dat[UART_LEN];
    memset((u8 *)temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//start
    temp_dat[0] = (u8)MainCmd;   //command
    memcpy((u8 *)&temp_dat[1], target_adr, 4);
    memcpy((u8 *)&temp_dat[5], rout_adr, 4);
#ifdef DTU3PRO

    if((Dtu3Detail.Property.Zero_Export_Switch == 1) ||
            (Dtu3Detail.Property.DRM_Limit_Switch == 1) ||
            (Dtu3Detail.Property.Phase_Balance_Switch == 1) ||
            (Dtu3Detail.Property.SunSpec_Switch == 1))
    {
        if(MIMajor[PortNO].Property.Acq_Switch == 0)
        {
            //1000w shutdown special control micro-inverse control of 1-to-4 with the last 8 digits of the ID less than 0x50000000
            if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
            {
                temp_dat[9]  = (u8)(SubCmd  >> 8);      //5a5a
                temp_dat[10] = (u8)(SubCmd & 0XFF);
                temp_dat[11] = 11;
                //                  temp = 35*4*10=1400=0x0578;
                temp_dat[12] = 0X05;
                temp_dat[13] = 0X78;
                temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC
                i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution
            }
            else
            {
                temp_dat[9]  = (u8)(CONTROL_OFF_SUB >> 8);      //aa55
                temp_dat[10] = (u8)(CONTROL_OFF_SUB & 0XFF);
                temp_dat[11] = Get_crc_xor((u8 *)&temp_dat[0], 11); //CRC
                i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 12); //forward substitution
            }
        }
        else
        {
            temp_dat[9]  = (u8)(SubCmd  >> 8);      //5a5a
            temp_dat[10] = (u8)(SubCmd & 0XFF);
            temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage
            temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8);    //High 8-bit power limit
            temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff);            //Low power limit 8 bits
            temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC
            i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution
        }
    }
    else
    {
#endif
        temp_dat[9]  = (u8)(SubCmd >> 8);      //5a5a
        temp_dat[10] = (u8)(SubCmd & 0XFF);
        temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage
        temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8);    //High 8-bit power limit
        temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff);            //Low power limit 8 bits
        temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC
        i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution
#ifdef DTU3PRO
    }

#endif
    Uart_SendBuffer[(i + 1)] = ETX; //end
    memset((u8 *)temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

Hier im Beispiel ein HM-1161 mit bis zu 2700 W maximaler 
Spitzenleistung.
Das müsste m.E. dann folgendes Paket ergeben:

1000W: 0x51 0x73109025 0x78563412 0xa5a5 0x03 0x03E8 CRC8
1500W: 0x51 0x73109025 0x78563412 0xa5a5 0x05 0x05DC CRC8
 400W: 0x51 0x73109025 0x78563412 0xa5a5 0x01 0x0100 CRC8

Hierbei ist 0x05 bzw. 0x03 der Wert des (PowerLimit * 10) dividiert 
durch die maximale Leistung (9*300W=2700W) des Inverters (bei 300 W pro 
"Kanal") wobei die HM-Modelle offenbar eine maximale Spitzenleistung 
zwischen 2100 W und 3000 W zur Validierung der führenden Stelle 
verwenden bzw. verkraften ?

Im obigen Beispiel also:

(1000*10)/(300*9)=10000/2700=3.70->(u8) 3
(1500*10)/(300*9)=15000/2700=5.55->(u8) 5
 (400*10)/(300*9)= 4000/2700=1.58->(u8) 1

Danach folgt in zwei weiteren Bytes das PowerLimit nochmal als Hex-Wert, 
hier 0x05DC (1500 W) bzw. 0x03E8 (1000 W) oder 0x0100 (400 W).

Hier noch die Anzahl der "Kanäle" bzw. der maximale 
Spitzenlast-Leistungsindex der Inverter:

typedef enum
{
    InitInverterType = 0,
    Inverter_250 = 1,
    Inverter_500 = 2,
    Inverter_1000 = 4,
    Inverter_Pro = 7,
    Inverter_HM_OneToOne = 8,
    Inverter_HM_OneToTwo = 9,
    Inverter_HM_OneToFour = 10,
} InverterType;

und die entsprechende Routine um den Invertertyp zu bestimmen.

/***********************************************
** Function name: Get the micro-inverse type
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/

InverterType UsartNrf_GetInvterType(u8 *pId)
{
    if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x26) // 0x0260
    {
        return Inverter_Pro; // 7*300W=2100W
    }
    else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x12) // 0x0120
    {
        return Inverter_HM_OneToOne; // 8*300W=2400W
    }
    else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x14) // 0x0140
    {
        return Inverter_HM_OneToTwo; // 9*300W=2700W
    }
    else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x16) // 0x0160
    {
        return Inverter_HM_OneToFour; // 10*300W=3000W
    }
    else
    {
        if(((pId[1] & 0xf0) == 0x10) || ((pId[1] & 0xf0) == 0x20)) //0x0010 || 0x0020
        {
            if(((pId[0] == 0x10) && (pId[1] == 0x22)) || ((pId[0] == 0x11) && (pId[1] == 0x21))) // 0x1022 || 0x1121
            {
                return Inverter_HM_OneToOne; // 8*300W=2400W
            }
            else if(((pId[0] == 0x10) && (pId[1] == 0x19)) || ((pId[0] == 0x10) && (pId[1] == 0x29))) // 0x1019 || 0x1029
            {
                return InitInverterType; // 0*300W=0W
            }
            else // others
            {
                return Inverter_250; // 1*300W=300W
            }
        }
        else if(((pId[1] & 0xf0)  == 0x30) || ((pId[1] & 0xf0) == 0x40)) //500w // 0x0030 || 0x0040
        {
            if(((pId[0] == 0x10) && (pId[1] == 0x42)) || ((pId[0] == 0x11) && (pId[1] == 0x41))) // 0x1042 || 0x1141
            {
                return Inverter_HM_OneToTwo; // 9*300W=2700W
            }
            else if(((pId[0] == 0x10) && (pId[1] == 0x39)) || ((pId[0] == 0x10) && (pId[1] == 0x49))) // 0x1039 || 0x1049
            {
                return InitInverterType; // 0*300W=0W
            }
            else // others
            {
                return Inverter_500; // 2*300W=600W
            }
        }
        else if(((pId[1] & 0xf0) ==  0x50) || ((pId[1] & 0xf0) ==  0x60)) // 0x0050 || 0x0060
        {
            if(((pId[0] == 0x10) && (pId[1] == 0x62)) || ((pId[0] == 0x11) && (pId[1] == 0x61))) // 0x1062 || 0x1161
            {
                return Inverter_HM_OneToFour; // 10*300W=3000W
            }
            else if((pId[0] == 0x10) && (pId[1] == 0x69)) // 0x1069
            {
                return InitInverterType; // 0*300W=0W
            }
            else // others
            {
                return Inverter_1000; // 4*300W=1200W
            }
        }
        else if((pId[0] == 0x12) && (pId[1] == 0x61)) // 0x1261
        {
            return Inverter_Pro; // 7*300W=2100W
        }

        return InitInverterType; // 0*300W=0W
    }
}

[Daniel R. (daniel92)]

Hi Stefan,

Stefan T. schrieb:
> hat eigentlich schon mal jemand versucht den Code von gitee.com
> (iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im
> Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an
> die HM-Wechselrichter versenden / verpacken würde ?

Ja da war ich dran, jedoch denke ich das ich dann an meine grenzen 
gekommen bin. Ich mag es eigentlich nicht alleine zu Coden.^^
Da ich irgendwann Abends nur noch frustriert bin wenn es nicht so voran 
geht wie ich es mir eigentlich wünsche. ^^


> und es sollte evtl. irgendwas wie das Folgende herauskommen:
> 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f

Genau das habe ich letztens auch verschickt... nur ich glaube 
mittlerweile das ich einen kleinen Fehler hatte (der großes bewirkt).
Asche auf mein Haupt - Natührlich möchte ich auch ehrlich sein und den 
Fehler kongretisieren: In der Excel stehen ja die Protkolle wie Sie 
auszusehen haben, daran habe ich mich gehalten. Nur habe ich Bsp. 0x0B 
geschickt, statt 0x0B00 wie es teilweiße im *.c zu sehen ist. ;(

Sobald ich heute Zuhause bin, schaue ich mir das ganze nochmal an. Habe 
mir jetzt paar Tage abstand gehalten und habe wieder einen freien Kopf 
dafür. :)

Danke für eure Hilfe!

> PS: die InverterMajor Struktur sieht wie folgt aus:
Das habe ich auch gesehen.

Edit: Ganz kurz für dumme (wie mich), ich bin kein Profi meine aber auch 
etwas drauf zu haben. ^^

Mir ist auch aufgefallen im Code das sogar Unterschieden wird welcher WR 
genau angesprochen wird. Ob es 1/2/4 Kanal hat und und und...

Ich war kurz davor das ganze zu portieren, jedoch bevor ich mir die 
Arbeit gemacht hätte habe ich zuerstmal versucht direkt aus der 
Paketstruktur die Daten zum WR zu senden und erst wenn das funktioniert 
ein ordentliches funktionen geschrieben damit es später automatisch im 
Hintergrund auch richtig verarbeitet wird (so wie es im code zu sehen 
ist).

Der einzige Knackpunkt womit ich zu kämpfen habe, ich lese ganz gerne 
die einzelnen Hex werte als Byte durch. Bsp: 05 06 07 08 09 0A ...
Wenn mir jemand 0x0500 schreibt, bin ich immer dabei nur die 0x05 zu 
sehen. Was an sich falsch ist! // Daher ein Fehler von mir. ;(

PS: Wenn jemand Lust hat, kann man sich mal auf Discord treffen.
Einfach melden, ich schicke den Einladungslink dann.

[Axel H. (ahinrichs)]

Gerald R. schrieb:
> Ist das hier der richtige?
> 
https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1

Ja, der sollte funktionieren. Wie alle anderen ESP32devkit Klone auch.

[Ziyat T. (toe_c)]

@Stefan T.
@Daniel R.

> typedef enum
> {
>     MI_NO       = 0,
>     MI_250W     = 0x01,
>     MI_500W_A   = 0x02,
>     MI_500W_B   = 0x03,
>     MI_1000W_A  = 0x04,
>     MI_1000W_B  = 0x05,
>     MI_1000W_C  = 0x06,
>     MI_1000W_D  = 0x07,
>     Pro_A       = 0x08,
>     Pro_B       = 0x09,
>     Pro_C       = 0x0a,
>     Pro_D       = 0x0b,
>     HM_250W     = 0x0C,
>     HM_500W_A   = 0x0D,
>     HM_500W_B   = 0x0E,
>     HM_1000W_A  = 0x0F,
>     HM_1000W_B  = 0x10,
>     HM_1000W_C  = 0x11,
>     HM_1000W_D  = 0x12,
> } PortType;

Wie hier ersichtlich, die gite Dokumente beinhalten nicht die 
HM-1200,HM-1500,MI-1200, MI-1500. Diese sind nicht unbedingt 
RF_communication_protocol-V6.5.xlsx kompatibel.
Die könnten ev. gleich sein wie MI_1000W_D/HM_1000W_D, also 4 Kanal 
Modelle, eben nur eventuell..Um das Sniffen kommt man nicht herum, 
MI-1500 hab ich schon.

[Ziyat T. (toe_c)]

Stefan T. schrieb:

> und es sollte evtl. irgendwas wie das Folgende herauskommen:
> 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f

- CMD 0x51 hat kein SubCMD 0x81 ????

- Warum schickst du diese 0x7e/0x7f ???
Diese sind nur für DTU-NRF intern Serial Kommunikation, die werden nicht 
in die Luft geschickt!!

Gruss

[Gerald R. (visitor)]

Axel H. schrieb:
> 
https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1
>
> Ja, der sollte funktionieren. Wie alle anderen ESP32devkit Klone auch.

Danke!

[Daniel R. (daniel92)]

Hallo zusammen,

also ich habe das mal probiert. Kein erfolg.
Bekomme höchstens immer folgende Antwort:

Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 
00 00 00 00 00 00 00 00 00 01 81 eb 9b
Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

[Sigi S. (sermon)]

Daniel R. schrieb:
> also ich habe das mal probiert.

WAS hast Du probiert?

[Daniel R. (daniel92)]

Hallo Sigi,

ich habe probiert Datenpakete zum HM-WR zu senden, so wie isnoahoy 
beschrieben hat. ;)

[Jan-Jonas S. (janjonas_s)]

Stellt euch doch lieber ein PC mit boinc zum verbrennen überschüssigem 
Stroms hin. Dann hat die Wissenschaft auch noch sinnvoll was davon.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Hallo zusammen,
>
> also ich habe das mal probiert. Kein erfolg.
> Bekomme höchstens immer folgende Antwort:
>
> Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00
> 00 00 00 00 00 00 00 00 00 01 81 eb 9b
> Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Wenn du das auch schreiben würdest was du geschickt hast?

edit:
das auch beachten
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Marcel A. (a-marcel)]

> Daniel R. schrieb:
> Hallo zusammen,
>
> also ich habe das mal probiert. Kein erfolg.
> Bekomme höchstens immer folgende Antwort:
>
> Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00
> 00 00 00 00 00 00 00 00 00 01 81 eb 9b
> Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Was du gesendet hast, würde mich auch interessieren, denn ich habe 
bisher noch nicht mal eine Antwort bekommen und das was du da geschickt 
hast ... darauf kann man ja aufbauen und rumspielen.

Danke
Marcel

[Heinz R. (heijz)]

Herbert K. schrieb:
> Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit
> HMT-xxxx, HMS-xxxx, DTU-Pro-S.
>
> Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt.
> Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"
>
> Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt.
> Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless"

Jetzt habt ihr hier einen Thread mit weit über 1000 Beiträgen - Respekt
Ich lese oft nicht nicht mehr mit - alleine weil mi das laden zu lange 
dauert

Aber Herbert - so geht das leider auch nicht
Dann mach doch Dein eigenes Forum für die Hoymiles-WR auf?
Oder überzeuge die Mc-Admins hier eine eigene Unterrubrik zu machen?

Einfach Leute mit für Dich uninteressante Themen abwimmeln - dann erst 
mal raus mit allen Mi-WR-Besitzern, hier geht es um die HM-Serie

VG

[Stefan T. (isnoahoy)]

Hallo Jan-Jonas,
ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das 
DTU-NRF Protokoll an sich ist schon interessant und bei der aktuellen 
Situation wäre es schon praktisch, wenn man die HM-Wechselrichter evtl. 
mit einem eigenen Grid Profile (laut Source Code kann man ein 1200 
Punkte langes Window-Frame aufnehmen (Sinux, Sägezahn, Rechteck, etc. 
=^} welches dann m.E. zur Analyse und Nachbildung der aktuellen 
Wechselstromkurve dient) bestücken könnte oder gar die Firmware updaten 
kann ...
Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren, 
einfach die Hauptsicherung rausdrehen und ab geht die Luzie! Jaja ich 
weiß darf man natürlich alles nicht wenn (solange) es an das 
Niedervolt-Netz des lokalen Elektrizitätversorgers angeschlossen ist.

@Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen 
Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es 
den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir 
mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^!

@Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End 
Transmission Bytes, die die DTU Software für die SPI Kommunikation mit 
dem NRF24 Modul als STX/SOF und ETX/EOF einfügt. Die kannst DU auch 
gerne weglassen, weil sie evtl. von der NRF24 Bibliothek eh eingefügt 
werden. Ich habe Sie nur im Zusammenhang mit der analysierten Code 
Stelle erwähnt.
Wegen den PortType's gehe ich davon aus, dies sind die einzelnen DC 
Eingangsports der unterschiedlichen HM- und MI-Wechselrichter Typen. Die 
eigentlichen Invertertypen werden in UsartNrf_GetInvterType() aus der 
Pre_Id also den ersten beiden Bytes der Seriennummer (z.B. 1141 bei 
meinem HM-600 führt zu einem Inverter_HM_OneToTwo) abgeleitet.
Die DC PortType's werden hingegen bei der Berechnung der einzelnen 
Leistungen berücksichtigt / unterschieden, da ja jeder Eingang (DC Ports 
A/B/C/D) auch unterschiedlich viel Ertrag bringen kann. Das wird dann 
m.E. in AntiReflux.c/.h gebraucht um die Leistung aller Wechselrichter, 
die von einer DTU kontrolliert werden, möglichst gleichmäßig auf alle 
drei AC Phasen A/B/C zu verteilen.

@Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll 
zumindest die elektronische und funkseitige Komponente der HMT- / HMS- 
und DTU-Pro-S in einem übersichtlichen Thread zu behandeln. Keine Ahnung 
ob dafür aber zwei/drei separate Threads notwendig & hilfreich sind (da 
vermutlich keiner von uns dort regelmäßig liest) und wie viele Anfragen 
dazu überhaupt reinkommen. Andererseits scheint die DTU-PRO-S eventuell 
sogar den selben Basis Code wie im gitee.com zu verwenden. Es gibt 
zumindest eine Vielzahl von #ifdef DTU3PRO und die aktivieren einen 
stm32f4xx anstelle eines stm32f10x Prozessors. Vielleicht finden sich ja 
irgendwo auf einer FCC ID Seite irgendwelche Informationen zur CPU ?

[Daniel R. (daniel92)]

Stefan T. schrieb:
> @Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen
> Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es
> den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir
> mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^!

Kann ich heute anhängen, log sei dank. =)

[John P. (brushlesspower)]

Thomas B. schrieb:
> Es gibt noch etliche Stellen die nicht perfekt sind, einer
> Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte
> erstmal was lauffähiges haben.
> Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU
> Im docs Ordner gibt es auch ein paar Screenshots der WebGUI.
>
> In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking
> Changes" geben was die Namen der MqTT Topics anbelangt.
> Die Payload Erzeugung habe ich auch schon in die Inverter Klassen
> verlegt. Dies ist jedoch mangels Test noch nicht commited.
>
> Über Anregungen und/oder PRs würde ich mich freuen.
>
> Grüße
> Thomas

Hallo Thomas,

ich habe es gestern endlich geschaft deine ESP32 Version mit meinem 
HM-400 zu testen.

Es lief auf anhieb ohne Probleme.

2 Dinge sind mir mit der aktuellen Version aufgefallen:
- Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone 
zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten 
Tabelle
- MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und 
im  Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es 
kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob 
MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK 
ist.
Eventuell liegts auch am MQTT Server?

[Axel H. (ahinrichs)]

John P. schrieb:
> Thomas B. schrieb:
>
>> Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU
>
> Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone
> zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten
> Tabelle

Da war ich schon dran und hab auch einen PR gemacht. Den könntest du 
probieren. Als nächstes wollte ich noch die NavBar und das Scrolling 
angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu 
About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei 
Tablet / mobile aufgefallen war.

[Ziyat T. (toe_c)]

Stefan T. schrieb:
> Hallo Jan-Jonas,
> ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das

Es sind Leute da, die nicht in Deutschland leben, es gibt Laender da 
darfst du nichts einspeisen, wenn dann bezahlst du die Einspeisung auch!


> Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren,

Die Gedanken habe ich auch gemacht, es waere nett ;-)

> @Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End
> Transmission Bytes, die die DTU Software für die SPI Kommunikation mit
> dem NRF24 Modul als STX/SOF und ETX/EOF einfügt.

Das meinte ich ja auch, waere besser hier ohne STX/SOF und ETX/EOF zu 
kommunizieren, weil es mich irritiert, ob ihr das Packet mit oder ohne 
sendet

> @Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll
> zumindest die elektronische und funkseitige Komponente der HMT- / HMS-
> und DTU-Pro-S in einem übersichtlichen Thread zu behandeln.

Vorlaeufig finde es auch

[Thomas B. (tbnobody)]

Axel H. schrieb:
> Da war ich schon dran und hab auch einen PR gemacht. Den könntest du
> probieren. Als nächstes wollte ich noch die NavBar und das Scrolling
> angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu
> About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei
> Tablet / mobile aufgefallen war.

Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute 
Abend mal drüber schauen.

[Thomas B. (tbnobody)]

John P. schrieb:
> - MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und
> im  Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es
> kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob
> MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK
> ist.
> Eventuell liegts auch am MQTT Server?

Könntest du für solche Themen ggf. bitte einen Issue auf Github 
aufmachen? Dann bleibt hier der Thread für die wichtigen Themen frei.
Hast du ACL's konfiguriert? Ein MQTT Client kann nämlich nicht 
feststellen ob er an die entsprechende Topic publishen darf. Wenn das 
z.B. durch ACL's (oder Benutzer rechte) verboten ist gehen die 
Nachrichten einfach unter. Ich habe das selbst mit einem Mosquitto 
(letzte Debian Pakete von mosquitto.org also Version 2.x) Broker im 
Einsatz und kann erst mal keine Probleme feststellen.

[Axel H. (ahinrichs)]

Thomas B. schrieb:
> Axel H. schrieb:
>> Da war ich schon dran und hab auch einen PR gemacht. Den könntest du
>> probieren. Als nächstes wollte ich noch die NavBar und das Scrolling
>> angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu
>> About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei
>> Tablet / mobile aufgefallen war.
>
> Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute
> Abend mal drüber schauen.

Lass Dich nicht stressen. Die PRs werden auch nicht dauerhaft in der 
Frequenz kommen. Hab hier gerade in Betrieb genommen und arbeite meine 
Liste ab. Wenn ich schon nichts zum RE des Protokolls beitragen konnte. 
Dafür übrigens herzlichen Dank an alle Beteiligten! Mit zu lesen und zu 
fiebern hat extrem viel Freude gemacht und war erkenntnisreich!

Als ich im März bestellt hatte, war das die eine Kröte, die ich 
geschluckt habe. Dass Auslesen nur über die Cloud geht und ich da halt 
drauf verzichten werde. Dass das jetzt doch geht ist ganz hervorragend!

[Ronny (Gast)]

Hallo zusammen,

ich lese sporadisch mit und bin auf der Suche nach einer Lösung für 
meinen HM-1500.
Leider reichen meine Kenntnisse nicht aus, dass hier alles geschriebene 
nachzuvollziehen und zu verstehen.

Daher meine Frage, gibt es von euch bereits ein fertiges Produkt was ich 
kaufen könnte? Im Moment habe ich das DTU Teil im Einsatz, allerdings 
gefällt es mir überhaupt nicht, dass ich so viele Daten preisgeben muss.

Vielen Dank für eure Antwort.

Gruß

[Daniel R. (daniel92)]

Hallo Ronny,

es gibt verschiedene Lösungen. Es kommt drauf an was für dich am 
einfachsten ist.
Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann... 
dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und 
Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine 
kleine Bezahlung?).

Natührlich wird hier daran weiter gearbeitet.
Ich habe auch noch viele Ideen was man hinzufügen kann.

Jedoch wird aktuell verstärkt an der Limitierung gearbeitet.

Im Grunde geht das Auslesen der Werte.

Mehr aus dem Github zu entnehmen:
https://github.com/grindylow/ahoy/ (hier wird m.E verstärkt gearbeitet)
oder
https://github.com/tbnobody/OpenDTU

[Daniel R. (daniel92)]

Marcel A. schrieb:
> Was du gesendet hast, würde mich auch interessieren, denn ich habe
> bisher noch nicht mal eine Antwort bekommen und das was du da geschickt
> hast ... darauf kann man ja aufbauen und rumspielen.

Poll inverter 116174403329
2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8
2022-07-05 14:35:31.453370 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8
2022-07-05 14:35:32.693952 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8
2022-07-05 14:35:33.931475 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8
2022-07-05 14:35:33.980149 Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
2022-07-05 14:35:34.483548 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
 payload has valid modbus crc
 payload has 14 bytes

Field view: int
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>B       128     0     0     0     0     0     0     0     0     0     0     0     0     1

Field view: shorts
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>H           32768           0           0           0           0           0           1
>H                     0           0           0           0           0           0

Field view: longs
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>L                  2147483648                       0                       0
>L                                 0                       0                       0
>L                                       0                       0                       1
>L                                             0                       0
 type utf-8  : utf-8 decode error
 type ascii  : ascii decode error

und

2022-07-05 16:11:51.881684 Transmit 17 | 51 74 40 33 29 78 56 34 12 81 0b 00 03 eb 00 01 14
2022-07-05 16:11:53.117722 Transmit 17 | 51 74 40 33 29 78 56 34 12 81 0b 00 03 eb 00 01 14
2022-07-05 16:11:53.164533 Received 27 bytes channel 61: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
2022-07-05 16:11:53.668439 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Die Log hängt im Anhang.

Diesen Payload bekomme ich so oft, sind in der Log 189 mal zu finden.

Discord Link für alle: https://discord.gg/2jUFfKkD

[Eike (Gast)]

Moin,
kann mal einer die Teileliste posten bitte was ich brauche, damit ich es 
alles zusammen löten kann :)


Danke
Eike

[Kellner (Gast)]

@Eike (Gast):  Dies ist kein Restaurant mit Kellner !
Dies ist ein Buffet. Da muss man sich selbst bedienen !
Alles was Du wissen möchtest wurde in vorherigen Beiträgen mehrfach 
beschrieben. Teilweise mit Fotos, Links, Bezugsquellen, 
Verdrahtungsplänen. Du brauchst Dir nur die Informationen vom 
Buffet=Beiträge nehmen.

[tom (Gast)]

vielleicht kann mir einer helfen
ich hab seit gestern einen d1 mini mit dem funkmodul laufen
soweit funktioniert alles gut, webseite läuft und die daten kommen auch 
beim iobroker an.
nur leider ist der d1 mini immer wieder im netzwerk nicht mehr 
erreichbar
ping bricht ab.
ich hab noch einige andere d1 mini laufen wodurch ich ein wlan problem 
ausschließe
was könnte da sein?
version hab ich die 0.4.20

[Günter H. (gnter_h534)]

tom schrieb:
> nur leider ist der d1 mini immer wieder im netzwerk nicht mehr
> erreichbar
> ping bricht ab.

Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83

Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich.

Versucht werden kann:
- Anderes Netzteil/Kabel,
- Elko über +/GND des nRF24L01+,
- das Abfrageintervall auf 30 s einstellen.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
Marcel A. schrieb:
>> Was du gesendet hast, würde mich auch interessieren, denn ich habe
>> bisher noch nicht mal eine Antwort bekommen und das was du da geschickt
>> hast ... darauf kann man ja aufbauen und rumspielen.
>
> [code]
> Poll inverter 116174403329
> 2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81
> 5a 78 35 61 00 78 30 31 01 00 f8

Hab schon mal drauf hingewiesen: CMD 0x51 hat kein SubCMD 0x81, dann 
0x5a etc. oder hab ich etwas übersehen?
Dann sehe ich Unixtimestamp drin, Tue Jul 27 2021 21:18:40 GMT+0000

Dieses Polling für HM kann nicht gehen.

Set Time/Data geht z.Bsp. so CMD 0x15 mit SubCMD 0x80 und Timestamp:
15 72220200 72220200 80 0B 00 62 09 04 9b 00 00 00 00 00 00 00 00 F2 68 
F0


CMD 0x51 hat SubCMD 0x5A5A für Limitierung
CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock
Und diese funktionieren scheinbar nur mit MI-1500, bisher..

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> CMD 0x51 hat SubCMD 0x5A5A für Limitierung
> CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock
> Und diese funktionieren scheinbar nur mit MI-1500, bisher..

Das ist korrekt! Steht ja auch in der Excel/c-File.

[tom (Gast)]

Günter H. schrieb:
> tom schrieb:
>> nur leider ist der d1 mini immer wieder im netzwerk nicht mehr
>> erreichbar
>> ping bricht ab.
>
> Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83
> Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich.
> Versucht werden kann:
>
> Anderes Netzteil/Kabel,
> Elko über +/GND des nRF24L01+,
> das Abfrageintervall auf 30 s einstellen.

Danke für die Infos, werde ich testen.
Welcher Elko wäre ideal?

[Sigi S. (sermon)]

Ich n

tom schrieb:
>> Anderes Netzteil/Kabel,
>> Elko über +/GND des nRF24L01+,
>> das Abfrageintervall auf 30 s einstellen.

Ich nutze ein Iphone Netzteil.
Ohne Elko etc.

Elko >= 1000 uF / 10 Volt passt auf jeden Fall.
Ein 100 nF zus. parallel kann auch nicht schaden.

[Günter H. (gnter_h534)]

Hier
https://github.com/grindylow/ahoy
gibt es für das D1 mini-Board die Firmware Version 0.4.22.

Das Kompilieren geschieht jetzt über Visual Studio Code/Platformio.

Da ich diese Software vor einigen Tagen zum Testen der Firmware für das 
ESP32-Board installiert hatte, wurde nach Download des 
"ahoy-main.zip"-Ordners und dem Öffnen der "platformio.ini" mit dem 
"Platformio: Build"-Befehl (überraschenderweise) erfolgreich eine 
"firmware.bin" erzeugt. Im Platformio-Explorer findet  man den 
Speicherort der neuen Firmware - ggf. im Windows-Explorer suchen.

Mit dieser neuen Firmware habe ich dann von Version 0.4.20 problemlos 
ein Update auf 0.4.22 gemacht.

Was das Update in Richtung Stabilität bringt, kann ich naturgemäß noch 
nicht sagen.

Der Text oben ist von jemandem verfasst, der von Programmieren praktisch 
null Ahnung hat.

Die Default-Verschaltung ab 0.4.20 habe ich mit angehängt.

[Rene M. (Firma: Bitte wählen) (renmo)]

Kannst du die neue -.bin auch raufladen?
Bei mir funzt das mit platformIO nicht

[Günter H. (gnter_h534)]

Firmware 0.4.22 für D1 mini.

[Rene M. (Firma: Bitte wählen) (renmo)]

Danke dir!

[tom (Gast)]

hab vorhin gerade die 0.4.22 drauf gespielt.
die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der 
seriele debug print weiter läuft auch wenn der d1 mini per netzwerk 
nicht mehr erreichbar ist?

[Holger S. (skusi)]

Daniel R. schrieb:
> Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann...
> dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und
> Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine
> kleine Bezahlung?).

Das war eigentlich mein Plan. Also eine Platine layouten, fertigen 
lassen und für die die nicht löten wollen/können würde ich die auch 
bestücken und alles in eine feines Gehäuse packen um das Ganze dann für 
Selbstkostenpreis + kleiner Aufwandsentschädigung anzubieten.

Nun habe ich die Platine ja schon fertig, und zur Probe mal eine selbst 
geätzt und bestückt. Leider hat sich herausgestellt das der Empfang sehr 
viel schlechter ist als mit der Breadboard Version :(

Dann habe ich die Schirmung des RF24 entfern, keine Besserung.
Dann habe ich das Netzteil entfernt und per USB versorgt, keine 
Besserung.
Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt 
positioniert, keine Besserung.
Die Platine unter Lupe natürlich optisch auf Fehler untrsucht, 
durchgemessen, nix zu finden.
Den RF ausgetauscht, keine Besserung.

Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang 
bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m 
Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern 
muss damit es so gut funktioniert wie auf dem Steckbrett.
Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört 
die Massefläche der Platine ?

Ich komm nicht weiter ...

[oxylog (Gast)]

Holger S. schrieb:
> Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört
> die Massefläche der Platine ?

Ich habe mir als purer Anfänger meine Platinen bei Aisler "schnitzen 
lassen" - funktionieren problemlos ohne Empfangsprobleme.
Ich habe den D1 direkt neben dem NRF24l01+ (nicht über) und dachte mir 
erst "das geht schief" - tut was es soll ohne große Schirmung.
Entweder die wirklich "räumliche Nähe" oder die Massefläche

[tom (Gast)]

tom schrieb:
> hab vorhin gerade die 0.4.22 drauf gespielt.
> die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der
> seriele debug print weiter läuft auch wenn der d1 mini per netzwerk
> nicht mehr erreichbar ist?

kann es sein das die probleme vom webserver kommen?
wenn ich ganz oft die webseite aktualisiere fällt die netzwerkverbindung 
bei mir aus.

ist das bei euch auch?

[Günter H. (gnter_h534)]

Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update (vor 
knapp 4 Std.) stabil.

[Lukas P. (lumapu)]

Rene M. schrieb:
> Kannst du die neue -.bin auch raufladen?
> Bei mir funzt das mit platformIO nicht

Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine 
erste CI (GitHub Actions), die nach dem Commit von Code die Firmware 
automatisch baut und sogar als Artifakt zum Download zur Verfügung 
stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90 
Tage, dann werden die automatisch gelöscht.

Hier z.B. das von gestern:
https://github.com/grindylow/ahoy/actions

dann auf den obersten Eintrag klicken, ganz unten erscheint dann das 
Artifakt

[tom (Gast)]

Günter H. schrieb:
> Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update
> (vor
> knapp 4 Std.) stabil.

das hatte ich auch schon probiert, leider ohne verbesserung, auch mit 
60s hab ich probiert

[Holger S. (skusi)]

Günter H. schrieb:
> Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update (vor
> knapp 4 Std.) stabil.

[Richard K. (laserrichi)]

Holger S. schrieb:

>
> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang
> bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m
> Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern
> muss damit es so gut funktioniert wie auf dem Steckbrett.
> Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört
> die Massefläche der Platine ?
>
> Ich komm nicht weiter ...

Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit 
2,4Ghz !!
Nebeneinander mit Abstand und der Variante ein Blech das man dazwischen 
einlöten kann. Und den Wemos gleich mit Pigtail für externe Antenne 
nehmen.
Die kurzen Leiterbahnen vom Chip zur Antenne strahlen ja auch schon was 
aus.

[Stefan T. (isnoahoy)]

Hallo Holger S.,

wenn ich mir die Erfahrungen / Kommentare zu Deiner Platine und den 
Aufbau der Anderen durchlese fällt mir auf, daß nur Du auch den AC/DC 
Transformator und den Spannungsregler mit auf der Platine hast.

Hast Du Dir mal die Spannung am ESP mit einem Oszi angeschaut ?

Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und 
dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du 
ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat.
Sind ja immerhin 50Hz ?

[Daniel R. (daniel92)]

Holger S. schrieb:
> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang
> bei meinem Aufbau.

Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken 
sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden. 
Trotzdem könnte ich mir das vorstellen.

Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und 
platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch?

Ok,  Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D

[Claus T. (Gast)]

Hallo Holger,
hast du schlechten Empfang oder gar keinen Empfang?
Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich 
das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen 
ob die Verbindung auf deiner Platine stimmt.
Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung 
von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da 
sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht 
sehr knapp aus.

Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand 
zwischen der 230V AC Seite zur Niederspannungsseite. Der 230V AC Bereich 
sollte eindeutig von der Niederspannungsseite getrennt sein.
Wenn ich mich recht erinnere, muss man hier 8mm Abstand einhalten.
Am besten den Stabi mit Elko zwischen ESP und Netzteil-Modul 
positionieren. Evtl. auch das Netzteil um 90 Grad drehen.
Und die Sicherung auf der AC Seite nicht vergessen, außer du hast sie in 
der Netz-Leitung integriert.

[Günter H. (gnter_h534)]

Lukas P. schrieb:
> Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine
> erste CI (GitHub Actions), die nach dem Commit von Code die Firmware
> automatisch baut und sogar als Artifakt zum Download zur Verfügung
> stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90
> Tage, dann werden die automatisch gelöscht.
>
> Hier z.B. das von gestern:
> https://github.com/grindylow/ahoy/actions
>
> dann auf den obersten Eintrag klicken, ganz unten erscheint dann das
> Artifakt

Danke für diesen Hinweis, das ist ein sehr einfacher und schneller 
Zugang zur aktuellen bin-Datei.

Ergänzung: Man muss bei guthub angemeldet sein, um das Artifakt 
herunterladen zu können.

[John P. (brushlesspower)]

Holger S. schrieb:
> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang
> bei meinem Aufbau.

Wenn man sich das Layout anguckt fällt mir etwas auf:

Der Elko ist völlig nutzlos. Dieser gehört nicht irgendwo auf die 
Leiterplatte, sondern nach an den NRF24L01+.

Die 6mm Abstand (oder Fräsung) zwischen 230V und Niederspannung wurden 
schon erwähnt. Sind aber nicht die Ursache deines Problems.

Wenn du deine Layout datein mit uns teilst können wir noch mehr tipps 
geben.

[Peter L. (leliep)]

Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen 
Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT 
mit zu übertragen?

Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man 
beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen 
anderen Weg...?

[Axel H. (ahinrichs)]

Holger S. schrieb:
> Ich weiß nicht was ich verändern
> muss damit es so gut funktioniert wie auf dem Steckbrett.

Disclaimer: Ich habe weder beruflich noch in der Ausbildung mit Platinen 
oder Schaltungen zu tun!

Hallo Holger,

wenn ich das richtig erkannt habe, dann finde ich die GND-Verbindung vom 
RF24 nicht optimal. Die geht auf den Fotos nur durch das GND-Pad vom 
Wemos. Ob die Empfangsprobleme damit zu tun haben, könnte man mit einer 
schnellen Kabelbrücke testen.

Und dann wollen doch die meisten LDO auch noch einen Kondensator am 
Ausgang. Gerade die RF24 scheinen doch relativ empfindlich auf die 
Restwelligkeit zu reagieren. Hatte ich so zumindest beim Mitlesen für 
mich rausgeschlossen.

Aber beides nur spontane Ideen eines Hobbyisten.

Gruß
Axel

[Claus T. (Gast)]

Ist da GND und 3,3V wirklich getrennt?

[Peter L. (leliep)]

Daniel R. schrieb:
> Holger S. schrieb:
>> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang
>> bei meinem Aufbau.
>
> Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken
> sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden.
> Trotzdem könnte ich mir das vorstellen.
>
> Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und
> platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch?
>
> Ok,  Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D

Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit 
Reboots) mit dem WR. Distanz zum WR ca. 15m.

https://www.mikrocontroller.net/attachment/560492/DE6F5772-A240-4F90-AB27-12E40A65CEF2.jpeg

[tom (Gast)]

hat schon jemand versucht den webserver mal abzuschalten und schauen ob 
der d1 mini dann immer noch neustartet?

[Lukas P. (lumapu)]

Peter L. schrieb:
> Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen
> Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT
> mit zu übertragen?
>
> Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man
> beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen
> anderen Weg...?

ioBroker hat für jedes Objekt mehrere Timestamps, zB wann es erzeugt 
wurde und wann es zuletzt aktualisiert wurde. Ich kann mir vorstellen, 
dass sich andere Systeme hier genauso verhalten und sehe daher keine 
Notwendigkeit den timestamp extra zu schicken.

@Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen 
Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt:
https://github.com/grindylow/ahoy/issues/83

[Holger S. (skusi)]

Stefan T. schrieb:
> Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und
> dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du
> ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat.
> Sind ja immerhin 50Hz ?

Zitat aus meinem Post:
"Dann habe ich das Netzteil entfernt und per USB versorgt, keine
Besserung."

Daniel R. schrieb:
> Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und
> platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch?

Richard K. schrieb:
> Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit
> 2,4Ghz !!

Zitat aus meinem Post:
"Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt
positioniert, keine Besserung."

Claus T. schrieb:
> hast du schlechten Empfang oder gar keinen Empfang?
> Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich
> das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen
> ob die Verbindung auf deiner Platine stimmt.
> Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung
> von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da
> sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht
> sehr knapp aus.
> Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand
> zwischen der 230V AC Seite zur Niederspannungsseite.

Der Empfang ist da, aber es werde sehr viele Fails erzeugt und von den 6 
Invertern sind meist nur 2 available.
Die Leiterbahnen sind OK. Das ist schlecht zu fotografieren. Aber unter 
der Lupenlampe nochmal gecheckt und durchgemessen hatte ich das ja auch. 
Das hätte auch gleich smoke gegen wenn da ne Verbindung ist. Der Aufbau 
funktioniert ja auch, nur der Empfang taugt nix.

Den Abstand 230V werde ich noch vergrößern. Wahrscheinlich lasse ich das 
on Board Netzteil wohl auch weg. Ich dachte es wäre ne gute Idee, aber 
wenn ich den Wemos und den RF24 nebeneinander setzten muß, und die 
Abstände vergrößern soll, wird mir das ganze schon wieder zu groß und 
muß in ein anderes Gehäuse. Dann eben nicht kompakt und mit extra USB 
Nezteil.

Peter L. schrieb:
> Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit
> Reboots) mit dem WR. Distanz zum WR ca. 15m.

Tja, deshalb bin ich ja so Ratlos.

[Zsolt Z. (zsolt_z)]

Dear All,
At first let me express my respect to all who contributes to this topic.
I am follwing this thread since a while and I am using the pre-compiled 
version 0.4.19 on a Wemos D1 mini clone anf HM-800 inverter and Home 
Assistant.
The pre-compiled image works for me only when I use pins D2/D1 instead 
of D4/D3 for signal CE/IRQ.

Hello Marcel,

I am trying to compile your ESPhome version on a 8266 (Wemos D1 mini 
clone)
ESPHome version: 2022.5.1

I am facing with an issue defining the serial number of the inverter.
If I set the serial number as a hex number ( 12 digit decimal number 
converted to hex) like in your example file:

        serialnumber: "0x1234567890"

then the ESPhome enters to a boot loop with the following output on the 
console:

[C][api:025]: Setting up Home Assistant API server...
[D][hoymiles.esp32:046]: Setting up Hoymiles Component
E: inverter type can't be detected!
[I][hoymiles.esp32:065]: Adding Inverter: hm800 ( 0x0 )
I: RF24 Amp Pwr: RF24_PA_I: LOW
I: Radio Config:
SPI Frequency           = 1 Mhz
                               Channel                  = 3 (~ 2403 MHz)
RF Data Rate            = 250 KBPS
RF Power Amplifier      = PA_LOW
RF Low Noise Amplifier  = Enabled
CRC Length              = 16 bits
Address Length          = 5 bytes
Static Payload Length   = 32 bytes
Auto Retry Delay        = 250 microseconds
Auto Retry Attempts     = 0 maximum
Packets lost on
                   current channel      = 0
Retry attempts made for
                           last transmission    = 15
Multicast               = Disabled
Custom ACK Payload      = Disabled
Dynamic Payloads        = Enabled
Auto Acknowledgment     = Disabled
Primary Mode            = RX
TX address              = 0xdeadbeef01
pipe 0 (closed) bound   = 0xdeadbeef01
pipe 1 ( open ) bound   = 0x1234567801
pipe 2 (closed) bound   = 0xc3
pipe 3 (closed) bound   = 0xc4
pipe 4 (closed) bound   = 0xc5
pipe 5 (closed) bound   = 0xc6
[I][hoymiles.sensor:010]: Sensor hm800, ▒H#@
[I][app:062]: setup() finished successfully!

If I set it as a decimal number (as it is printed on the HW, either with 
or without quotes):

        serialnumber: "114180445566"

then it does not enter the boot loop, but prints the following:

[D][hoymiles.esp32:046]: Setting up Hoymiles Component
E: inverter type can't be detected!
[I][hoymiles.esp32:065]: Adding Inverter: hm800 ( 0x7fffffff )
I: RF24 Amp Pwr: RF24_PA_I: LOW
I: Radio Config:
SPI Frequency           = 1 Mhz
                               Channel                  = 3 (~ 2403 MHz)
RF Data Rate            = 250 KBPS
RF Power Amplifier      = PA_LOW
RF Low Noise Amplifier  = Enabled
CRC Length              = 16 bits
Address Length          = 5 bytes
Static Payload Length   = 32 bytes
Auto Retry Delay        = 250 microseconds
Auto Retry Attempts     = 0 maximum
Packets lost on
                   current channel      = 0
Retry attempts made for
                           last transmission    = 15
Multicast               = Disabled
Custom ACK Payload      = Disabled
Dynamic Payloads        = Enabled
Auto Acknowledgment     = Disabled
Primary Mode            = RX
TX address              = 0xdeadbeef01
pipe 0 (closed) bound   = 0xdeadbeef01
pipe 1 ( open ) bound   = 0x1234567801
pipe 2 (closed) bound   = 0xc3
pipe 3 (closed) bound   = 0xc4
pipe 4 (closed) bound   = 0xc5
pipe 5 (closed) bound   = 0xc6
[I][hoymiles.sensor:010]: Sensor hm800, ▒H#@
[I][app:062]: setup() finished successfully!

What am I doing wrong?

[Herbert K. (avr-herbi)]

Zsolt Z. schrieb:

Hello Zsolt, you can try this. I don´t know if it is working so.

Example (see hmRadio.h)
// Serial WR  : 1141 74 11 22 33  Label on Inverter
try
// #define WR1_RADIO_ID            ((uint64_t)0x 33 22 11 74 01ULL) 
only for better readable for your eyes
// #define WR1_RADIO_ID            ((uint64_t)0x 74 11 22 33 01ULL) 
only for better readable for your eyes

(see hmRadio.h)
// in Source Code
#define WR_RADIO_ID            ((uint64_t)0x3322117401ULL)
// OR try
#define WR_RADIO_ID            ((uint64_t)0x7411223301ULL)

You have to change the example to YOUR serial number.

[Ziyat T. (toe_c)]

Holger S. schrieb:
> Stefan T. schrieb:
> Daniel R. schrieb:
> Richard K. schrieb:
> Claus T. schrieb:
> Peter L. schrieb:
> Tja, deshalb bin ich ja so Ratlos.

Hallo
Ich hatte lange auch ab und zu den ganzen Tag Empfang Probleme mit 
Wemos, ich verwende meine spez. SW-Version auf Hubi's Basis.
Ich habe es lange gemessen und gesnifft, das Problem war nicht die HW ! 
(Edit: ich dachte auch mal die NRF sind futsch..)

- Ich würde mal die SW ohne Interrupt mit polling und ohne CRC 
ausprobieren. Ich bin ziemlich sicher, dass mit Interrupt etwas verloren 
geht, warum weiss ich nicht. Mit CRC geht vieles auch verloren. Ohne CRC 
sind die Werte fast 97% richtig, die Falschen kann man ausfiltern.

- Ich bin auch ziemlich sicher, dass die WR's nicht immer auf CH3 
senden, die SW muss beim RX auch hoppen. Mein MI-1500 sendet manchmal 
einen Tag lang nur über CH61/CH75. Wenn die SW nur auf CH3 hört, siehst 
du den ganzen Tag nichts!

Edit: versucht mal mit einer NRF24 Sniffer SW ob ihr mit der Dose etwas 
empfaengt?

[Denny S. (nightstorm99)]

Hallo Zusammen,

erstmal vielen Dank für die tolle Arbeit hier.

Mein Setup:
- DTU-Lite
- HM1500 - 4 Module
- HM800 - 2 Module
- weitere 4 HM1500 kommen noch dazu

An meinem DTU-Lite habe ich über die Cloud alles verbunden mit dem 
HM1500.
Leider kann der DTU ja nur 4 Module, deshalb bin ich jetzt auf die 
8266/RF24 Lösung gestoßen und habe dieses gleich umgesetzt.

Bisher läuft dieses, aber wenn ich den DTU-Lite und den 8266 am laufen 
haben, dann erhalte ich vom HM1500 oft keine Daten. Der HmM800 hat diese 
Probleme nicht.
Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite 
hängt und dadurch irgend welche Daten verloren gehen.

Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem?

Vielen Dank
Gruß

[Herbert K. (avr-herbi)]

Denny S. schrieb:
> - DTU-Lite
> - HM1500 - 4 Module
> - HM800 - 2 Module
...
> Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem?

Du kannst ja auch nicht 2 PKWs gleichzeitig fahren  :-)
Vermutlich hat der HM1500 Probleme mit 2 DTUs zu kommunizieren ?

1. Möglichkeit:  DTU-Lite Stromversorgung kappen - also aus das Teil

2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see 
hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und 
dann schauen, ob das dann funktioniert.

Wenn ich nix überlesen habe, hat das wohl noch niemand probiert.
Also zack und los  :-)  Du darfst als Erster  :-)
Bin selbst gespannt. Viel Erfolg !

[Denny S. (nightstorm99)]

Variante 1 geht, aber ich würde gerne beides nutzen. Eine DTU-Pro habe 
ich schon geordert, damit ich in Zukunft alle HM's auslesen kann.
Wieviele HM's kann der 8266 mit AHOY gleichzeitig lesen? Hat das jemand 
mal getestet?

Variante 2 hatte ich schon probiert, aber dann bekomme ich überhaupt 
keine Daten mehr.
Kann aber auch sein das ich mit der Seriennummer was falsch gemacht 
habe.
Diese beginnt mit: 10D98015XXXX
Muss ich diese 1zu1 in die Zeile kopieren?
#define DTU_RADIO_ID            ((uint64_t)0x1234567801ULL)


Danke

[Herbert K. (avr-herbi)]

schau heute um 10:25. Da hab ich geschrieben wie die SN einzutragen ist.
Die letzten 4 Zahlenpaare der SN. Musst einfach Beides mal probieren.
Die Anzahl der WR kannst Du auch irgendwo konfigurieren vor dem 
Übersetzen.

[Ziyat T. (toe_c)]

Herbert K. schrieb:

> 2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see
> hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und
> dann schauen, ob das dann funktioniert.

So hab ich die DTU-Pro<>MI-1500 gesnifft, schon am Anfang des Projekts. 
Wenn du die gleiche Adresse eingibst wie die DTU, kannst alles mithören 
was der WR sendet.

[Ziyat T. (toe_c)]

Denny S. schrieb:

> Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite
> hängt und dadurch irgend welche Daten verloren gehen.

Der WR hat keine Ahnung von der Cloud, nur die DTU haengt an der.

Zum parallel Betrieb, siehe
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Stefan T. (isnoahoy)]

tom schrieb:
> hat schon jemand versucht den webserver mal abzuschalten und schauen ob
> der d1 mini dann immer noch neustartet?

Lukas P. (lumapu) schrieb:
> @Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen
> Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt:
> https://github.com/grindylow/ahoy/issues/83

Ich persönlich glaube, daß die von Tomas B genutzte AsyncWebServer 
Bibliothek evtl. auch das Problem behebn könnte. Momentan verwenden wir 
die ESP8266WebServer Library und die blockiert bis die Seite 
ausgeliefert wurde.
Ich habe keine Ahnung wie die AsyncWebServer Bibliothek es genau macht, 
aber anscheinend kann diese mehrere Requests parallel beantworten und 
hat dazu so eine Art "Multithreading". Zumindest wird der Listener immer 
gleich wieder freigegeben und steht dann für weitere Verbindungen zur 
Verfügung. Vielleicht eine Funktion der AsyncTCP Bibliothek die als 
Abhängigkeit dazu kommt.

@Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266 
Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den 
ESP8266 übersetzen ?

[Thomas B. (tbnobody)]

Stefan T. schrieb:
> @Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266
> Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den
> ESP8266 übersetzen ?

ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist 
so out of the Box wohl nicht möglich, da ich diverse Compiler und Linker 
Features verwende die im Toolkit vom 8266 nicht vorhanden sind.

[Daniel M. (daniel_m821)]

Denny S. schrieb:
> Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite
> hängt und dadurch irgend welche Daten verloren gehen.

Moin,
ich habe einen HM-1500 und frage ihn alle 10s mit ESP8266 und ESP32 ab, 
unterschiedliche DTU-ID's, keine Probleme.

Dem WR ist es eigentlich egal, er antwortet stumpf. Das was ich mir 
vorstellen kann, das er Probleme hat mit unterschiedlichen Zeitframes, 
die er bekommt oder die Abfragen zu schnell nacheinander kommen.

Bei meine TSUN-DTU sehe ich im Sekundentakt abfragen, vielleicht 
kollidiert es da, HM und TSUN sind ja quasi identisch.

Kannst du einfach mal deine DTU für ein paar Minuten trennen und 
schauen, ob es dann geht?

[Denny S. (nightstorm99)]

Hallo,

ja wenn der DTU aus ist, gehen keine Daten verloren.
Ist der DTU an, sieht man gut das nur der HM1500 hin und wieder keine 
Daten erhält (hängt am DTU), aber der HM800 (nur über AHOY) immer alles 
korrekt ist.

Das mit der DTU Seriennummer ändern im AHOY habe ich auch probiert, aber 
dann geht nix mehr.

Vielleicht geht das mit der DTU-Pro dann besser.

[IsnoAhoy (Gast)]

Thomas B. schrieb:
>> könnte man auch Deinen OpenDTU Code für den ESP8266 übersetzen ?
> ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist so out 
of the Box wohl nicht möglich, da ich diverse Compiler und Linker Features 
verwende die im Toolkit vom 8266 nicht vorhanden sind.

Hallo Thomas, das habe ich gesehen vor allem das std::bind() für die 
Interrupt Handler will er bei mir partout nicht übersetzen. Ich habe es 
aber auch nicht hinbekommen die Interrupthandler außerhalb der 
Klassenbzu definieren. Das scheint dem ESP8266 Cross Compiler nicht zu 
gefallen. Das andere sind glaube ich div. Datentypen die beim ESP8266 
etwas anders sind. Soll ich Dir die bereits gemachten Anpassungen 
irgendwie per PR zukommen lassen ?

[IsnoAhoy (Gast)]

Hallo Denny S.,
ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR 
sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn 
Du das Abfrageintervall auf einen größeren Zeitraum stellst könnte es 
evtl klappen aber mE bringst Du damit die Payload Decodierung aus dem 
Tritt, weil er ja per Interrupt Pakete bekommt die er evtl grade gar 
nicht erwartet.
Im DTU Code von Hoymiles sind zwar einige Bedingungen für falsche Pakete 
(out-of-order) definiert die dann ggf. einen Abbruch der Verbindung und 
ein sog. NET_INIT (ich glaube unser Zeit senden Paket) auslösen. Aber 
auch im Ahoy-ESP8266 code schon alle Eventualitäten berücksichtigt sind 
wage ich zu bezweifeln.
Der Hoymiles Code wartet auch max 300-500ms auf eine Antwort, da gibt es 
eine ausführliche Methode die für jede Anfrage die sog LOCAL_TIME 
berechnet bevor die Anfrage bzw Antwort verworfen wird und eine neue 
Anfrage gestellt wird.

Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum 
Ahoy-ESP zu betreiben ?
Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst 
?

[IsnoAhoy (Gast)]

@Lukas evtl könnten wir ein sog Promiscuous Feature in die AHOY-ESP 
Software einbauen, bei dem er selbst keine Anfragen sendet aber 
ankommende Payloads versucht zu dekodieren ? Wäre ein Flag in den 
Settings je WR und er müsste halt sehen ob er irgendwann das erste 
Antwort-Paket und alle folgenden mitbekommt. Wenn es nicht klappt kann 
er die Payload ja auch wieder verwerfen, da er ja kein Retransmit senden 
kann/soll.

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:
> ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR
> sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn

Auf der smiles-cloud kann man einen WR nur 1x registireren, DTU-lite 
oder DTU-Pro

> Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum
> Ahoy-ESP zu betreiben ?
> Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst
> ?
DTU-Lite kann nur 4 Module haendeln, ich denke er möchte mehr sehen...

[Stefan T. (isnoahoy)]

Hallo @All,
Lukas und ich diskutieren gerade in 
https://github.com/grindylow/ahoy/issues/36 und #83 ob wir einen ESP8266 
mit 4MB Flash vorraussetzen können und sollen. Die HTML-Seiten und 
Konfiguration scheint langsam den Flash zu füllen und die Wemos D1 mini 
***LITE v1*** mit nur 1MB und einem ESP-07 würde damit als 
***unsupported*** rausfallen. Wieviele von Euch nutzen den ESP-07 bzw. 
einen Wemos D1 mini in der ***LITE v1*** mit nur einem 1MB Flash ?
Bitte im o.g. Github issue #36 und/oder #83 melden, damit wir die 
Auswirkung dieser Änderung abschätzen können. Danke!

[Stefan T. (isnoahoy)]

@Ziyat T.,
danke für den Hinweis es scheint sich in #91 heraus zu kristallisieren, 
daß wir alle Antwort-Pakete ( egal für welche DTU ) die wir empfangen 
auch versuchen in die Payloadstruktur zu integrieren. Wir sollten hier 
also einen Plausibilitätscheck der DTU Addresse einbauen, außer wir sind 
im o.g. Promiscuous Mode. Sonst kommen wir mit den Antworten für die 
echte DTU und denen auf unsere Anfragen durcheinander.

Siehe https://github.com/grindylow/ahoy/issues/91

@Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und 
eine original DTU (Lite/Pro) verwenden willst ?
Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ?

[Marcel A. (a-marcel)]

> @Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und
> eine original DTU (Lite/Pro) verwenden willst ?
> Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ?

Limitieren eines HoyMiles geht noch immer nicht :(

[Denny S. (nightstorm99)]

Moin Zusammen,

IsnoAhoy schrieb:
> Hallo Denny S.,
> ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR
> Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum
> Ahoy-ESP zu betreiben ?

Eigentlich erstmal nur Testweise. Ich möchte alle Werte aus der Anlage 
gerne in ioBroker haben. Das geht mit dem DTU-Lite leider überhaupt 
nicht, deshalb hatte ich mir einen DTU-Pro + Energiemesser bestellt 
(kommt aber erst Ende Juli).
Dann bin ich auf dieses Projekt gestoßen. Ohne DTU-Lite am Netz könnte 
ich eigentlich auf AHOY umstellen, aber dann geht mir aktuell die 
Aufbereitung der Daten in der Hoymiles Cloud flöten.

> Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst
> ?
Also wenn ich schon so gefragt werde :-)
Was haltet ihr von einer Berechnung der Gesamtwerte der Anlage, also 
wenn mehrere WR eingebunden sind und die Daten ebenfalls gleich über 
MQTT raus schicken?

Weitere Punkte fallen mir bestimmt noch ein. :-)

Gruß

[Marcel A. (a-marcel)]

Dieser Thread ist ja damit gestartet das man versucht die Daten von 
Hoymiles auszulesen. Das ist ja eigentlich geschafft und dieser Thread 
wird ja mehr und mehr zum Support Thread mit sehr vielen gleichen Fragen 
und langer ladezeit.

Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten 
gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll 
diskussion entstehen?

Ich habe leider keine DTU und kann somit auch keine Daten sniffen. Ich 
kann aber programmieren und kann helfen Sachen zu testen.

Wie man ja oben schon sieht, ich bin wirklich an der Limitierung 
interessiert.

Danke
Marcel

[Daniel R. (daniel92)]

Hi Marcel,

geht uns doch allen so. :) - Discord Link weiter oben.

Ich probiere viel alleine aus. Aber neue Erkentniss habe ich nicht.
Eine DTU-pro wäre hier Hilfreich.

Gruß Daniel

[Herbert K. (avr-herbi)]

Marcel A. schrieb:
> Dieser Thread ist ja damit gestartet das man versucht die Daten von
> Hoymiles auszulesen. Das ist ja eigentlich geschafft

Ist meines Erachtens noch nicht geschafft bzw. nur zum Teil.
Wir bekommen zwar die "Guten Daten" aber nicht die Bösen, sofern ich nix 
übersehen habe. Es ist noch gar nix in Richtung Fehler Abfrage 
erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source 
eine Fehlerliste entdeckt.

> Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten
> gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll
> diskussion entstehen?

Ich bin sehr dafür. Darum hatte ich ja auch schon für HMT, HMS, 
DTU-Pro-S extra Threads angelegt in der Hoffnung, das sich da auch mal 
irgendwann jemand einfindet und nicht diesen hier wiederholt kapert. Mit 
Discord kann ich nix anfangen. Sagt mir nix. Wenn, dann Bitte hier. Nur 
mir fällt kein Name ein.

Vielleicht so?

Protokoll Analyse Hoymiles HM-xxxx, MI-xxxx Bits und Bytes

Und als 1. Beitrag so was in der Art wie ich bei HMT geschrieben habe 
evt.

Sinngemäß:

Kein Support für Entwicklungsumgebungen (kann Source nicht übersetzen 
usw.)
Kein Support zum Flashen der Mikrokontroller
Kein Support für MQTT Probleme usw.

Dazu bitte den alten Beitrag benutzen:
Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Hier soll nur über die Analyse der Bits und Bytes diskutiert werden

[isnoAhoy (Gast)]

Hallo Marcel A. & Herbert K.,
>> Dieser Thread ist ja damit gestartet das man versucht die Daten von
>> Hoymiles auszulesen. Das ist ja eigentlich geschafft
> Es ist noch gar nix in Richtung Fehler Abfrage
erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source
eine Fehlerliste entdeckt.

Ich finde den Punkt gut hier im ESP evtl. auch die Fehlerliste 
abzufragen. Das wäre dann eine neue sendEventLog Routine und dann der 
entsprechende Payload Decoder.

Daniel R., hatte ja schon versucht aufgrund der Hoymiles Code Analyse 
einige Power Limit Kommandos o.a. an seinen Wechselrichter zu schicken. 
Ich habe bei mir irgendwo die vier NRF24 Module verlegt und somit nur 
eines am ESP welches ich aber nicht so flexibel einsetzen kann wie das 
mit dem Raspberry Pi code von Jan-Jonas geht.

Ich hatte m.W. auch schon weiter oben die verschiedenen SubCmds und 
Events aus dem Hoymiles DTU-Pro code (iotloves) extrahiert:

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

The current implementation we use for HM-inverters seems to be in the
Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or
`usart_nrf3.h`.
There also the user data starts with `0x80` in `byte[10]` and
after that the Sub Command mentioned in the Excel sheet.

According to the implementation in `usart_nrf3.h` the Sub Command is
defined as `DataType` in `usart_nrf3.h`:

typedef enum
{
    InverterDevInform_Simple = 0, // 0x00
    InverterDevInform_All = 1, // 0x01
    GridOnProFilePara = 2, // 0x02
    HardWareConfig = 3, // 0x03
    SimpleCalibrationPara = 4, // 0x04
    SystemConfigPara = 5, // 0x05
    RealTimeRunData_Debug = 11, // 0x0B
    RealTimeRunData_Reality = 12, // 0x0C
    RealTimeRunData_A_Phase = 13, // 0x0D
    RealTimeRunData_B_Phase = 14, // 0x0E
    RealTimeRunData_C_Phase = 15, // 0x0F
    //RealTimeRunData_Password = 16, // 0x10
    AlarmData = 17, // 0x11
    RecordData = 18, // 0x12
    InternalData = 19, // 0x13
    ExternalData = 20, // 0x14
} DataType;

Especially the 0x0B rings a bell with me and the traces so far!

According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:

#define DEVCONTROL_ALL         0x51
#define ANSWER_DEVCONTROL_ALL     (DEVCONTROL_ALL|0X80)

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

The main routine is in `UsartNrf3_Send_NetCmdToNrfCmd` where all the
commands and subcommands are defined, where the Sub Commands are of 
`DevControlType`:

typedef enum
{
    Type_TurnOn = 0, // 0x00
    Type_TurnOff = 1, // 0x01
    Type_Restart = 2, // 0x02
    Type_Lock = 3, // 0x03
    Type_Unlock = 4, // 0x04
    Type_ActivePowerContr = 11, // 0x0B
    Type_ReactivePowerContr = 12, // 0x0C
    Type_PFSet = 13, // 0x0D
    Type_CleanState_LockAndAlarm = 20, // 0x14
    Type_Init = 0xff, // 0xFF
} DevControlType;

The AlarmDataType can store up to 20 Alerts as far as I could tell from
the `UsartNrf3_Process_DevInform_Alarm` method.

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX
Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und
erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL
(REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden
SubCmd's definiert als:

typedef enum
{
    InverterDevInform_Simple = 0,
    InverterDevInform_All = 1,
    GridOnProFilePara = 2,
    HardWareConfig = 3,
    SimpleCalibrationPara = 4,
    SystemConfigPara = 5,
    RealTimeRunData_Debug = 11, // 0x0B
    RealTimeRunData_Reality = 12, // 0x0C
    RealTimeRunData_A_Phase = 13, // 0x0D
    RealTimeRunData_B_Phase = 14, // 0x0E
    RealTimeRunData_C_Phase = 15, // 0x0F //�澯����-����δ���͸澯
    AlarmData = 17,  // 0x11 //�澯����-ȫ������澯
    AlarmUpdate = 18, // 0x12
    RecordData = 19, // 0x13
    InternalData = 20, // 0x14
    GetLossRate = 21, // 0x15
    //dong 2020-06-15
    GetSelfCheckState = 30, // 0x1E
    InitDataState = 0xff,
} DataType;

Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum
Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S.
hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw
AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem
Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter
hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert
hatten.

Interessant ist hier vor allem auch der InitDataState 0xff den der 
Hoymiles immer wieder sendet um den Wechselrichter in einen definierten 
Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort 
ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.

@Daniel R.,
Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit 
Funktion zu nutzen ?

[isnoAhoy (Gast)]

Ach ja, wir haben auch schon seit längerem zwei Feature Requests im 
Github, wenn ihr das lieber nehmen wollt um spezifische 
Protokoll-Kommandos im Detail zu besprechen:

Das hier ist m.E. für die Alarm Data / Update Daten:

Use the 0x15 or 0x09 command to query the inverters internal history
#77
https://github.com/grindylow/ahoy/issues/77

und das hier sollte das Power Limit behandeln:

Feature Erweiterung: Leistungslimitierung (für z.B. geregelter 
Batteriewechselrichter oder um gesetzliche Grenzen einzuhalten)
#31
https://github.com/grindylow/ahoy/issues/31

[Günter H. (gnter_h534)]

Herbert K. schrieb:
> Hier soll nur über die Analyse der Bits und Bytes diskutiert werden

Aus meiner Sicht sollten wir es lassen wie es ist:
1. Auch Fragen außerhalb von Bits und Bytes bringen das Projekt 
insgesamt weiter,
2. gelingt eine solche "Sortierung" überhaupt (in den neu angelegten 
Threads ist bisher kein weiterer Eintrag),
3. die angesprochenen langen Ladezeiten sind bei Auswahl der 
Seitentrennung kein Thema.

[Daniel R. (daniel92)]

isnoAhoy schrieb:
> Interessant ist hier vor allem auch der InitDataState 0xff den der
> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
>
> @Daniel R.,
> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
> Funktion zu nutzen ?

Ui, darauf habe ich gar nicht geachtet! Guter Punkt.
Lass mich das später nochmal anschauen, gibt es die Möglichkeit dich 
außerhalb von µC zu Kontaktieren?

[isnoAhoy (Gast)]

Hallo Daniel R.,
Dein Discord Invite ist expired. Kannst Du nochmal einen schicken ?

[Ziyat T. (toe_c)]

Hallo

Wollte mal fragen, ob jemand auch den MI integriert oder überhaupt 
integrieren wird?

[Daniel R. (daniel92)]

Ich befürworte es, das man versucht alle Versionen zu integrieren. :)

[Daniel R. (daniel92)]

isnoAhoy schrieb:
> Dein Discord Invite ist expired. Kannst Du nochmal einen schicken ?

https://discord.gg/WzhxEY62mB bitte schön. :)

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ich befürworte es, das man versucht alle Versionen zu integrieren. :)

Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben, 
oder hab ich schon?

[Ziyat T. (toe_c)]

isnoAhoy schrieb:

> Interessant ist hier vor allem auch der InitDataState 0xff den der
> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
>
> @Daniel R.,
> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
> Funktion zu nutzen ?

Habe heute nochmals lange nach gesnifft, meine DTU-Pro sendet definitiv 
keine InitDataState 0xff zum MI.

wenn
#define DEVCONTROL_ALL 0x51
für alle gilt müsste ja auch für HM gehen, hmmm??

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben,
> oder hab ich schon?

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" ist es das 
hier?
Hast du auch Github, dann könntest du es vorerst dort pflegen.

Vielleicht kann man später das ganze mergen. Bin aktuell heiß auf die HM 
Limitierung. :)

[Martin M. (mquadrat)]

Moin,

gibt es eine Quelle wo man die Binarys der aktuellen Version downloaden 
kann?

[Lukas P. (lumapu)]

schaue ein paar Beiträge zurück, da hab ich geschrieben wo in Github 
diese zu finden sind.

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Daniel R. schrieb:
>> Ich befürworte es, das man versucht alle Versionen zu integrieren. :)
>
> Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben,
> oder hab ich schon?

Wo liegt deine Version? Wenn es nicht allzu viel Aufwand ist und jemand 
sich zum Testen bereit erklärt würde ich es mir anschauen, habe selbst 
keinen MI.

[Martin M. (mquadrat)]

Lukas P. schrieb:
> schaue ein paar Beiträge zurück, da hab ich geschrieben wo in Github
> diese zu finden sind.

Ok, das habe ich gelesen. Der Trick war nur, dass man auf Github 
eingeloggt sein muss um den Downloadlink zu sehen.

Danke!

[Ziyat T. (toe_c)]

Lukas P. schrieb:
Daniel R. schrieb:

> Wo liegt deine Version? Wenn es nicht allzu viel Aufwand ist und jemand
> sich zum Testen bereit erklärt würde ich es mir anschauen, habe selbst
> keinen MI.

Die Quick&Dirty für MI-1500, erwartet bitte keine Qualitaet, auf der 
Basis v. Hubi!

Laeuft auf ESP8266 und ArduiniUNO(ohne WiFi)

Im settings.h ist alles einzustellen
- Laeuft als Sniffer, wenns definiert (adr 0x00aa, 0x0055, hört alles 
mit).
- Channel hopping auch beim RX
- Mit/Ohne Interrupt,CRC zum Testen
- hat MQTT (auf meine Art) wenn Wifi, bekommt SmartMeterPower über MQTT
- kann über Serielle-SS gesteuert werden:
  * Befehl 1-1000: Leistungs Limitierung in Watt/ 0:stop limiting
  * Befehl 2000: serial help
  * Befehl 2001: WR-Info
  * BEfehl 2002-2004 : set PA_LEVEL

Kann eure SW testen wenn sie auf esp8266 laeuft.

[Stefan T. (isnoahoy)]

Ziyat T. schrieb:
> isnoAhoy schrieb:
>
>> Interessant ist hier vor allem auch der InitDataState 0xff den der
>> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
>> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
>> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
>>
>> @Daniel R.,
>> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
>> Funktion zu nutzen ?
>
> Habe heute nochmals lange nach gesnifft, meine DTU-Pro sendet definitiv
> keine InitDataState 0xff zum MI.
>
> wenn
> #define DEVCONTROL_ALL 0x51
> für alle gilt müsste ja auch für HM gehen, hmmm??

Hallo Ziyat T.,

ja Du hast Recht.

Das CurRecSendPackageDataType = InitDataState setzt er nur in zwei 
anderen Fällen und einmal initial.

Das mit dem SubCmd = Type_Init (0xff) scheint nur bei
* MainCmd = DOWN_PRO (0x0e)
oder
* MainCmd = DOWN_DAT (0x0a)
verwendet zu werden.

Bei allen anderen Anfragen erfolgt vorher ein CurNetCmd = NET_INIT, also
* MainCmd = REQ_ARW_DAT_ALL (0x15) und
* SubCmd = RealTimeRunData_Reality (0x0c) bzw.
* SubCmd = RealTimeRunData_Debug (0x0b).

Wir verwenden ja schon länger den zweiten Fall 0x0b für die Status 
Meldungen.

[Tobias (Gast)]

Hallo und vielen Dank für die super Arbeit!
Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600 
nichts empfangen kann? Irgend ein Depp hat nämlich alles montiert und 
vorher kein Foto vom Wechselrichter gemacht bzw. das Etikett 
abgezogen......

[Herbert K. (avr-herbi)]

Tobias schrieb:
> Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600
> nichts empfangen kann?

So sieht es aus !  Vielleicht hast Du Glück und es hat die S/N jemand 
eingescannt und sie steht auf Rechnung / Lieferschein.

[Friedhelm E. (fritsche)]

Hallo Hubi,
habe mit Zufriedenheit die SW-Varianten vom 13.04.22 und 5.06.22 an 
einem HM800 erprobt.
Finde die SW-Lösung vom 13.04.22 wegen der expliziten Darstellung der 
Werte übersichtlicher als die vom 5.06.22.
Habe heute beim Übernehmen der Daten für die E-Woche festgestellt, das 
auf Grund der 4 Bytes nur maximal 65535 W angegeben werden können.
Bei der Aufsummierung der Werte > 65535 springt der Zähler wieder auf 0 
und beginnt von neuem. Frage : Ist irgend eine der 4Byte in der Abfrage 
ein Zähler für die Summierung der Überläufe?

weiterhin gutes Gelingen.
Fritsche

[Tobias (Gast)]

Auf der Rechnung/Lieferschein finde ich leider keine Seriennummer :-(
Na dann, Dummheit muss bestraft werden, also wieder rauf auf's 
Garagendach ;-)

Herbert K. schrieb:
> Tobias schrieb:
>> Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600
>> nichts empfangen kann?
>
> So sieht es aus !  Vielleicht hast Du Glück und es hat die S/N jemand
> eingescannt und sie steht auf Rechnung / Lieferschein.

[Daniel R. (daniel92)]

@Tobias, laut Hersteller soll es eine Scan Funktion geben.
Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann 
kein Problem mehr sein. :)

[Tobias (Gast)]

Daniel R. schrieb:
> @Tobias, laut Hersteller soll es eine Scan Funktion geben.
> Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann
> kein Problem mehr sein. :)

DAS wäre natürlich was. Ich kapiere das mit den shockburst vom nrf zwar 
nicht, aber ich könnte mir als Laie schon vorstellen, dass der 
Wechselrichter seine Seriennummer irgendwie "broadcasted". Bei den 
nrf-Sniffern die ich hier verlinkt fand, war allerdings die Eingabe der 
Seriennummer Voraussetzung.

[Daniel R. (daniel92)]

Das ist richtig, da wir Thema Scan noch nicht implemtiert haben/können.

Ich bin gerade die Alarme auszulesen und konnte schonmal Erfolg 
verbuchen! :)

Habe mit isnoahoy folgende Beiträge durchgesichtet und diese auch 
probiert:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Und tatsächlich  konnte ich Payloads erhalten. Es gibt nur ein Problem:
Wenn ich auf Kanal 3 oder 75 sende, bekomme ich bessere Ergebnise.
Bei zuvielen Retransmits, bricht der skript ab und fängt von neu an...

Hier jetzt mal mein Ergebnis (noch nicht analysiert!):

Poll inverter 116174403329
Transmit 27 | 15 74 40 33 29 78 56 34 12 80 11 00 62 7b 69 fe 00 00 00 00 00 00 00 00 47 d7 bc
Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 01 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 c4
Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 02 00 04 62 2e 00 00 00 00 00 00 00 d2 00 05 62 2e 44
Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 03 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 66
Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 04 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 22
Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 05 00 0d 62 2e 69 fd 00 00 00 00 80 02 00 22 6c a4 2d
Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 06 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff ff
Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 07 ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 f0
Error while retrieving data: Missing packet: Last packet 7

Transmit 11 | 15 74 40 33 29 78 56 34 12 88 bb
Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 08 00 25 6c f1 6c f1 ff ff ff fb 80 02 00 26 6c fb 8f
Error while retrieving data: Missing packet: Last packet 8

Transmit 11 | 15 74 40 33 29 78 56 34 12 89 ba
Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 09 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff a7

Error while retrieving data: Missing packet: Last packet 9
Transmit 11 | 15 74 40 33 29 78 56 34 12 8a b9
Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 0a ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 a2
Error while retrieving data: Missing packet: Last packet 10

Transmit 11 | 15 74 40 33 29 78 56 34 12 8b b8
Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 0b 00 29 6d 27 6d 27 ff ff ff fb 80 02 00 2a 6d 32 44
Error while retrieving data: Missing packet: Last packet 11

Transmit 11 | 15 74 40 33 29 78 56 34 12 8c bf
Received 19 bytes channel 23: 95 74 40 33 29 74 40 33 29 8c 6d 32 ff ff ff f5 53 03 1c

Payload: 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 00 04 62 2e 00 00 00 00 00 00 00 d2 00 05 62 2e 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 00 0d 62 2e 69 fd 00 00 00 00 80 02 00 22 6c a4 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 00 25 6c f1 6c f1 ff ff ff fb 80 02 00 26 6c fb 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 00 29 6d 27 6d 27 ff ff ff fb 80 02 00 2a 6d 32 6d 32 ff ff ff f5 53 03
 payload has valid modbus crc

[Hubi (Gast)]

@friedhelm E.
hol dir die neuste Version von git-hub hm-soft/hoydtusim. Das sollte 
klappen.

[Daniel R. (daniel92)]

Das einzige was bei mir nicht passt:
Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

payload has valid modbus crc
80 01 00 01 62 26 62 26 00 00 00 00:
 uptime=6:58:46 a_count=1 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 1, 25126, 25126, 0, 0)
00 d1 00 04 62 2e 00 00 00 00 00 00:
 uptime=6:58:54 a_count=4 opcode=0 a_code=209 a_text=Port 1 no input
 BBHHHHH: (0, 209, 4, 25134, 0, 0, 0)
00 d2 00 05 62 2e 00 00 00 00 00 00:
 uptime=6:58:54 a_count=5 opcode=0 a_code=210 a_text=Port 2 no input
 BBHHHHH: (0, 210, 5, 25134, 0, 0, 0)
00 cf 00 06 63 5a 00 00 00 00 00 dc:
 uptime=7:03:54 a_count=6 opcode=0 a_code=207 a_text=Input port 1 & 2 undervoltage
 BBHHHHH: (0, 207, 6, 25434, 0, 0, 220)
40 8f 00 0c 62 2e 69 fd 00 03 07 a3:
 uptime=6:58:54 a_count=12 opcode=64 a_code=143 a_text=Grid undervoltage
 BBHHHHH: (64, 143, 12, 25134, 27133, 3, 1955)
40 93 00 0d 62 2e 69 fd 00 00 00 00:
 uptime=6:58:54 a_count=13 opcode=64 a_code=147 a_text=Power grid outage
 BBHHHHH: (64, 147, 13, 25134, 27133, 0, 0)
80 02 00 22 6c a4 6c a4 ff ff ff fa:
 uptime=7:43:32 a_count=34 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 34, 27812, 27812, 65535, 65530)
80 02 00 23 6c ab 6c ab ff ff ff f9:
 uptime=7:43:39 a_count=35 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 35, 27819, 27819, 65535, 65529)
80 02 00 24 6c ec 6c ec ff ff ff bf:
 uptime=7:44:44 a_count=36 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 36, 27884, 27884, 65535, 65471)
80 02 00 25 6c f1 6c f1 ff ff ff fb:
 uptime=7:44:49 a_count=37 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 37, 27889, 27889, 65535, 65531)
80 02 00 26 6c fb 6c fb ff ff ff f6:
 uptime=7:44:59 a_count=38 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 38, 27899, 27899, 65535, 65526)
80 02 00 27 6d 18 6d 18 ff ff ff e3:
 uptime=7:45:28 a_count=39 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 39, 27928, 27928, 65535, 65507)
80 02 00 28 6d 22 6d 22 ff ff ff f6:
 uptime=7:45:38 a_count=40 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 40, 27938, 27938, 65535, 65526)
80 02 00 29 6d 27 6d 27 ff ff ff fb:
 uptime=7:45:43 a_count=41 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 41, 27943, 27943, 65535, 65531)
80 02 00 2a 6d 32 6d 32 ff ff ff f5:
 uptime=7:45:54 a_count=42 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 42, 27954, 27954, 65535, 65525)

[Ziyat T. (toe_c)]

Tobias schrieb:
> Daniel R. schrieb:
> Wechselrichter seine Seriennummer irgendwie "broadcasted".

Also mein bisheriges Sniffen zwischen DTU-Pro und MI-1500: hab noch nie 
ein braodcast vom MI gesehen, auch wenn die DTU ausgeschaltet war.
An welche Adresse soll broadcastet werden?

Der WR ist ohne eine Abfrage quasi tot, zumindestens der MI-1500

(mein Sniffer hört auf "alles" wechselweise auf mehreren kanaelen)

[Daniel R. (daniel92)]

@Ziyat T. Ich habe bisher nur im Manual gelesen das man via Webinterface 
in der DTU das Umfeld Scannen kann.  Damit man weitere Wechselrichter 
finden kann.

Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Das einzige was bei mir nicht passt:
> Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
>
Die v. Jonas erwaenhte Quelle ist für die HMS Serie !

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> @Ziyat T. Ich habe bisher nur im Manual gelesen das man via Webinterface
> in der DTU das Umfeld Scannen kann.  Damit man weitere Wechselrichter
> finden kann.
>
> Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Das ist soweit korrekt, nur auf dem Android-Phone per Installer-APP.
Die APP fragt einfach mal alle WR Modelle ab, also es ist nicht 
richtiges broadcasting, der WR macht also nichts

[Daniel R. (daniel92)]

In der Excel steht folgendes, kannst du das mal probieren für MI?
Siehe Anhang.

Target würde ich mal als DTU sehen, oder?

Gongfa steht für:
to attack
to raid

[Ziyat T. (toe_c)]

Tobias schrieb:
> Bei den
> nrf-Sniffern die ich hier verlinkt fand, war allerdings die Eingabe der
> Seriennummer Voraussetzung.

Wenn du auf esp8266 bist kannst du die nehmen als Sniffer, braucht keine 
WR/DTU Adresse:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
im settings.h "sniffer" einstellen

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> In der Excel steht folgendes, kannst du das mal probieren für MI?
> Siehe Anhang.
>
> Target würde ich mal als DTU sehen, oder?
>
> Gongfa steht für:
> to attack
> to raid

Ich werde mir das Ding nochmals anschauen

Edit: habe vorher eine falsche Antwort geschrieben, ich habe die 0xf 
implementiert

[isnoAhoy (Gast)]

Daniel R. schrieb:
> @Tobias, laut Hersteller soll es eine Scan Funktion geben.
> Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann
> kein Problem mehr sein. :)

Anbei die ins Englische übersetzten Versionen der usart_nrf.c/.h und 
usart_nrf3.c/.h aus dem iotloves Gitee repo. Endlich hab ich mal die 
Zeit gefunden das mal für mich abzuschließen. Ähnlich interessant sind 
m.E. noch die AntiReflux.c/.h und DRM.c/.h Dateien.

Für das G{o,ua}ngfa / Such-Kommando wird folgendes gesetzt:

void UsartNrf_Send_NetCmdToNrfCmd(void)
...
case NET_SEARCH_ID: //Search ID
                MainCmd = BROADCAST; // 0x02
                SubCmd = 0; // 0x00
                break;

void UsartNrf_Send_PackNrfCmd(void)
...
        case NET_SEARCH_ID://Search Id (Guangfa command)
            {
                if(UsartNrf_HasSetCurrentInverterOk())
                {
                    for(j  = Dtu3Detail.Property.PortNum; j < PORT_LEN; j++)
                    {
                        memset((u8 *)MIMajor[j].Property.Pre_Id, 0, 2);
                        memset((u8 *)MIMajor[j].Property.Id, 0, 4);
                        MIMajor[j].Property.Port = MI_NO;
                    }

                    Uart_SendBufferLen  = UsartNrf_Send_PackBaseCommand((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, MainCmd, 0);
                }

                break;
            }

u8 UsartNrf_Send_PackBaseCommand(u8 *target_adr, u8 *rout_adr, u8 cmd, u8 dat)
{
    vu8 i = 0;
    vu8 temp_dat[UART_LEN];
    memset((u8 *)temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//start // 0x7e
    temp_dat[0] = cmd;   //command // MainCmd
    memcpy((u8 *)&temp_dat[1], target_adr, 4);
    memcpy((u8 *)&temp_dat[5], rout_adr, 4);
    temp_dat[9] = dat;
    temp_dat[10] = Get_crc_xor((u8 *)&temp_dat[0], 10); //CRC
    i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 11); //Forward Substitution
    Uart_SendBuffer[(i + 1)] = ETX; //end
    memset((u8 *)temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

Es sollte also mit z.B. als Search Paket gehen:
02  74 40 33 29  78 56 34 12  00  CRC8

[isnoAhoy (Gast)]

Daniel R. schrieb:

> 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 00 04 62 2e 00 00 00 00 
> 00 00 00 d2 00 05 62 2e 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 
> 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 00 0d 62 2e 69 fd 00 00 
> 00 00 80 02 00 22 6c a4 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff 
> ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 00 25 6c f1 6c f1 ff ff 
> ff fb 80 02 00 26 6c fb 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff 
> ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 00 29 6d 27 6d 27 ff ff 
> ff fb 80 02 00 2a 6d 32 6d 32 ff ff ff f5 53 03

Die Routine um die o.a. Alarm Payload zu dekodieren findet sich in 
UsartNrf3_Process_DevInform_Alarm().
Es wird immer in 12 byte zusammengefaßt, wobei die ersten beiden die 
Alarm Version number darstellen:

00 01 <-- Alarm Version number
80 01 00 01 62 26 62 26 00 00 00 00 
00 d1 00 04 62 2e 00 00 00 00 00 00
00 d2 00 05 62 2e 00 00 00 00 00 00
00 cf 00 06 63 5a 00 00 00 00 00 dc
40 8f 00 0c 62 2e 69 fd 00 03 07 a3
40 93 00 0d 62 2e 69 fd 00 00 00 00
80 02 00 22 6c a4 6c a4 ff ff ff fa
80 02 00 23 6c ab 6c ab ff ff ff f9
80 02 00 24 6c ec 6c ec ff ff ff bf
80 02 00 25 6c f1 6c f1 ff ff ff fb
80 02 00 26 6c fb 6c fb ff ff ff f6
80 02 00 27 6d 18 6d 18 ff ff ff e3
80 02 00 28 6d 22 6d 22 ff ff ff f6
80 02 00 29 6d 27 6d 27 ff ff ff fb
80 02 00 2a 6d 32 6d 32 ff ff ff f5
|...| |...| |...| |...| |...| |...|
+2 +3 +4 +5 +6 +7 +8 +9 +10.. +12..
<WCode>     |     |     |     |
      <WNum>|     |     |     |
      <WarnSerNub>|     |     |
            <AlarmStartTime>  |
                  <AlarmEndTime> 
                        <AlarmData1> 
                              <AlarmData2>

Hier die Dekodierung der o.a. Felder:

AlarmId:    Alarm_Id[0]), (u8 *)MIMajor[PortNO].Property.Pre_Id, 2);
            Alarm_Id[2]), (u8 *)MIMajor[PortNO].Property.Id, 4);

WCode:      WCode = (u16)pProBuffer[i * 12 + 2] << 8 | pProBuffer[i * 12 + 3];
WNum:       WNum), &(pProBuffer[i * 12 + 4]), 2);
WarnSerNub: WarnSerNub[PortNO] = (u16)pProBuffer[i * 12 + 4] << 8 | (u16)pProBuffer[i * 12 + 5];
WTime1=AlarmStartTime: //Alarm start time
                       AlarmTime = (u32)((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7]) + DateToSec(calendar); // AM
                       AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7])) + DateToSec(calendar); // PM WCode >> 13) & 0x01) == 1)
WTime2=AlarmEndTime  : //Alarm end time
                       AlarmTime = (u32)((u16)pProBuffer[i * 12 + 8] << 8) | ((u16)pProBuffer[i * 12 + 9]) + DateToSec(calendar); // AM
                       AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 8] << 8) | ((u16)pProBuffer[i * 12 + 9])) + DateToSec(calendar); // PM WCode >> 12) & 0x01) == 1)
AlarmData1: Data1[0]), &(pProBuffer[i * 12 + 10]), 2);
AlarmData2: Data2[0]), &(pProBuffer[i * 12 + 12]), 2);

Es wird offenbar immer das aktuelle Datum des Tages in Sekunden dazu 
gezählt und anhand des Bit 13 / 12 im WCode entschieden ob der 
AlarmStartTime / AlarmEndTime vormittags oder nachmittags liegt/lag.

Aus Bit 14 & 15 des WCode wird noch ein sog. Run_Status[0] und [1] 
extrahiert.
Was auch immer das aussagt?

WCode >> 14) & 0x03)) == 0)
  Run_Status[0] = 0x00;
  Run_Status[1] = 0x08;

WCode >> 14) & 0x03) == 1)
  Run_Status[0] = 0x00;
  Run_Status[1] = 0x03;

@Jan-Jonas S., kannst Du die Punkte mal mit Deinen bisherigen Annahmen 
(a_code, etc.) überprüfen.

[Daniel R. (daniel92)]

Morgen zusammen,

@Jan-Jonas S.: Also den Python Code müssten man irgendwann mal 
optimieren. :D
ABER: Es läuft schonmal zwecks Logs auswertung ziemlich gut!

2022-07-14 20:08:34.249099 Payload: 00 01 80 01 00 01 4d 02 4d 02 00 00 00 00 00 d1 00 04 4d 0a 00 00 00 00 00 00 00 d2 00 05 4d 0a 00 00 00 00 00 00 00 cf 00 06 4e 36 00 00 00 00 00 dc 40 8f 00 0c 4d 0a 54 d9 00 03 07 a3 40 93 00 0d 4d 0a 54 d9 00 00 00 00 80 02 00 40 6c 85 6c 85 ff ff ff fb 80 02 00 41 6c 8b 6c 8b ff ff ff fa 80 24 00 42 6d 09 6d 09 09 06 eb ec 00 94 00 43 6d 0a 00 00 0f 06 00 00 80 02 00 44 6d 14 6d 14 ff ff ff 77 80 02 00 45 6d 3a 6d 3a ff ff ff da 80 02 00 46 6d 3f 6d 3f ff ff ff fb 80 02 00 47 6d 46 6d 46 ff ff ff f9 80 02 00 48 6d 50 6d 50 ff ff ff f6 06 28
 payload has valid modbus crc
80 01 00 01 4d 02 4d 02 00 00 00 00: 
 uptime=5:28:34 a_count=1 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 1, 19714, 19714, 0, 0)
00 d1 00 04 4d 0a 00 00 00 00 00 00: 
 uptime=5:28:42 a_count=4 opcode=0 a_code=209 a_text=Port 1 no input
 BBHHHHH: (0, 209, 4, 19722, 0, 0, 0)
00 d2 00 05 4d 0a 00 00 00 00 00 00: 
 uptime=5:28:42 a_count=5 opcode=0 a_code=210 a_text=Port 2 no input
 BBHHHHH: (0, 210, 5, 19722, 0, 0, 0)
00 cf 00 06 4e 36 00 00 00 00 00 dc: 
 uptime=5:33:42 a_count=6 opcode=0 a_code=207 a_text=Input port 1 & 2 undervoltage
 BBHHHHH: (0, 207, 6, 20022, 0, 0, 220)
40 8f 00 0c 4d 0a 54 d9 00 03 07 a3: 
 uptime=5:28:42 a_count=12 opcode=64 a_code=143 a_text=Grid undervoltage
 BBHHHHH: (64, 143, 12, 19722, 21721, 3, 1955)
40 93 00 0d 4d 0a 54 d9 00 00 00 00: 
 uptime=5:28:42 a_count=13 opcode=64 a_code=147 a_text=Power grid outage
 BBHHHHH: (64, 147, 13, 19722, 21721, 0, 0)
80 02 00 40 6c 85 6c 85 ff ff ff fb: 
 uptime=7:43:01 a_count=64 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 64, 27781, 27781, 65535, 65531)
80 02 00 41 6c 8b 6c 8b ff ff ff fa: 
 uptime=7:43:07 a_count=65 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 65, 27787, 27787, 65535, 65530)
80 24 00 42 6d 09 6d 09 09 06 eb ec: 
 uptime=7:45:13 a_count=66 opcode=128 a_code=36 a_text=N/A
 BBHHHHH: (128, 36, 66, 27913, 27913, 2310, 60396)
00 94 00 43 6d 0a 00 00 0f 06 00 00: 
 uptime=7:45:14 a_count=67 opcode=0 a_code=148 a_text=Grid disconnection
 BBHHHHH: (0, 148, 67, 27914, 0, 3846, 0)
80 02 00 44 6d 14 6d 14 ff ff ff 77: 
 uptime=7:45:24 a_count=68 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 68, 27924, 27924, 65535, 65399)
80 02 00 45 6d 3a 6d 3a ff ff ff da: 
 uptime=7:46:02 a_count=69 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 69, 27962, 27962, 65535, 65498)
80 02 00 46 6d 3f 6d 3f ff ff ff fb: 
 uptime=7:46:07 a_count=70 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 70, 27967, 27967, 65535, 65531)
80 02 00 47 6d 46 6d 46 ff ff ff f9: 
 uptime=7:46:14 a_count=71 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 71, 27974, 27974, 65535, 65529)
80 02 00 48 6d 50 6d 50 ff ff ff f6: 
 uptime=7:46:24 a_count=72 opcode=128 a_code=2 a_text=DTU command failed
 BBHHHHH: (128, 2, 72, 27984, 27984, 65535, 65526)

Meiner Meinung nach müsste man die Log auswertung etwas leserlicher 
gestalten.
Es soll sich so lesen als würde man einfach ein Log AUszug aus dem 
Webinterface geben. :)

Kann jemand mal ein Screenshoot aus einer echten DTU-Webinterface von 
der Log bereitstellen?

@Jan-Jonas S.: Was fehlt hier eigentlich noch, wo müsste man noch etwas 
analyzieren?

[Josef J. (jauntyjosef)]

Daniel R. schrieb:
> Kann jemand mal ein Screenshoot aus einer echten DTU-Webinterface von
> der Log bereitstellen?

Ich habe eine DTU Pro. Lokales Webinterface gibt es da keines und in der 
Cloud sehe ich bei meinem Installer Account keine Möglichkeit ein Log zu 
sehen.

[Daniel R. (daniel92)]

DTU-Pro hat kein Webinterface?
Das ist ja schwach. ^^

Ok aber an sich müsste das Log auslesen irgendwie gehen. Hmm..

[Stefan T. (isnoahoy)]

Hallo Jan-Jonas,

uptime ist tatsächlich ein Zeitstempel also WTime1 / AlarmStartTime, 
wobei das Bits 13 (Start) des long WCode (d.h. opcode<<8 | a_code) also 
Bit 5 des opcode bestimmt ob es AM = 0 / PM = 1 ist.

Der long Wert hinter uptime ist die WTime2 / AlarmEndTime, hier bestimmt 
Bit 12 (End) also Bit 4 des opcode ob es AM = 0 / PM = 1 ist.
Bit 15 und 14 bestimmen (also Bit 7 und 6 des opcode) wie der RunStatus 
des Wechselrichters ist (siehe oben).

Wir sollten also uptime in starttime umbenennen, die endtime hinzunehmen 
und die AM/PM Berechnung einbauen.

Den RunStatus habe ich noch nicht ganz durchschaut, der wird offenbar 
auch per ModBus486 und NetProtocol an den Server weitergegeben.

Was die WData1 und WData2 in den beiden longs ganz rechts sind, weiß ich 
auch nicht. Das hängt bestimmt von dem von Dir so genannten a_code ab.

BTW: die a_code's können übrigens noch bis zu 12 Bit groß sein. Aber ich 
denke die Übersetzungstabelle die Du eingebaut hast scheint ganz gut zu 
funktionieren und die höchsten vier Bit sind offenbar noch nicht 
vergeben worden.

[Thomas B. (tbnobody)]

isnoAhoy schrieb:
> und anhand des Bit 13 / 12 im WCode entschieden ob der
> AlarmStartTime / AlarmEndTime vormittags oder nachmittags liegt/lag.

Wo im Sourcecode siehst du das? Das war mir so anhand der 
UsartNrf3_Process_DevInform_Alarm Funktion nicht klar.

[Stefan T. (isnoahoy)]

Hallo Thomas B.,
Hier mal der erste Teil für die Alarm Start Time mit Bit 13 des WCode 
(erster long/double Wert einer 12 byte Zeile), der Block wiederholt sich 
für die Alarm End Time und Bit 12.

                //Pending alarm afternoon
                if(((pRealAlarm[RealAlarmDataNO].Data.WCode >> 13) & 0x01) == 1)
                {
                    AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7])) + DateToSec(calendar);
                }
                //Pending alarm morning
                else
                {
                    AlarmTime = (u32)((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7]) + DateToSec(calendar);
                }

                //Alarm start time
                pRealAlarm[RealAlarmDataNO].Data.WTime1[0] = AlarmTime >> 24;
                pRealAlarm[RealAlarmDataNO].Data.WTime1[1] = AlarmTime >> 16;
                pRealAlarm[RealAlarmDataNO].Data.WTime1[2] = AlarmTime >> 8;
                pRealAlarm[RealAlarmDataNO].Data.WTime1[3] = AlarmTime;

D.h. die ersten beiden Bits 15 & 14 des WCode bestimmen den RunStatus 
und die Bit 13 & 12 bestimmen AM/PM der AlarmStartTime / AlarmEndTime 
Angaben.

[Thomas B. (tbnobody)]

Hallo Stefan,

aus welchem Repo kommt das? Bei mir ist die Bedingung:

if((calendar.hour * 60 * 60 + calendar.min * 60 + calendar.sec) / (12 * 60 * 60) > 0)

statt

if(((pRealAlarm[RealAlarmDataNO].Data.WCode >> 13) & 0x01) == 1)

[Stefan T. (isnoahoy)]

@Thomas B.,
das ist aus dem iotloves bzw. dem m.W. identischen andycao1860 repos.
Im älteren michel_individual_organization war m.W. keine usart_nrf3.c 
Implementierung aber ich kann mich auch täuschen und die war einfach nur 
älter.
Ich habe mir deswegen den aktuelleren Code angesehen, da dort auch 
AntiReflux.c und andere schöne Funktionen implementiert sind.

Die usart_nrf[3].c/.h Dateien aus dem iotloves hatte ich gestern 
übersetzt und hier angehängt. Die aus dem michel_individual_organization 
schon vor einer ganzen Weile ebenfalls hier im Forum.

[Java L. (java_l)]

Hallo allerseits, ich bitte um Nachsicht wenn ich so reinplatze, ich 
habe diesen Thread zwar schon öfters durchkämmt, konnte aber mein 
Problem bzw. mein Anliegen nicht so richtig finden, deshalb meine Frage:
ich hab die wlan Datenpakete von einem Stick (DTU100W) mitgeschnitten 
und erhoffe mir darüber die mir wichtigen Informationen, wie Temperatur 
des Wechselrichters (HM-800) und die PV-Module-Power der einzelnen 
Panels, auszulesen. Ich bin mir ziemlich sicher, dass die Struktur der 
Datenpakete schon analysiert worden ist, doch wo könnte ich die finden?
Vielen Dank,
Hans
Ps: der screenshot zeigt eines der typischen Pakete, das sich pro Minute 
wiederholt. Es geht nicht um den Datenverkehr zwischen WR und irgend 
einen HW-Client, sondern  um den Datenverkehr zwischen DTU und Cloud, 
den ich abtrennen möchte.

[Herbert K. (avr-herbi)]

Java L. schrieb:
> Hallo allerseits, ich bitte um Nachsicht wenn ich so reinplatze, ich
> habe diesen Thread zwar schon öfters durchkämmt, konnte aber mein
...
Hier analysieren wir die Kommunikation zwischen DTU... und HM-xxxx, 
MI-xxxx.

Hier wird NICHT analysiert der Netzwerktraffic zwischen DTU und der 
S-Miles-Cloud. Bitte mach dafür einen neuen Thread auf falls Dich das 
Interessiert. Das ist eine ganz andere Baustelle. Danke.

[Josef J. (jauntyjosef)]

Daniel R. schrieb:
> DTU-Pro hat kein Webinterface?
> Das ist ja schwach. ^^
>
> Ok aber an sich müsste das Log auslesen irgendwie gehen. Hmm..

Wenn wer weiß wie, könnte ich dann, falls es hilft, dahingehend gerne 
was dazu beitragen

[A.D. (Gast)]

Hallo zusammen,

gibt es Wechselrichter bei denen es nicht funktioniert?
Hab hier ein HM-600 der irgendwie nicht will.
Bei meinem anderen (auch HM-600) funktioniert es ohne Probleme.

"Inverter 'TEST' is not available and is not producing"

kann evtl eine falsche Seriennummer auf dem WR sein? Kann man die 
irgendwie anders auslesen?

Danke schon mal.

[IsnoAhoy (Gast)]

Hallo Java L.
wie Herbert schon geschrieben hat geht es hier vorragig um die 
HM-Wechselrichter <-> DTU lite/Pro Kommunikation. Die Modbus485 und die 
NetProtocol Kommunination zwischen DTU und Hoymiles Cloud ist hier 
Off-Topic. Du kannst gerne einen Hinweis/Link auf den Thread hier 
posten. Das Protokoll sollte mE im NetProtocol.c/.h der einschlägigen 
gitee Repos definiert sein. Ich habe nur bisher keinen Endpoint 
entdecken können. Aber vielleicht willst Du ja Deine Ergebnisse mit 
Wireshark / mitmproxy o.ä. in dem neuen Thread publizieren ?

[Ziyat T. (toe_c)]

@isnoAhoy
@Daniel R. schrieb:
> In der Excel steht folgendes, kannst du das mal probieren für MI?
> Siehe Anhang.
>
> Target würde ich mal als DTU sehen, oder?
>
> Gongfa steht für:
> to attack
> to raid

Ich hab es probiert, bekomme nichts vom MI.

Meine DTU-Pro hat sowas auch nie geschickt, besser gesagt hab nie 
gesichtet.

Was ich nicht ganz verstehe ist, wie soll diese 0x2 als 
broadcast/search_packet gelten? Normalerweise ist die routing_adress ist 
ja die WR-Adresse, dann ist ja WR bekannt! Oder welche routing_adress 
sollte es sein?
target_adress ist DTU, das ist klar.

Für mich ist die 0x2 einfache WR Abfrage, oder?

[Thomas G. (glatho)]

A.D. schrieb:
> gibt es Wechselrichter bei denen es nicht funktioniert?
> Hab hier ein HM-600 der irgendwie nicht will.


An diesem Problem hab ich jetzt auch 2 Tage gehangen.
Keine Ahnung warum aber mein HM-600 wollte partout nicht
antworten wenn er nur auf Kanal 40 angefunkt wird.
Mit Kanal 3 und 23 funktioniert es.

Ich nehme an du verwendest Ahoy für den ESP8266?
Probiere mal ob es funktioniert wenn Du in der hmRadio.h
mTxChLst[0] = 40; änderst in Kanal 3 oder 23.

[A.D. (Gast)]

A.D. schrieb:
> gibt es Wechselrichter bei denen es nicht funktioniert?
> Hab hier ein HM-600 der irgendwie nicht will.

Hat sich erledigt. Irgendwann konnte ich ihn dann doch zum "reden" 
überzeugen :)

[A.D. (Gast)]

Thomas G. schrieb:
> Ich nehme an du verwendest Ahoy für den ESP8266?
> Probiere mal ob es funktioniert wenn Du in der hmRadio.h
> mTxChLst[0] = 40; änderst in Kanal 3 oder 23.

Ja, verwende ich. Warum auch immer fing er dann nach nem halben Tag an 
doch zu kommunizieren. Aber danke trotzdem für den Tipp!!

[Markus (Gast)]

Hallo Zusammen,

finde ich toll was ihr da so angestellt habt.
ich versuche mich daran das auf einen ESP32 zu laden habe mich an die 
Anleitung gehalten in https://github.com/tbnobody/OpenDTU aber Probleme 
beim aufspielen auf den ESP32.
habe 9immer die Fehlermeldung "Der Terminalprozess 
"C:\Users\Markus\.platformio\penv\Scripts\platformio.exe 'run', 
'--target', 'upload'" wurde mit folgendem Exitcode beendet: 1. "

gruß Markus

[SM D. (bandit7311)]

Hallo,

bin schon seit einer Weile mit Begeisterung den Thread am verfolgen. Da 
ich momentan ziemlich eingespannt bin kann ich leider nicht aktiv 
mitwirken.

Hätte folgende Fragen:

a) Ist die Einspeiselimitierung schon implementiert (z.B. 70%)?

b) Wurde schon die Modbusverbindung zu einem Smartmeter (z.B. CHINT 666) 
eingebunden zwecks z.B. Null-Einspeisung, alternativ z.B. auch Shelly 
oder andere?

Solong B.

[Strg F (Gast)]

SM D. schrieb:
> Hätte folgende Fragen

Einfach Strg F bemühen, ggf. Seitenaufteilung abschalten.

[tom (Gast)]

hat jemand eine fertige bin Datei von der aktuellen Version für mich?

[Günter H. (gnter_h534)]

tom schrieb:
> hat jemand eine fertige bin Datei von der aktuellen Version für mich?

Hier ist sie.

[Gerald R. (visitor)]

Ich habe in der AHOY 0.4.20 etwas experimentiert und schreibe die 
"inverter data" Ausgabe die normalerweise nur über die serielle 
Schnittstelle kommt zusätzlich auf eine SD Karte.

So können Laptop und Router beim loggen ausgeschaltet bleiben.
Ich würde gerne für jeden Tag eine neue Datei erstellen, verstehe aber 
nicht wie ich das aktuelle Datum aus der main.cpp in der app.cpp 
erhalte.

String logFilename = "log";
logFilename += date();
ergibt:
'date' was not declared in this scope


String logFilename = "log";
logFilename += year();
ergibt:
1970

Entweder ich bekomme "date" welches in der main.cpp schon berichtigt 
wird in die app.cpp, oder oder ich schaffe es die NTP Zeit auf die 
"Arduino time" zu übertragen damit year(), month() etc stimmen.

Ja, da scheitert es an Grundlagen, ist mir klar ;-)

Wäre trotzdem nett wenn mich jemand in die richtige Richtung schubsen 
würde.

[dax (Gast)]

Könnten Sie bitte eine Quelle für die Bibliothek "dbg.h" für Arduino 
bereitstellen

[tom (Gast)]

Günter H. schrieb:
> tom schrieb:
>> hat jemand eine fertige bin Datei von der aktuellen Version für mich?
>
> Hier ist sie.



Vielen Dank

[Gerald R. (visitor)]

Habe es jetzt mit meinem WEMOS D1 mini hinbekommen und werde es morgen 
testen.
Ein diff zum Head 0b9ab0100a9cf2b428911dfbe3f79d82886109e3 (0.4.20) 
hänge ich an.

CS Pin ist wie im Quellcode ersichtlich auf D0, der Rest MISO MOSI CLK 
VDD und GND ist wohl selbsterklärend.

[tom (Gast)]

macht es einen unterschied ob ich einen normalen d1 mini oder einen d1 
mini pro verwende?
aktuell hab ich einen d1 mini und der fällt immer wieder aus

[Gerald R. (visitor)]

Ich habe den D1 mini V2 von Reichelt, der ist bei mir noch nie 
ausgefallen.
https://secure.reichelt.at/at/de/d1-mini-esp8266-v2-0-d1-mini-p253978.html?&nbc=1

[Falcon81 (Gast)]

Hallo an Alle und als erstes ein herzliches Dankeschön für eure Arbeit.
Ich lese hier schon eine Weile mit und habe auch schon so einige 
Versionen auf meinem ESP8266 geflasht.
Habe einen HM-600.

Bekomme mit der Version 4.24 bzw. 4.25 folgende Ausgabe im Terminal:

I: Requesting Inverter SN 1141xxxxxxxx
I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 
I: Inverter #0 I: no Payload received! (retransmits: 3)

Nach einem zurück auf Version 4.22 (hatte ich als .bin noch), wurden 
sofort wieder Daten empfangen.

Auch ein Wechsel auf Kanal 3 oder 23 brachte keine Verbesserung.
Habe die beiden Versionen (4.25 zu 4.22) verglichen soweit ich den Code 
verstanden habe, aber nichts gefunden, welches das unterschiedliche 
Verhalten der beiden Versionen erklärt.

Vielleicht kann jemand mal darüber schauen, der mehr Ahnung hat als ich?

Danke und einen schönen Sonntag.

[oxylog (Gast)]

Falcon81 schrieb:
> Bekomme mit der Version 4.24 bzw. 4.25 folgende Ausgabe im Terminal:

Von 4.22 auf 4.25 wurden die Pins für CE und IRQ wieder getauscht - 
eventuell liegt da der Hase im Pfeffer?

"Reverted the default settings to CE=D4 and IRQ=D3 so it matches the 
pinout diagrams for the time being."

4.25
// PINOUT (Default, can be changed in setup)
//-------------------------------------
#define RF24_CS_PIN         15
#define RF24_CE_PIN         2
#define RF24_IRQ_PIN        0

4.22
/ PINOUT (Default, can be changed in setup)
//-------------------------------------
#define RF24_CS_PIN         15
#define RF24_CE_PIN         0
#define RF24_IRQ_PIN        2

[Falcon81 (Gast)]

Vielen, vielen Dank.
Das war es.
Nach dem Tausch von CE und IRQ läuft es wieder

[Thomas B. (tbnobody)]

Markus schrieb:
> Hallo Zusammen,
>
> finde ich toll was ihr da so angestellt habt.
> ich versuche mich daran das auf einen ESP32 zu laden habe mich an die
> Anleitung gehalten in https://github.com/tbnobody/OpenDTU aber Probleme
> beim aufspielen auf den ESP32.
> habe 9immer die Fehlermeldung "Der Terminalprozess
> "C:\Users\Markus\.platformio\penv\Scripts\platformio.exe 'run',
> '--target', 'upload'" wurde mit folgendem Exitcode beendet: 1. "
>
> gruß Markus

Hallo Markus,

da sollten davor noch mehr Meldungen erscheinen. Diese dürften 
aussagekräftiger sein.

[Chris P. (chris_p975)]

Ihr seit echt der Hammer!
Habe mir nen Wemos d1 mini und das Funkmodul gekauft, verkabelt, die 
220713_ahoy_0.4.25_esp8266.bin von Günther H. geflasht, dann per Wifi AP 
die Werte eingetragen und zack... alles läuft!
Vielen Dank!

[Rene M. (Firma: Bitte wählen) (renmo)]

Ich hoffe, dass die Leistungsbegrenzung noch kommt.

[Kla H. (klahus1)]

Hallo zusammen,

ich bin froh verkünden zu können, dass die Leistungsreduzierung / 
Leistungseinstellung für den HM300 funktioniert.
In den nächsten Tagen werde ich das Ganze dokumentieren und hier 
bereitstellen.
DanielR92 testet gerade seinen HM1500.

Auch ich werde noch Weiteres testen, wenn die Sonne wieder scheint ;-)

Viele Grüße
Klaus

[Daniel R. (daniel92)]

Kla H. schrieb:
> DanielR92 testet gerade seinen HM1500.

Genau.
Habe für Python (RPi) denn Modbus CRC16 schon hinterlegt.
Das ganze möchte ich sauber noch ziehen, da es probleme beim Paket bauen 
gibt.

@Jan-Jonas: Da müsste man nochmal was anpassen. :)

Aktuell ist 0x80 immer fest als Sub-CMD sowie CMD.
Dies muss man abändern.

PS: Aktuell läuft die HM-1500 auf ~25W! =)

[Kla H. (klahus1)]

Hallo zusammen,

hier die erste Version des Protokolls:

https://github.com/tbnobody/OpenDTU/issues/35

https://github.com/grindylow/ahoy/issues/31

Vielen Dank an die tolle "Vorarbeit" hier im Forum.

Besonders Stefan T. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
und Daniel R. für die hilfreichen Hinweise.

Erste Version quick and dirty mit dem openDTU implementiert und 
getestet:

limit = zwei Byte, eine Dezimalstelle. Z.B: 30W = 300dez = 0x01 0x2c

<0x51> <WR>     <DTU>    <0x81>   <0x0b 0x00> <0x01 0x2c> <0x01 0x00>            <crc16/modbus> <crc8>
<Cmd>  <target> <source> <subcmd> <ctrlmode>  <limit>     <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8>

Log:

22:28:13.964 > Fetch inverter: 112172615582
22:28:13.964 > sendPackSetPowerLimitCommand
22:28:13.966 > sendEsbPacket
22:28:13.969 > TX 51 72 61 55 82 78 56 34 12 81 0B 00 01 2C 01 00 C5 C0 3E 
...
22:28:14.897 > Interrupt received
22:28:14.897 > 
22:28:14.897 > >> RX  OK: D1 72 61 55 82 72 61 55 82 81 00 00 0B 00 14 07 48 
22:28:14.903 > 
22:28:15.271 > RX Period End
22:28:15.271 > getLastRequest() == RequestType::Cmd
22:28:15.275 > Success

Siehe auch :

usart_nrf3.cpp
UsartNrf_Send_DevControlUpdate()
...
                    MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[0] = (u8)(relative_value >> 8);
                    MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[1] = (u8)(relative_value);
                    MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[0] = 0;
                    MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[1] = 1;

...Happy coding...

VG
Klaus

[Stefan T. (isnoahoy)]

Kla H. schrieb:
> Vielen Dank an die tolle "Vorarbeit" hier im Forum.
> limit = zwei Byte, eine Dezimalstelle. Z.B: 30.0W = 300dez = 0x01 0x2c

<0x51> <WR>     <DTU>    <0x81>   <0x0b 0x00> <0x01 0x2c> <0x01 0x00>            <crc16/modbus> <crc8>
<Cmd>  <target> <source> <subcmd> <ctrlmode>  <limit>     <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8>

Danke fürs Ausprobieren und die Lösung, daß das Limit mit einer 
Dezimalstelle angegeben wird war mir bisher nicht klar. Das ist die 
Wucht, Gratuliere!

Mit besten Grüßen,
Stefan T.

[Rene M. (Firma: Bitte wählen) (renmo)]

Einfach genial.
Danke an die Hirnis hier!

[Angsthase (Gast)]

Hallo,

besteht da nicht die Gefahr, das man seinen WR völlig und unwiderruflich 
verstrubbelt?

Oder hat der ne Resettaste?
Mein HM1200 nicht.

[Claus T. (Gast)]

Angsthase schrieb:
> Hallo,
>
> besteht da nicht die Gefahr, das man seinen WR völlig und unwiderruflich
> verstrubbelt?
>
> Oder hat der ne Resettaste?
> Mein HM1200 nicht.

Die Gefahr besteht immer :-)
Zur Resettaste:
Vielleicht hilft kpl. stromlos machen, also DC 
(Solarpanel/Netzteil/Batterie) und AC-Stecker ziehen für eine gewisse 
Zeit.
Ist das schon jemandem der Tester aufgefallen?
Bleiben die Total-Werte immer erhalten?

[locke987 (Gast)]

Wie erkennt man eigentlich wenn eine neue Version der OpenDTU verfügbar 
ist?
Aktuell habe ich:
SDK Version      v4.4.1-1-gb8050b365e
Firmware Version    0.1.18
Git Hash      g63ccf38

Die habe ich heute gebuilded und die *.bin per Firmware Upgrade Funktion 
eingespielt. Erkennt man im Git irgenwo welche Version gerade aktuell 
ist?
Vielen Dank!

[Hoyle (Gast)]

Mal eine Frage bezüglich der Leistungsreduzierung:
Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher 
interessiert bei meinem HM-600 die 600W Begrenzung aufzuheben und alles 
rauszuholen, was die Module hergeben ;)
Klärt ihr mich auf? Danke

[Thomas B. (tbnobody)]

locke987 schrieb:
> Wie erkennt man eigentlich wenn eine neue Version der OpenDTU verfügbar
> ist?
> Aktuell habe ich:
> SDK Version      v4.4.1-1-gb8050b365e
> Firmware Version    0.1.18
> Git Hash      g63ccf38
>
> Die habe ich heute gebuilded und die *.bin per Firmware Upgrade Funktion
> eingespielt. Erkennt man im Git irgenwo welche Version gerade aktuell
> ist?
> Vielen Dank!

Es gibt keine Versionsnummern. Alles was im Git ist ist stabil (nach 
bestem Wissen und Gewissen).
Die einzelnen Git Commits sieht man ja hier: 
https://github.com/tbnobody/OpenDTU/commits/master

Bei jedem Commit steht rechts der Git Hash. Im aktuellen Fall 63ccf38. 
Das ist auch der Git Hash den du in der System Overview siehst. Damit 
lässt sich exakt bestimmen welche Version man aktuell am laufen hat.

[Herbert K. (avr-herbi)]

Hoyle schrieb:
> Mal eine Frage bezüglich der Leistungsreduzierung:
> Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher
...
> Klärt ihr mich auf? Danke

Hier geht es um das Reverse Engineering des Protokolls und nicht ob 
etwas sinnvoll ist oder nicht. Wer es braucht und warum findest Du in 
den 1679 Beiträgen hier.
Wenn Du eine Diskussion über Deine Wünsche möchtest, mach bitte ein 
eigenen Thread auf und kapere nicht diesen. Da könnt Ihr dann auch über 
zu tauschende MOSFETs im WR diskutieren. Danke.

[Hoyle (Gast)]

Herbert K. schrieb:
> Hoyle schrieb:
>> Mal eine Frage bezüglich der Leistungsreduzierung:
>> Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher
> ...
>> Klärt ihr mich auf? Danke
>
> Hier geht es um das Reverse Engineering des Protokolls und nicht ob
> etwas sinnvoll ist oder nicht. Wer es braucht und warum findest Du in
> den 1678 Beiträgen hier.
> Wenn Du eine Diskussion über Deine Wünsche möchtest, mach bitte ein
> eigenen Thread auf und kapere nicht diesen. Da könnt Ihr dann auch über
> zu tauschende MOSFETs im WR diskutieren. Danke.

Hohoho was ist denn für ein Umgangston? Ich würde behaupten, ich lese 
den Thread schon länger mit als du... Aber darum geht es nicht. Und den 
Mund verbieten lasse ich mir von dir schon garnicht.

Mich interessiert der Anwedungsfall für die gewünschte 
Leistungsreduzierung - nicht mehr nicht weniger. Dass ich mir eher die 
Möglichkeit wünschen würde, die Leistung aufzubohren (bzw. die 
willkürliche 600W Begrenzung für DE) soll nur mein Unverständnis 
/-wissen diesbezüglich verdeutlichen.
Wenn du dazu nichts beizutragen hast, dann überlies doch bitte einfach 
meinen Post. Danke Hoyle

[Thomas B. (tbnobody)]

Hoyle schrieb:
> Mich interessiert der Anwedungsfall für die gewünschte
> Leistungsreduzierung - nicht mehr nicht weniger.

Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem 
Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen 
als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts 
läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR 
limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss 
könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die 
Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das 
ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt.

[locke987 (Gast)]

Thomas B. schrieb:
> Das ist auch der Git Hash den du in der System Overview siehst. Damit
> lässt sich exakt bestimmen welche Version man aktuell am laufen hat.

Vielen Dank!!!

[Hoyle (Gast)]

Thomas B. schrieb:
> Hoyle schrieb:
>> Mich interessiert der Anwedungsfall für die gewünschte
>> Leistungsreduzierung - nicht mehr nicht weniger.
>
> Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem
> Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen
> als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts
> läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR
> limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss
> könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die
> Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das
> ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt.

Aha!
Danke für die Ideen dazu.
Mir hat sich diese Frage bisher noch garnicht gestellt, da hier noch ein 
alter Ferraris-Zähler (ggf. auch mal ein paar Umdrehungen rückwärts) 
läuft.
So lange den keiner wechseln will, komme ich noch nicht in die 
Versuchung, über Batterien und verschenkte kWh nachzudenken :)
Danke Thomas!

[Angsthase (Gast)]

Stefan T. schrieb:
> Kla H. schrieb:
>> Vielen Dank an die tolle "Vorarbeit" hier im Forum.
>> limit = zwei Byte, eine Dezimalstelle. Z.B: 30.0W = 300dez = 0x01 0x2c
> 1<0x51> <WR>     <DTU>    <0x81>   <0x0b 0x00> <0x01 0x2c> <0x01 0x00>
> <crc16/modbus> <crc8>
> 2<Cmd>  <target> <source> <subcmd> <ctrlmode>  <limit>     <?desc?-fix
> 0x01 0x00> <crc16/modbus> <crc8>
>
> Danke fürs Ausprobieren und die Lösung, daß das Limit mit einer
> Dezimalstelle angegeben wird war mir bisher nicht klar. Das ist die
> Wucht, Gratuliere!
>
> Mit besten Grüßen,
> Stefan T.

Wirst Du das auch in Deine Software mit einbauen?

[Claus T. (Gast)]

Thomas B. schrieb:
> Dann könnte man den WR
> limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss
> könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die
> Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das
> ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt.

Zum Anschluss des WR an eine Batterie, statt den Solarpanels, würde mich 
interessieren, ob es einen Befehl zum deaktivieren der MPPT-Regler für 
die Panels gibt, bzw. Batterie-Betrieb umschalten?
Ist da bei der DTU-Pro was vorgesehen?

[Heiko (Gast)]

Hallo,
ich lese schon einige Zeit hier mit und sage erstmal Danke für die ganze 
Arbeit. Ich habe mir kürzlich ein ESP8266 und Funkmodul zusammengebaut 
und die bin von Günter H. geflasht. Geht super, nochmals Danke.
Eine Sache ist mir in der V0.4.25 aufgefallen: wenn das WLan wiederkehrt 
(nach Nachtabschaltung) verbindet sich MQTT nicht wieder, erst nach 
Neustart. In der V0.4.22 schien das zu gehen.
Schöne Grüße
Heiko

[Daniel M. (daniel_m821)]

Claus T. schrieb:
> Zum Anschluss des WR an eine Batterie, statt den Solarpanels, würde mich
> interessieren, ob es einen Befehl zum deaktivieren der MPPT-Regler für
> die Panels gibt, bzw. Batterie-Betrieb umschalten?
> Ist da bei der DTU-Pro was vorgesehen?

Moin,

ein Befehl dafür ist mir nicht aufgefallen. Der MPPT läuft automatisch 
ab eine bestimmten Spannung mit und versucht einfach, den Leistungspunkt 
zu optimieren.
Meine Erkenntnisse aus der DTU zeigen nur den "normalen" Leistungsumfang 
wie die 0-Einspeisung in Verbindung mit dem CHiNT Meter, die restliche 
Leistungsreduktion wurde durch Daniel R. dahingehend auf Basis dieser 
Befehle erfolgreich getestet.

Wenn du mehr darüber wissen willst, wir haben mittlerweile auf dem 
Discord einen Speichersysteme-Channel, wo wir sowas genauer besprechen 
können. Dort gibt es bereits mehrere Ansätze, bei denen du dich gerne 
mit Einbringen kannst, keine Idee ist verrückt genug :)

Turn On/Turn Off/Restart sind ebenfalls seit eben bekannt.

Das ganze werde ich für die MI-Version nachher noch anschauen, 
Leistungsreduktion auf der MI-Serie (bei mir MI-600) habe ich auch 
mitgeschnitten, ist nur noch nicht ausgewertet.
Controls muss ich extra machen, war leider schon zu dunkel dafür.

lg

[Kev (Gast)]

Hallo,

erstmals ein großes Dankeschön an alle, die geholfen haben, dieses 
Projekt weiter zu bringen. Es ist immer schön zu sehen was eine Hand 
voll kluger Köpfe erreichen kann. :)

Ich bin auf den Thread gestoßen, nachdem wir bei einem Freund eine 
HM-1200-Anlage mit einem HM-1500 erweitert haben, und auf das 
Vier-Platten-Limit des DTU-Lite gestoßen sind. Zudem war uns die 
Cloud-Geschichte schon immer ein Dorn im Auge.

Beim Zusammenlöten und Testen bei mir vor Ort habe ich spaßeshalber die 
SN meines TSUN TSOL-M350 eingegeben, da diese wie bei den Modellen 
HM-300, HM-350 und HM-400 mit "1121" beginnt.

Und siehe da: es funktioniert ohne Probleme. Nachdem die Integration in 
mein Grafana gebaut wurde, bleibt wohl ein ESP bei mir. :)

Viele Grüße,

Kev

[Tarifarbeiter (Gast)]

Thomas B. schrieb:
> Hoyle schrieb:
>> Mich interessiert der Anwedungsfall für die gewünschte
>> Leistungsreduzierung - nicht mehr nicht weniger.
>
> Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem
> Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen
> als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts
> läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR
> limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss
> könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die
> Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das
> ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt.

Der WR hat genau einen Ausgang, und zwar die Netzeinspeisung (50Hz 
230V). Wenn ich jetzt das limitiere, wie genau bekomme ich den Überfluss 
an Leistung aus dem PV panelen in meine Batterie?

VG

[Stefan T. (isnoahoy)]

Hier die drei o.g. Commands für das Ein-/Ausschalten bzw. den Reset des 
Wechselrichters.

51 76543210 78563412 81 0000 B001 A5 ------ Type_TurnOn 0x00
51 76543210 78563412 81 0100 2000 55 ------ Type_TurnOff 0x01
51 76543210 78563412 81 0200 D000 7B ------ Type_Restart 0x02
^^-------------------------------------- MainCmd 0x51 DEVCONTROL_ALL
   ^^^^^^^^----------------------------- WR Serial ID
            ^^^^^^^^-------------------- DTU Serial ID
                     ^^----------------- SingleFrameID
                        ^^-------------- SubCmd siehe oben
                        ^^^^------------ Control Mode ? immer zwei Byte im Gen3 Protokoll
                              ^^^^------ CRC16 / CRC-Modbus über die Daten, excl. Frame ID!
                                   ^^--- CRC8

Die CRC16 und CRC8 läßt sich ggf. online berechnen, falls es jemand mal 
schnell kontrollieren will:

CRC-16/CRC-Modbus Input Data: 0x0200
Result CRC-16/CRC-Modbus value: 0xD000
https://crccalc.com/?crc=0x0200&method=CRC-16/MODBUS&datatype=hex&outtype=0

CRC-8 Input value: 0x51 76543210 78563412 81 0200 D000
Result CRC-8 value: 0x7B
https://crccalc.com/?crc=0x517654321078563412810200D000&method=CRC-8/ITU&datatype=hex&outtype=0

---

Und hier das Power Limit setzen

51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B
^^--------------------------------------------- MainCmd 0x51 DEVCONTROL_ALL
   ^^^^^^^^------------------------------------ WR Serial ID
            ^^^^^^^^--------------------------- DTU Serial ID
                     ^^------------------------ SingleFrameID
                        ^^--------------------- SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr
                        ^^^^------------------- Control Mode
                             ^^^^-------------- PowerPFDev.SetValut 0x012C = 30.0 W
                                  ^^^^--------- PowerPFDev.Desc 0x0000 oder 0x0001 ?
                                       ^^^^---- CRC16 / CRC-Modbus über die Daten, excl. Frame ID!
                                            ^^- CRC8

CRC-16/CRC-Modbus Input Data: 0x0B00 012C 0000
Result CRC-16/CRC-Modbus value: 0x55C1
https://crccalc.com/?crc=0x0B00012C0000&method=CRC-16/MODBUS&datatype=hex&outtype=0

CRC-8 Input value: 0x51 76543210 78563412 81 0B00 012C 0000 55C1
Result CRC-8 value: 0x0F
https://crccalc.com/?crc=0x517654321078563412810B00012C000055C1&method=CRC-8/ITU&datatype=hex&outtype=0

Die Antwort Pakete haben wir noch nicht entschlüsselt, aber es kommt 
immer (MainCmd | 0x80) also ANSWER_DEVCONTROL_ALL 0xD1 zurück. Bei 
Fehlern in der Nachricht oder der CRC-16/CRC-Modbus Checksumme kommt 
0xF1 oder 0xFF als Fehlercode je nachdem ob es sich um eine SingleFrame 
oder MultiFrame Anfrage gehandelt hat.

[Herbert K. (avr-herbi)]

Stefan T. schrieb:
> Hier die drei o.g. Commands für das Ein-/Ausschalten bzw. den Reset des
> Wechselrichters....
Hallo Stefan T.,
sind die für für MI-xxxx oder HM-xxxx ?
SUPER Arbeit von Dir !

[Tobi (Gast)]

Kurze Frage: muss es ein NRF24L01+ sein oder funktioniert auch ein 
NRF24L01?

[Herbert K. (avr-herbi)]

Tobi schrieb:
> Kurze Frage: muss es ein NRF24L01+ sein oder funktioniert auch ein
> NRF24L01?
Es MUSS ein "+"  sein

[Carsten B. (carstenb)]

> Der WR hat genau einen Ausgang, und zwar die Netzeinspeisung (50Hz
> 230V). Wenn ich jetzt das limitiere, wie genau bekomme ich den Überfluss
> an Leistung aus dem PV panelen in meine Batterie?
>
Hallo,

ich denke die Idee dahinter ist, den WR (nicht nich bestimmungsmässem 
Gebrauch) an eine Batterie zu hängen (z.B. LiFePo mit 24, 36 oder 48V) 
und über die Begrenzung dann die Ausgangsleistung passend zum 
Hauverbrauch zu regeln. Das wäre eine sehr preisgünstige Sache mit einem 
Netzsetig konformen WR.

Gruß

Carsten

PS: vieleich hierzu ein Seperates Thema aufmachen, wenn es mehr Leute 
interessiert?

[Daniel M. (daniel_m821)]

Herbert K. schrieb:
> sind die für für MI-xxxx oder HM-xxxx ?

Das betrifft die HM-Serie.

Mein TSUN ist eigentlich ein MI-600, daher habe ich für MI
folgendes direkt an der DTU Pro mitgeloggt:
OFF-CMD: 51 63500316 63500316 AA55 AE
ON-CMD:  51 63500316 63500316 55AA AE
Reboot: 0E 63500316 63500316 1000 0000 12EE E2

Leistung:
51 63500316 63500316 5A5A 2C0A 86F1
51 63500316 63500316 5A5A 1C06 C08B

Was aus der Leistung rauslesbar ist, weiß ich noch nicht, aber ihr habt 
erstmal wieder Futter für die 2-Kanal MI :)

Anbei außerdem diverse Logs direkt am NRF-Modul der Pro, drin zu finden 
Powerlimits in Verbindung mit dem CHiNT-Zähler, Limitierung des HM-1500 
und des MI-600, Reboot-, ON- und OFF- Commands.

[Daniel M. (daniel_m821)]

Carsten B. schrieb:
> PS: vieleich hierzu ein Seperates Thema aufmachen, wenn es mehr Leute
> interessiert?

Die Thematik haben wir u.a. auf dem Discord. Ich denke, hier ist es 
sinnvoll, später ein extra Thema zu starten, wenn die Erkenntnisse 
soweit sind, dass man es verwenden kann, zumal div. Zähler/Messgeräte 
zusätzlich benötigt werden.
Aktuell ist es noch so, dass zwar grundlegende Funktionen bekannt sind, 
jedoch noch nicht überall integriert.

Derzeit hat Daniel R. ein Labornetzteil und einen Raspi zum Testen, mir 
fehlen Programmierkenntnisse um das ganze in AHOY und OpenDTU 
einzubauen, damit kann ich nur Daten abfischen und bereitstellen.

Die weitere Problematik ist die Berechnung der Limits anhand der 
benutzten Eingänge über mehrere Geräteklassen hinweg (1- und Mehrkanal 
HM/MI), was nicht ganz trivial ist.

Klar ist: Eine netzkonforme Ausspeisung aus einem Akku ist der Weg, den 
einige hier wünschen :)

lg

[SM D. (bandit7311)]

Hallo,

ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der 
wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später 
ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass 
das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite 
die dann aber kurz später nicht mehr erreichbar ist.

Hat jemand eine Idee was das sein könnte?

Solong B

[locke987 (Gast)]

Ich hatte gestern und heute 2 "Unknown" events im Log, einmal Event ID 
12 und einmal ID 47. Weiß Jemand welche Fehlermeldung das sein könnte? 
Bzw. ist es geplant in der OpenDTU die Loginformationen zu erweitern? 
Ich speichere alle verfügbaren Werte momentan über mqtt in einer 
influxdb und Werte diese über Grafana aus, konnte aber keinerlei 
Zusammenhang zu den Zeitpunkten der Fehlermeldungen erkennen.

[Daniel M. (daniel_m821)]

Update Leistungsregulierung MI-Serie (hier MI-600 & Kompatibel)

An der Schnittstelle zum NRF abgegriffene Daten sehen so aus:
<51> <63 50 03 16> <63 50 03 16> <5A 5A> <2D> <0A 9E> <E8>
Main-CMD 0x51, WR-ID, WR-ID, Sub-CMD 0x5A 0x5A, Limit %, Limit Absolut, 
CRC8

Die CRC8 über den ganzen Block.
Meine DTU sendet das Powerlimit basierend auf 1%=6W (100%=600W),
0x2D = 45%, 0x0A 0x9E = 271,8W (DEC 2.718)

51 63500316 63500316 5A5A 2D 0AA0 D6 -> 45% 272,0W
51 63500316 63500316 5A5A 65 17CC EF -> 101% 609,2W
51 63500316 63500316 5A5A 3F 0EF0 90 -> 63% 382,4W

Ich weiß nicht, ob ein Limit von 100% mit einem absoluten Wert 
funktioniert, für die 2-Kanal MI könnte das aber ein Ansatz sein.

Viel Spaß beim Testen :)

lg

[Chris (Gast)]

Kann man irgendwie prüfen ob der NRF24L01+ richtig arbeitet? Also gibt 
es einen Log-Output auf dem ESP32?

Ich hab alles verlötet, den ESP32 geflasht, die Weboberfläche startet - 
aber ich bekomme keine Daten vom Hoymiles.

Darum würde ich gerne wissen ob mein NRF24L01+ Board "am Leben" ist.

[Joni N. (hal_9000)]

Chris schrieb:
> Kann man irgendwie prüfen ob der NRF24L01+ richtig arbeitet? Also
> gibt es einen Log-Output auf dem ESP32?

Schau auf welchem COM Port dein ESP32 hängt und geh einfach mit einem 
Serial Monitor drauf (mit 115200 Baud).

Dort findest du dann Zeilen wie:

Starting OpenDTU
...
Setting Hostname... Configuring WiFi STA using new credentials... done
...
Initialize Hoymiles interface... Connection successfull
...

Im Fehlerfall, also falls die Initialization vom NRF gar nicht klappt, 
sollte da das hier stehen:

Initialize Hoymiles interface... Connection error!!

[Thomas B. (tbnobody)]

locke987 schrieb:
> Ich hatte gestern und heute 2 "Unknown" events im Log, einmal Event ID
> 12 und einmal ID 47. Weiß Jemand welche Fehlermeldung das sein könnte?
> Bzw. ist es geplant in der OpenDTU die Loginformationen zu erweitern?
> Ich speichere alle verfügbaren Werte momentan über mqtt in einer
> influxdb und Werte diese über Grafana aus, konnte aber keinerlei
> Zusammenhang zu den Zeitpunkten der Fehlermeldungen erkennen.

Das Eventlog kommt 1zu1 aus dem Inverter. Hier Dinge zu erweitern wird 
also eher nichts werden. Was dagegen noch machbar ist, ist die 
Interpretation der enthaltenen Daten. ID 12 bzw. 47 hatte ich bisher 
noch nicht. Manchmal sehe ich Abends eine 36. Aber auch nicht jeden Tag.

[Joni N. (hal_9000)]

Ich habe gerade das erste mal versucht eine Verbindung aufzubauen. Wenn 
ich außerhalb der Reichweite bin, dann kommt:

TX 15 81 10 4 20 78 56 34 13 80 B 0 62 DA 4C 23 0 0 0 5 0 0 0 0 4C D2 6E 
RX Period End
All missing
Nothing received, resend count exeeded

Wenn ich innerhalb der Reichweite bin kommt laufend:

Fetch inverter: 116181100420
Fetch inverter: 116181100420
Fetch inverter: 116181100420
Fetch inverter: 116181100420
...

Ich vermute mal, dieses "Fetch" bedeutet, dass die Verbindung klappt.

Problem: Ich bekomme trotzdem keine Werte, im Web Interface sind 
sämtliche Werte auf 0. Das "Event Log" hat auch 0 Einträge.

Was könnte das Problem sein?

[Ziyat T. (toe_c)]

Daniel M. schrieb:
> Update Leistungsregulierung MI-Serie (hier MI-600 & Kompatibel)
>
> An der Schnittstelle zum NRF abgegriffene Daten sehen so aus:
> <51> <63 50 03 16> <63 50 03 16> <5A 5A> <2D> <0A 9E> <E8>
> Main-CMD 0x51, WR-ID, WR-ID, Sub-CMD 0x5A 0x5A, Limit %, Limit Absolut,
> CRC8
>
> Die CRC8 über den ganzen Block.
> Meine DTU sendet das Powerlimit basierend auf 1%=6W (100%=600W),
> 0x2D = 45%, 0x0A 0x9E = 271,8W (DEC 2.718)
>
> 51 63500316 63500316 5A5A 2D 0AA0 D6 -> 45% 272,0W
> 51 63500316 63500316 5A5A 65 17CC EF -> 101% 609,2W
> 51 63500316 63500316 5A5A 3F 0EF0 90 -> 63% 382,4W
>
> Ich weiß nicht, ob ein Limit von 100% mit einem absoluten Wert
> funktioniert, für die 2-Kanal MI könnte das aber ein Ansatz sein.
>
> Viel Spaß beim Testen :)
>
> lg

Ok, der MI600 ist ja scheinbar gleich was ich vom MI-1500 berichtet 
hatte.

Das mit % oder abs. Wert funktioniert entweder oder, wenn du % eingibst 
wird nach der %-Wattzahl der Nennleistung limitiert, wenn du abs. Wert 
eingibts, also 2. byte nach 0x5a5a, wird die % Zahl ignoriert.

[Thomas B. (tbnobody)]

Joni N. schrieb:
> Ich vermute mal, dieses "Fetch" bedeutet, dass die Verbindung klappt.
>
> Problem: Ich bekomme trotzdem keine Werte, im Web Interface sind
> sämtliche Werte auf 0. Das "Event Log" hat auch 0 Einträge.

Das Fetch bedeutet, dass versucht wird was vom Inverter zu lesen. Aber 
wenn darauf keine TX Nachrichten kommen (was bei dir ja nicht der Fall 
ist) scheint keine valide Uhrzeit vorzuliegen. Hier scheint der ESP 
keine Internet Verbindung zu bekommen um die Zeit vom NTP Server zu 
holen.

[Joni N. (hal_9000)]

Thomas B. schrieb:

> Das Fetch bedeutet, dass versucht wird was vom Inverter zu lesen.

Ah, OK. Pollst du die Werte für ein bestimmtes Zeitfenster? Muss 
deswegen die Zeit genau stimmen?

Haben die Hoymiles eine RTC eingebaut?

[Frank K. (Gast)]

Kurze Erfahrung mit einem NRF24L01+ - Clone:
Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt 
mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen 
NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600 
empfangen.

Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt!

[Thomas B. (tbnobody)]

Joni N. schrieb:
> Ah, OK. Pollst du die Werte für ein bestimmtes Zeitfenster? Muss
> deswegen die Zeit genau stimmen?
>
> Haben die Hoymiles eine RTC eingebaut?

Die Zeit wird mit jedem Anfragepaket an den WR geschickt. Was der WR 
intern damit alles macht ist nicht bekannt. Fest steht, dass die Zeit 
anschließend im Eventlog auftaucht. Ob über diese Zeit auch die tägliche 
Produktion (also der Tageswechsel) ermittelt wird ist nicht bekannt aber 
möglich.

[Joni N. (hal_9000)]

Frank K. schrieb:
> Heute kamen die originalen
> NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600
> empfangen.

Welche/wo NRF24L01+ hast Du denn bestellt? Ich bin mir nicht sicher ob 
meine richtig funktionieren.

Ich würde gerne genau die selben wie Du bestellen.

[locke987 (Gast)]

Joni N. schrieb:
> Welche/wo NRF24L01+ hast Du denn bestellt?

Ich bin zwar nicht Frank aber diese beiden funktionieren bei mir beide 
in Verbindung mit einem ESP8266 und aktueller OpenDTU Version:

https://www.amazon.de/gp/product/B07PQPFTWZ/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1

https://www.amazon.de/gp/product/B06XJN417D/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

Gruß Stefan

[skusi (Gast)]

Frank K. schrieb:
> Kurze Erfahrung mit einem NRF24L01+ - Clone:
> Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt
> mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen
> NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600
> empfangen.
> Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt!

Wo hast du die originalen gekauft? Meine China Dinger zicken auch nur 
rum. Ich würde auch gerne andere ausprobieren.

[Holger S. (skusi)]

skusi schrieb:
> Frank K. schrieb:
>> Kurze Erfahrung mit einem NRF24L01+ - Clone:
>> Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt
>> mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen
>> NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600
>> empfangen.
>> Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt!
>
> Wo hast du die originalen gekauft? Meine China Dinger zicken auch nur
> rum. Ich würde auch gerne andere ausprobieren.

Sorry, hat sich erledigt, hab eben erst zu Ende gelesen...
Danke Stefan.

[Axel H. (ahinrichs)]

SM D. schrieb:
> Hallo,
>
> ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der
> wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später
> ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass
> das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite
> die dann aber kurz später nicht mehr erreichbar ist.
>
> Hat jemand eine Idee was das sein könnte?
>

Es könnte Reboots wegen zu schwacher Stromversorgung sein. Was sagt das 
serielle Log?

[Tobias G. (tobias_g841)]

Hallo,
ein tolles Projekt!
Was genau benötige ich nun für Teile?
ESP8266 + nrf24l01 ?
Muss es ein original Wemos ESP8266 sein? wemos ds1 mini?
Mal lese ich, es muss unbedingt ein nrf24l01+ sein, mal lese ich ein 
nrf24l01 reicht auch.
Kann jemand ggf. Links zu Amazon posten, von Teilen, die erfolgreich mit 
Hoymiles-Wechselrichtern funktionieren?
Ich bin ein wenig verwirrt, weil es nicht mein Tagesgeschäft ist ;-)
Danke.
Gruß, Tobias

[Return 5 (Gast)]

@Tobias G.
Einfach 5 Beiträge zurück. Da sind Links.
UND nirgends steht, das ein "nrf24l01"  ausreicht !
Es muß !!! ein "+" sein !

[Tobias G. (tobias_g841)]

@Return 5 Danke, aber deshalb frage ich ja, weil es m.E. in dem Link bei 
dem Artikel DollaTek 2Pcs NRF24L01 + PA + LNA nicht um den NRF24L01+ 
handelt, sondern hier nur das "+" geschickt als Ersatz für & im Rahmen 
einer Aufzählung verwendet wurde ... aber den Eindruck erwecken soll, 
dass es sich um den NRF24L01+ handelt. Oder liege ich falsch?

[RM (Gast)]

Hallo,
hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut?

[locke987 (Gast)]

Tobias G. schrieb:
> @Return 5 Danke, aber deshalb frage ich ja, weil es m.E. in dem
> Link bei
> dem Artikel DollaTek 2Pcs NRF24L01 + PA + LNA nicht um den NRF24L01+
> handelt, sondern hier nur das "+" geschickt als Ersatz für & im Rahmen
> einer Aufzählung verwendet wurde ... aber den Eindruck erwecken soll,
> dass es sich um den NRF24L01+ handelt. Oder liege ich falsch?

Wie auch immer, ich hab die Dinger beide im Einsatz und Sie 
funktionieren stabil seit ca. 2 Wochen, und wenn nicht schickst Du sie 
einfach wieder kostenlos zurück.

[locke987 (Gast)]

locke987 schrieb:
> Wie auch immer, ich hab die Dinger beide im Einsatz und Sie
> funktionieren stabil seit ca. 2 Wochen, und wenn nicht schickst Du sie
> einfach wieder kostenlos zurück.

auf dem Chip ist ein + drauf

[Daniel M. (daniel_m821)]

RM schrieb:
> Hallo,
> hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut?

Hi,
ja, auch das haben wir bereits angeschaut und versuchen das 
nachzuvollziehen.
Bitte etwas Geduld und gerne direkt auf Github AHOY und OpenDTU 
verfolgen.

Wofür brauchst du es genau?

(Und wer votet solche Fragen runter? Meine güte...)

lg

[RM (Gast)]

Daniel M. schrieb:
> RM schrieb:
>> Hallo,
>> hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut?
>
> Hi,
> ja, auch das haben wir bereits angeschaut und versuchen das
> nachzuvollziehen.
> Bitte etwas Geduld und gerne direkt auf Github AHOY und OpenDTU
> verfolgen.
>
> Wofür brauchst du es genau?
>
> (Und wer votet solche Fragen runter? Meine güte...)
>
> lg

Ich wollte mir mit 3x HM 1500 eine PV Anlage bauen und vor allem 
Anmelden.
Der Elektriker bzw der Enegergieversorger haben auf Ihrer Checkliste 
stehen, dass der Wechselrichter die Möglichkeit haben muss, die 
Blindleistung einzustellen.
Also einstellen will ich da nichts, aber bei der Abnahme muss ich Ihn 
demonstrieren, dass ich könnte.... In der DTU glaub ich gehts nicht, 
aber im Datenblatt ist was erwähnt, dass es gehen sollte.


Ich will die anmelden, es gibts zwar blos 6 cent aber besser als den 
Strom zu verschenken. Und ich brach weil alles so verwinkelt und 
verschattet ist 6 MPPT Tracker. Seit über 1,5 Jahren hab ich auch schon 
2x HM 300 im einsatz und auch beim Amateurfunk keine merklichen Probleme 
damit, das hab ich mit meinen Nachbarn und SMA Wechselrichter schon.

[Tobias G. (tobias_g841)]

Kann mir jemand helfen und sagen, ob ich diesen ESP hier nehmen kann 
oder lieber einen anderen?
https://www.amazon.de/AZDelivery-D1-Mini-Entwicklungsboard-kompatibel/dp/B0754N794H/ref=cm_cr_arp_d_product_top?ie=UTF8

[Denny S. (nightstorm99)]

Tobias G. schrieb:
> Kann mir jemand helfen und sagen, ob ich diesen ESP hier nehmen kann
> oder lieber einen anderen?
> 
https://www.amazon.de/AZDelivery-D1-Mini-Entwicklungsboard-kompatibel/dp/B0754N794H/ref=cm_cr_arp_d_product_top?ie=UTF8

Ja die sind Top und benutze sie auch.
4MB Flash sind wichtig

[Daniel M. (daniel_m821)]

RM schrieb:
>
> Ich wollte mir mit 3x HM 1500 eine PV Anlage bauen und vor allem
> Anmelden.

Das ist eine ordentliche Größe, da lohnt sich auch der Aufwand.

> Der Elektriker bzw der Enegergieversorger haben auf Ihrer Checkliste
> stehen, dass der Wechselrichter die Möglichkeit haben muss, die
> Blindleistung einzustellen.

Bitte was? Mir wäre neu, dass das bei kleinen Anlagen gefordert ist.
Im Normalfall machen die das selber, wenn die Messung sagt, dass es 
nötig ist.
Bist du sicher, dass es sich dabei um die Blindleistung und nicht um die 
normale AC-Leistung handelt?
Ich bin kein Netzbetreiber, aber ich denke, im Netz haben die größere 
Sorgen als 1,5kW Mikrowechselrichter justieren zu müssen.
Frag da nochmal nach ob die dich verarschen wollen.

> Also einstellen will ich da nichts, aber bei der Abnahme muss ich Ihn
> demonstrieren, dass ich könnte.... In der DTU glaub ich gehts nicht,
> aber im Datenblatt ist was erwähnt, dass es gehen sollte.

Einstellen solltest du da als Anwender auch nichts, vor allem nicht, 
wenn du nicht weißt, was du tust.
In der DTU geht das nicht manuell, wie gesagt, es ist ein Automatismus, 
der da greift.

> Ich will die anmelden, es gibts zwar blos 6 cent aber besser als den
> Strom zu verschenken. Und ich brach weil alles so verwinkelt und
> verschattet ist 6 MPPT Tracker. Seit über 1,5 Jahren hab ich auch schon
> 2x HM 300 im einsatz und auch beim Amateurfunk keine merklichen Probleme
> damit, das hab ich mit meinen Nachbarn und SMA Wechselrichter schon.

Zuviel Input :)
Mach ruhig, gerade mit der neuen Einspeisevergütung gibts da ja mehr.
Amateurfunk, anderes Thema, nicht in diesem Thread. Oberwellen und 
Netzrückwirkungen gehen hier auch ein Stück zu weit in die falsche 
Richtung, da kommt maximal die Info: siehe Zertifikate und 
Laborberichte.

lg

[Joni N. (hal_9000)]

Nachdem ich jetzt tagelang herumgelötet habe, alles doppelt und dreifach 
überprüft hab - und trotzdem nichts ging sind heute die bestellten 
Transceiver Module angekommen. Und damit klappte es auf Anhieb!

Ich hab diese hier bestellt: https://www.amazon.de/gp/product/B07VQ838KT

Tausend Dank an die Entwickler für dieses tolle Projekt.

[Frank K. (Gast)]

Tobias:
Das funktionsfähige Teil habe ich bei MAKERSHOP.DE bestellt, 
Artikelbezeichnung "2x NRF24L01+ 2.4GHz Funkmodul Raspberry Pi Arduino 
Modul nrf2401 Antenne".

[Dirk (Gast)]

Hallo zusammen, erst mal vielen Dank für die super Leistung !!! Hab 
meinen ESP mit Empfänger verlötet und alles funktioniert ... Mir ist nur 
aufgefallen das der MQQT in der aktuellen Version 0.4.25 nur beim 
Neustart verbunden wird. Wenn Wlan kurz weg ist oder der MQQT Server 
nicht erreichbar ist ( weil er eine Datensicherung nachts macht ) wird 
keine Verbindung mehr hergestellt. Erst nach einem Neustart geht es 
wieder.

[Holger S. (skusi)]

Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24 besser?

[Chris (Gast)]

Holger S. schrieb:
> Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24
> besser?


Nein, ist bei mir auch bei der .24 so gewesen. Eine gute Version mit 
stabilerem MQTT war bei mir die 0.4.5

[esafreak (Gast)]

Hallo in die Runde. Ich habe ein Problem und zwar ich bekomme auf meinem 
D1 mini von berrybase, nichts hochgeladen, weder mit der Arduino IDE 
noch mit Visual Studio Code und der Platform.io.

Mein Setup ist wie folgt:
1x D1 Mini von berrybase.de 
https://www.berrybase.de/d1-mini-esp8266-entwicklungsboard per USB Kabel 
am Laptop.

Auf dem Board ist ja so ein USB to Serial Converter CH340 drauf verbaut. 
Der Treiber wird erkannt und setzt das Board auf COM6. Soweit so gut.

Aber wenn ich mit dem VSC oder der Arduino IDE versuche zu D1 Mini zu 
connecten bricht der Uploade immer mit Fehlermeldung ab.

Hat jemand von euch das Setup so am laufen mit dem CH340 USB to Serial 
Converter oder flasht ihr die Software über FTDI direkt verdrahtet auf 
die RX und TX Pins des ESP D1 Mini ?

Danke für Eure Tips

Gruss Esafreak

[Gerri (Gast)]

@esafreak:
Verwende doch einfach eines der Flash- Programme!

NodeMCU-PyFlasher
ESP8266Flasher
tasmotizer-1.2

Funktioniert tadellos!

Grüße
Gerri

[oxylog (Gast)]

esafreak schrieb:
> Hat jemand von euch das Setup so am laufen mit dem CH340 USB to Serial

Ich habe das Setup exakt so am laufen an meinem Mac. Keine Probleme; 
Weder unter Arduino noch unter VS-Code. Unter VS-Code finde ich es sogar 
komfortabler zu flashen (als Anfänger).
Hast du schon mal ein anderes USB-Kabel verwendet?

[USB (Gast)]

Tausche das Kabel.
Da gibt es mehr Schrott als vorstellbar!
Viele sind gar nicht komplett belegt und taugen maximal zum Laden.

[Friedhelm E. (fritsche)]

Hallo Hubi.
Aus den vielen Beiträgen habe ich die SW hoydtusim aus Deiner Schmiede 
gewählt und finde die gut.
Frage: Wird deine SW auch um die Einstellung der Leistungsbegrenzung 
bzw. Nulleinspeisung mit Smartmeter erweitert oder hast Du dies vor?
einen schönen Sonntag.
Fritsche

[Mr.James (Gast)]

Hallo zusammen,
Nach 3 Tagen intensiver Forschung hab ich den Datenlogger soweit gebaut. 
Firmware ist drauf, im WLAN sind wir auch, nur kann ich meine HMT-1800 
nicht verbinden mit der Seriennummer.

Kann es sein, dass HMT-1800 nicht unterstützt wird bei der aktuellen 
Diskussion?

Danke und VG
James

[Daniel M. (daniel_m821)]

Mr.James schrieb:
> Hallo zusammen,
> Nach 3 Tagen intensiver Forschung hab ich den Datenlogger soweit gebaut.
> Firmware ist drauf, im WLAN sind wir auch, nur kann ich meine HMT-1800
> nicht verbinden mit der Seriennummer.
>
> Kann es sein, dass HMT-1800 nicht unterstützt wird bei der aktuellen
> Diskussion?
>
> Danke und VG
> James

Hallo James,

der HMT wird nicht unterstützt, da dieser ein anderes Funkprotokoll und 
einen andere Frequenzbereich verwendet.

lg

[Marius (Gast)]

Hallo zusammen,

ich verfolge dieses Thema schon seit langen. Ich finde es echt cool wie 
das ganze hier sich entwickelt hat. Super Arbeit.

Eine Frage hätte ich noch: wird es eventuell irgend wann eine 
Unterstützung für den HM-1800 (3 Phasig) geben ?

Mit dem HM-800 läuft das ganze einwandfrei.

Vielen Dank nochmal

[IsnoAhoy (Gast)]

Hallo Marius,
so ein bisschen kann ich AVR Herbi schon verstehen wenn man nicht mal 
die letzten zwei Posts liest.
Und nein HMT/HMS Wechselrichter sind nicht das Thema dieses Threads da 
es sich um komplett andere Gunktechnik handelt. Wenn Du die Funktechnik 
nachgebaut hast kannst Du Dich gerne im Source Code der DTU-Pro umsehen 
da steht auch einiges zum Regeln von drei Phasen drin aber die 
Ansteuerung von Deinem Wechselrichter wird über den von Hoymiles und uns 
verwendeten nRF24L01+ nicht funktionieren da die Frequenz und das 
Funkverfahren zwei ganz andere sind.

[Sven H. (sven_h846)]

Hallo zusammen,

könnte mir bitte jemand den Discord Link zukommen lassen

Danke

Sven

[Esafreak (Gast)]

Hallo zusammen,
Danke schon mal für eure Antworten. Habe es auf 2 Windows Rechnern 
probiert mit 3 verschiedenen USB Kabeln :-(

Eine Frage noch. Muss man am wemos D1 Mini vor dem flashen immer den 
GPIO 0 auf Low legen oder etwas anderes beachten damit das wemos Board 
geflasht wird? Davon hab ich bisher nirgends etwas gelesen dass man am 
wemos d1 mini Board aktiv einen Pin jedesmal vor dem flashen high oder 
Low schalten muss. Kann das mein Problem sein dass der wemos d1 mini nie 
in den Flash Modus geht oder ist das eigentlich nicht notwendig Pins auf 
der Platine händisch auf high oder Low zu legen? Danke für euer 
Feedback. Gruss esa

[Daniel M. (daniel_m821)]

Sven H. schrieb:
> Hallo zusammen,
>
> könnte mir bitte jemand den Discord Link zukommen lassen
>
> Danke
>
> Sven

Findest du hier:
https://discord.gg/mddnTPwu

lg

[Günter H. (gnter_h534)]

@ Esafreak

Beim Wemos D1 Mini müssen keine Pins auf bestimmte Potentiale gelegt 
werden, das geschieht durch die Beschaltung auf dem Board.

[Hubi (Gast)]

Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Friedhelm,
da ich keine DTU und sniffen kann bin ich auf die Erkenntnisse von 
anderen in diesem Thread angewiesen. Aber, ja, ich habe das gefragte 
vor, aber eher n Richtung volle Ausnutzung meiner Panele.

[esafreak (Gast)]

Hi zusammen, jetzt hat es endlich geklappt mit dem flashen. das esp 
board hatte einen Schuss weg. habe noch ein anderes originalverpackt 
liegen gehabt, und das liess sich dann mit platform.io flashen.

jetzt hab ich aber das nächste folgende problem. der esp macht ein wlan 
auf mit dem namen ahoy-dtu und nach eingabe des wlan passworts für 
ahoy-dtu connected mein laptop auch kurz aufs wlan des Esp. allerdings 
werde ich nicht automatisch zu den configuration seiten weitergeleitet 
sondern das wlan des esp ist mal da, mal weg, mal da mal weg. die IP des 
esp lässt sich pingen, aber es werden nicht die configurationsseiten 
geladen. Hat jemand eine Idee von euch, woran das liegen könnte, dass 
die configuration seiten des ESP nicht geladen werden, nachdem ich auf 
das ahoy-dtu WLAN connected habe. ? Wie gesagt, es ist auch nicht 
ständig da sondern das ahoy-dtu kommt und geht.

danke schon mal für eure kommentare.

gruss esafreak

[Holger S. (skusi)]

Hast Du mal nen Browser aufgemacht und die IP des Wemos eingegeben ?
Also 192.168.1.1

[PeterL (Gast)]

Hallo Zusammen,
mein Passwort fpr das AHOY-DTU WLAN wird nicht akzeptiert. Könnt Ihr das 
Start PW bitte noch mal posten?
Vielen Dank

[Volker.B. (Gast)]

PeterL schrieb:
> Start PW bitte noch mal posten?

esp_8266

[PeterL (Gast)]

Das war aber schnell, vielen Dank!!!

[83775 (Gast)]

Hallo zusammen, hab ständig die Meldung MQQT : not connected. Nach 
Neustart funktioniert es kurz dann wieder der Fehler. Ich verwende die 
Version 0.4.25 auf einem ESP. GUI funktioniert alles. Jemand ne Idee zur 
Lösung ? Besten Dank schon mal ... :-)

[Esafreak (Gast)]

Axel H. schrieb:
> SM D. schrieb:
>
>> Hallo,
>> ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der
>> wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später
>> ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass
>> das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite
>> die dann aber kurz später nicht mehr erreichbar ist.
>> Hat jemand eine Idee was das sein könnte?
>
> Es könnte Reboots wegen zu schwacher Stromversorgung sein. Was sagt das
> serielle Log?

Genau das gleiche Problem bei mir. Stromversorgung ist stabiles 
raspberry Netzteil
Hat sich das Problem bei euch schon gelöst und wenn ja wie?
Gruss esafreak

[Daniel R. (daniel92)]

Hallo zusammen,

wir sind bald fertig. Natührlich muss viel noch überarbeitet werden.
Aktuell haben wir ein kleines Problem das später das ganze 
Python-Scrippt imemr wieder zum crashen bringt.

File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack
    return struct.unpack(fmt, self.response[base:base+size])
struct.error: unpack requires a buffer of 2 bytes


Wenn jemand eine Idee hat, sagt bescheid.

PS: Ja Google ist mein aller aller ... bester Freund. ;)

[Gerald R. (visitor)]

83775 schrieb:
>Jemand ne Idee zur Lösung ? Besten Dank schon mal ... :-)

Ich hatte mit Ahoy ähnliche Probleme als ich noch mit Arduino geflasht 
habe.
Es werden ja Partitionen definiert, wenn das nicht stimmt können 
seltsame Dinge passieren.

Ich würde vorschlagen vor dem flashen alles zu löschen.
Kann man in Arduino einstellen, ich denke das geht in Plattform IO 
bestimmt auch.

Habs gefunden, siehe Anhang.

[SM D. (bandit7311)]

Esafreak schrieb:
>
> Genau das gleiche Problem bei mir. Stromversorgung ist stabiles
> raspberry Netzteil
> Hat sich das Problem bei euch schon gelöst und wenn ja wie?
> Gruss esafreak

Also,

das Problem kam bei mir von einer schlechten USB Buchse auf dem ESP32 
Board, die ging mal und mal ging sie nicht, zumindest nicht 
ausreichend(Übergangswiderstand).

Das gleiche könnte natürlich auch ein Problem des USB Kabels sein.

Solong
B

[Petra R. (petra-kathi)]

Hallo Daniel,

> Aktuell haben wir ein kleines Problem das später das ganze
> Python-Scrippt imemr wieder zum crashen bringt.
>
> File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack
>     return struct.unpack(fmt, self.response[base:base+size])
> struct.error: unpack requires a buffer of 2 bytes
>
>
> Wenn jemand eine Idee hat, sagt bescheid.

Wenn das nur sporadisch auftritt (gelegentliches, vorüber gehendes 
Empfangsproblem?), wäre meine Methode per Python, das mittels eines 
try:/except:-Konstrukts abzufangen und erst mal nicht weiter drüber 
nachzudenken, bis andere wichtigere Sachen organisiert sind.

Bei grundsätzlich unsicheren Datensituationen ist so was wahrscheinlich 
sogar die einzige solide Lösung, da raus zu kommen.

Tschüssi,
Petra

[Esafreak (Gast)]

Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. Tolles 
Projekt!! Gruss esafreak

[K. J. (k_j)]

Hallo. Ich habe eine Frage zum HM-400 WR

Ich nutzte die Arduino IDE mit der HoyDtuSim.ino.
Hardware: WEMOS D1 Mini + 1x NRF24L01+ verkabelt nach der Anleitung von 
github.

Im Seriellen Monitor sehe ich, dass sich der Wemos mit dem Wifi 
verbindet.
Ich komme auch per Browser rauf.

Es gibt in diesem Sketch keine Möglichkeit den 400er WR auszuwählen. Ich 
sehe hier nur den 600er und 1200er?

Ist das korrekt? Kann ich die "Vorlage" für den 600er lassen?
Meine Seriennummer lautet: 112173109786
(Kann gern in die Tabelle mit übernommen werden)

Wird diese in genau dieser Form unter
#define DUMMY_RADIO_ID eingetragen? Oder muss das 0x am Anfang und das 
ULL am Ende bleiben?

[Gerri (Gast)]

Esafreak schrieb:
> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle.

... und woran hatte es dann gelegen?

Grüße
Gerri

[Bert 0. (maschinist)]

Daniel R. schrieb:

> File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack
>     return struct.unpack(fmt, self.response[base:base+size])
> struct.error: unpack requires a buffer of 2 bytes

try:-except: drumrum bauen und im Fehlerfall fmt und self.response bzw. 
deren len anzeigen lassen!


Gruß... Bert

[Stevedee78 (Gast)]

K. J. schrieb:
> Hallo. Ich habe eine Frage zum HM-400 WR
> Ich nutzte die Arduino IDE mit der HoyDtuSim.ino.
> Hardware: WEMOS D1 Mini + 1x NRF24L01+ verkabelt nach der Anleitung von
> github.
> Im Seriellen Monitor sehe ich, dass sich der Wemos mit dem Wifi
> verbindet.
> Ich komme auch per Browser rauf.
> Es gibt in diesem Sketch keine Möglichkeit den 400er WR auszuwählen. Ich
> sehe hier nur den 600er und 1200er?
> Ist das korrekt? Kann ich die "Vorlage" für den 600er lassen?
> Meine Seriennummer lautet: 112173109786
> (Kann gern in die Tabelle mit übernommen werden)
> Wird diese in genau dieser Form unter
> #define DUMMY_RADIO_ID eingetragen? Oder muss das 0x am Anfang und das
> ULL am Ende bleiben?

0x und ULL verbleiben so.

[K. J. (k_j)]

Noch eine Frage.

Ich erhalte folgende Fehlermeldung:

'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not 
declared in this scope

    out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";

Man kann das auskommentieren dann wird der Sketch hochgeladen.
Aber wieso taucht der Fehler auf. Bzw wie kann ich das beheben?

[Esafreak (Gast)]

Gerri schrieb:
> Esafreak schrieb:
>
>> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle.
>
> ... und woran hatte es dann gelegen?
> Grüße
> Gerri

Hi Gerri, ich hatte verschiedene Probleme gleichzeitig. Am Anfang war 
der esp defekt und liess sich nicht flashen.Als ich dann einen andern 
genommen hatte ging es.dann hatte ich Probleme die config Seiten 
aufzurufen weil der access point immer nach paar Sekunden weg war und 
nicht auf die settings Seite weitergeleitet wurde. Nach ewigem 
rumprobieren war der esp dann im WLAN angemeldet und der Webserver hat 
die seiten zuverlässig angezeigt und ich konnte den hoymiles WR 
konfigurieren. Allerdings hat das funkmodul nicht mit dem WR 
kommuniziert. Ich musste dann noch zwei GPIOS am Esp umlöten und in den 
settings umkonfigurieren und dann lief das ganze. Schönes Projekt. Viele 
Grüße esafreak

[USB (Gast)]

Esafreak schrieb:
> Gerri schrieb:
>> Esafreak schrieb:
>>
>>> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle.
>>
>> ... und woran hatte es dann gelegen?
>> Grüße
>> Gerri
>
> Hi Gerri, ich hatte verschiedene Probleme gleichzeitig. Am Anfang war
> der esp defekt und liess sich nicht flashen.Als ich dann einen andern
> genommen hatte ging es.dann hatte ich Probleme die config Seiten
> aufzurufen weil der access point immer nach paar Sekunden weg war und
> nicht auf die settings Seite weitergeleitet wurde. Nach ewigem
> rumprobieren war der esp dann im WLAN angemeldet und der Webserver hat
> die seiten zuverlässig angezeigt und ich konnte den hoymiles WR
> konfigurieren. Allerdings hat das funkmodul nicht mit dem WR
> kommuniziert. Ich musste dann noch zwei GPIOS am Esp umlöten und in den
> settings umkonfigurieren und dann lief das ganze. Schönes Projekt. Viele
> Grüße esafreak


Was für ein wirres Geschwurbel, völlig sinnbefreit und nutzlos.
Bitte versuche es nochmal und etwas strukturiert.

[Tobias G. (tobias_g841)]

So, alles zusammengelötet, lief auf Anhieb! Danke an alle 
Verantwortlichen, die dieses Projekt vorantreiben!

Ich habe 4 Fragen:
1. Der ESP8266 hat eine Antenne (geschlängelte Kupferbahn auf der 
Platine) und der NRF24 hat ebenfalls eine Antenne (geschraubt).
Welche wird nun benutzt und ist genau wofür?
Wenn beide benutzt werden, ist dann ein mögl großer Abstand zwischen 
beiden sinnvoll? geht ja nur um cm, aber man könnte es ja einrichten.

2. Wenn ich den "Amplifier Power Level" von MIN auf irgendwas anderes 
(HIGH, MAX..) stelle, verliere ich die Verbindung zu den beiden HM-1500.
Hat jemand eine Vermutung, woran es liegen könnte?

3. MQTT - was genau muss ich tun, damit ich alles im Home Assistant 
sehen kann?
Muss ich die komplette MQTT-Broker Integration hinzufügen oder reicht 
auch irgend ein kleines Adaptertool?

4. AHOY vs Open DTU
Konkurrenz? Was ist besser? Haben beide die gleichen Funktionen?

Viele Grüße
Tobias

[Daniel R. (daniel92)]

Tobias G. schrieb:
> Ich habe 4 Fragen:
> 1. Der ESP8266 hat eine Antenne (geschlängelte Kupferbahn auf der
> Platine) und der NRF24 hat ebenfalls eine Antenne (geschraubt).
> Welche wird nun benutzt und ist genau wofür?
> Wenn beide benutzt werden, ist dann ein mögl großer Abstand zwischen
> beiden sinnvoll? geht ja nur um cm, aber man könnte es ja einrichten.

Die eine auf dem ESP ist für die WLAN Verbindung zum Router. Darauf 
finden die normalen Datensignal austausch statt (Webinterface,...).

Auf dem NRF24 funkt zwar auch auf 2.4GHz, aber hat ein komplett anderen 
Protokoll aufbau (die Datenpakette sind nicht gleich wie die vom TCP).

Da hier beide auf den gleicheren "Grundfrequenz" senden/empfangen, 
jedoch eine leichte Verschiebung aufweisen (kommt vom Kanal). Kann es ab 
und zu dazu kommen, das gewisse Daten nicht korrekt übertragen wurden. - 
Man kann es nicht ausschließen. Wenn man diese so Positioniert das beide 
Antennen in die jeweilige Richtung zeigen, sollte es ausreichen. ;)

> 2. Wenn ich den "Amplifier Power Level" von MIN auf irgendwas anderes
> (HIGH, MAX..) stelle, verliere ich die Verbindung zu den beiden HM-1500.
> Hat jemand eine Vermutung, woran es liegen könnte?

Kann mehrere Gründe haben, je lauter so ein Ding schreit, umso mehr 
stört man andere Kommunikation. Oder das Modul stört sich selbst 
(Mutmassung)?

> 3. MQTT - was genau muss ich tun, damit ich alles im Home Assistant
> sehen kann?
> Muss ich die komplette MQTT-Broker Integration hinzufügen oder reicht
> auch irgend ein kleines Adaptertool?

Das kann jeder selbst entscheiden. Ich nutze es direkt am Raspberry Pi 
und MQTT. Darauf läuft gleichzeit auch mein HomeAssistant (aber noch 
nicht eingebunden).

> 4. AHOY vs Open DTU
> Konkurrenz? Was ist besser? Haben beide die gleichen Funktionen?

Das ist Geschmackssache. Beides hat Vor/Nachteile.
OpenDTU nutzt hier nur ein ESP.
Ahoy, nutzt ESP und Raspberry Pi (in Python -> nutze ich, somit habe ich 
kein weiteren Client im Netzwerk).

[Hubi (Gast)]

K. J. schrieb:
> 'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not
> declared in this scope

Ich habe mir die Source neu runtergeladen und habe keinen Fehler. Da 
musst du eine ältere Version haben.

K. J. schrieb:
> Kann ich die "Vorlage" für den 600er lassen?
> Meine Seriennummer lautet: 112173109786

Nein, denn HM400 haben 1 Kanal, HM600 2 Kanäle. Somit ist die 
Kommunikation bzw Auswertung der Telegramme unterschiedlich.
Ich werde versuchen noch heute die Tabelle für den HM400 (gilt auch für 
300 und 350) zur Verfügung zu stellen.

[Hubi (Gast)]

@K.J.
Die Tabelle für HM400 (HM300, HM350) ist jetzt in HoyDtuSim.
Da ich es nicht testen kann, bitte Probleme in meinem Github melden.

[Daniel M. (daniel_m821)]

Hubi schrieb:
> K. J. schrieb:
>> 'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not
>> declared in this scope
>
> Ich habe mir die Source neu runtergeladen und habe keinen Fehler. Da
> musst du eine ältere Version haben.
>
> K. J. schrieb:
>> Kann ich die "Vorlage" für den 600er lassen?
>> Meine Seriennummer lautet: 112173109786
>
> Nein, denn HM400 haben 1 Kanal, HM600 2 Kanäle. Somit ist die
> Kommunikation bzw Auswertung der Telegramme unterschiedlich.
> Ich werde versuchen noch heute die Tabelle für den HM400 (gilt auch für
> 300 und 350) zur Verfügung zu stellen.

Das Problem wurde zwischenzeitlich gelöst auf Discord.
Verwendet wurde die Ur-Version, jetzt läuft die AHOY in der aktuellen 
Version und das zuverlässig auf dem D1 mini.

Danke trotzdem für die Meldung Hubi :)

lg

[DerJens (Gast)]

Hallo Hubi, vielen Dank für die neue Version.

Mit einem HM-300 passen noch nicht alle Werte - siehe angehängter 
Screenshot.

Leider stirbt recht schnell das Webinterface weg, die Debugausgabe via 
USB/Seriel-Monitor läuft dann weiter bis irgendwann ein Stracktrace 
kommt und neu gestartet wird.

Mein Setup: Wemos D1 mini vom Makershop mit nRF24L01+.

[PeterL (Gast)]

Hallo Zusammen,

keine Frage und kein Problem ;-)
Ich wollte Eu nur ein kurzes Feedback geben.

Habe einen Hoymiles HM800 mit 2 Pannels. Ich hatte zuerst 
Schwierigkeiten selbst zu kompilieren. Nachdem ich das .bin File 
entdeckt hatte war alles innerhalb von Minuten erledigt.
Ein riesen großes Lob an alles hier beteiligten. Eure Arbeit ist 
sensationell. Alles läuft jetzt bei mir seid 2 Tagen perfekt. Nicht nur 
die Kommunikation mit dem Wechselrichter ist problemlos, auch die 
Übertragung an meinen ioBroker per MQTT. Hier wurden alle Datenpunkte 
perfekt angelegt.
Ich bin so was von begeistert.
Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das 
.bin File veröffentlichen.

Vielen Dank uns weiter so.....

[PeterL (Gast)]

Hallo Zusammen,

keine Frage und kein Problem ;-)
Ich wollte Eu nur ein kurzes Feedback geben.

Habe einen Hoymiles HM800 mit 2 Pannels. Ich hatte zuerst 
Schwierigkeiten selbst zu kompilieren. Nachdem ich das .bin File 
entdeckt hatte war alles innerhalb von Minuten erledigt.
Ein riesen großes Lob an alles hier beteiligten. Eure Arbeit ist 
sensationell. Alles läuft jetzt bei mir seid 2 Tagen perfekt. Nicht nur 
die Kommunikation mit dem Wechselrichter ist problemlos, auch die 
Übertragung an meinen ioBroker per MQTT. Hier wurden alle Datenpunkte 
perfekt angelegt.
Ich bin so was von begeistert.
Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das 
.bin File veröffentlichen.

Vielen Dank und weiter so.....

[Eike (Gast)]

Hi Leute,
ich habe jetzt alles hin bekommen was das Flashen usw. angeht. Jetzt 
suche ich die Seriennummer von meinem Hoymiles 1500
Wenn ich die 11617.... eingebe sagt er mir immer das der Wert nicht 
stimmt.

Ich habe aber keinen anderen Aufkleber auf meinem Wechselrichter.

Könnt ihr helfen ? (Bild hängt dran)




Hostname  OpenDTU-%06X
SDK Version  v4.4.1-1-gb8050b365e
Firmware Version  0.1.18
Git Hash  725d482
Reset Reason CPU 0  Vbat power on reset
Reset Reason CPU 1  for APP CPU, reseted by PRO CPU
Config save count  4
Uptime  0 days 00:54:12

[Eike (Gast)]

habs eben immer unter DTU Settings eingetragen.....ich Dussel....Was 
muss ich bei DTU settings eintragen ?

Einmal Hilfe hierzu bitte

[Günter H. (gnter_h534)]

PeterL schrieb:
> Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das
> .bin File veröffentlichen.

Die .bin-Files sind jetzt schon unter

https://github.com/grindylow/ahoy bzw.

https://github.com/tbnobody/OpenDTU

jeweils unter dem Menüpunkt "Actions" chronologisch aufgelistet.

Zum Herunterladen muss man bei GitHub angemeldet sein.

[Eike (Gast)]

kleine Frage hätte ich noch.
Kann das den Wechselrichter auch ohne Module testen ? oder kommt dann 
nix?
Ich war mal so frei und habe ihn eben so angeschlossen ohne alles und es 
hat keine Lampe oder der gleichen geleuchtet. Auch kam im OpenDTU nix an 
:(


Danke

Eike

[Günter H. (gnter_h534)]

Die Wechselrichter arbeiten nur, wenn sie mit Gleichspannung versorgt 
werden.

Auch mit angeschlossenen Modulen sind sie nach Einbruch der Dunkelheit 
nicht mehr erreichbar.

Im Blog gibt es Hinweise, dass man die Module zu Testzwecken durch ein 
geeignetes Labornetzteil ersetzen kann.

[Eike (Gast)]

ahhhhh danke das erklärt einiges....na dann baue ich den Mist mal 
zusammen und die Tage aufs Carport.


eike

[Herbert K. (avr-herbi)]

@github Programmierer

Hubi, Daniel(s), ....  betrifft im Prinzip alle Sourcen ESP8266, ESP32, 
Raspi, phyton

Heute und auch die letzten Tage sind extrem viele Fragen zu div. Dingen 
gekommen.

S/N eintragen, muss das "ULL" stehen bleiben (im Source) ? Format 
Beispiel direkt im Souce als Kommentar z.B.

Wo und wie kommt man direkt ohne Entwicklungsumgebung an die .bin ?

Wo liegen die verschiedenen Versionen der .bin´s ?

Muß es ein nrf24L01+ sein oder funktioniert auch ein nrf24L01 (ohne 
Plus) ?

Werden hoymiles HMT und HMS auch unterstützt ?

Wird DTU-Pro-S auch unterstützt ?

Wird Modbus für Zähler auch unterstützt ?

Stabile Stromversorgung ...

Ich habe mehr als 3 hoymiles HM-..., wird das auch Unterstützt ?
(muss im Source geändert werden - ich weiss - aber neue Nutzer eher 
nicht)

Antwortet der HM-.... auch ohne angeschlossene PV Module bzw. Nachts ?

Reicht ein ESP8266 mit 1MB oder muss es unbedingt ein ESP8266 mit 4MB 
sein ?

...

Vielleicht könnt Ihr Bitte mal so die letzten Beiträge durchgehen und 
einiges als FAQs mit aufnehmen in der Hoffnung, das es nicht täglich neu 
gefragt wird ?

Das könnte vielleicht auch jemand machen, der aktuell nicht mit 
entwickelt, aber sich gut mit github auskennt ?
Vielleicht auch 1 Dokument für alle Sourcen zusammen - denn einiges wäre
ja Allgemeingültig ?

Nur so als Anregung.

[Sylvester D. (sylvester_d)]

Hallo Leute,
Klasse Projekt und Zusammenarbeit, Hut ab.
Aber auch ich hänge leider etwas und habe noch keinen 100% Erfolg. Hab 
es mit einem MINI D1 ESP32 und einem NRF24L01+ aufgebaut. Weboberfläche 
läuft alles. Allerdings bekomme ich keine Verbindung zum HM-600 und 
somit auch keine Daten. Es werden nur Nullwerte angezeigt. Nun habe ich 
bisher testweise nur ein Panel und keine zwei angeschlossen. Kann das 
vielleicht daran liegen? WR Adresse habe ich komplett (alle Stellen) 
unter Inverter eingegben. Das ganze lief jetzt 2 Tage und das eine 
angeschlossene Panel hat tagsüber auch Strom geliefert, aber wie gesagt 
keine Verbindung. Ich frage mich was ich da noch falsch mache.

PS: Ein Problem das ich vorher noch hatte ist dass ich nicht die 
Typbezeichnung des WR unter dem Menüpunkt Inverter eingegeben hatte 
sondern einen "freien" anderen Text. Danach verabschiedet sich der ESP32 
in einer Dauerbootloop und ist nur mit einem erease_flash wieder zu 
retten. (Ich hatte das mit esptool erledigt aber da geht nur eine 
Version > 3.0, ansonsten erscheint die Fehlermeldung "kann ROM nicht 
löschen", leider ist unter Ubuntu noch eine ältere Version esptool 
gebündelt.) Habe heute erst hier im Text gelesen dass das erase_flash 
auch direkt aus PlatformIO heraus gehen soll.
Bin mit PlatformIO noch nicht so richtig vertraut. Ein Hinweis hierzu 
(falschen Textstring bei Inverter) könnte anderen vielleicht diesen 
falschen Weg ersparen.

Sylvester

[Günter H. (gnter_h534)]

Sylvester D. schrieb:
> Allerdings bekomme ich keine Verbindung zum HM-600 und
> somit auch keine Daten. Es werden nur Nullwerte angezeigt. Nun habe ich
> bisher testweise nur ein Panel und keine zwei angeschlossen. Kann das
> vielleicht daran liegen?

Ich betreibe einen HM-600 z. Z. mit einem Modul und erhalte plausible 
Werte. Die Anschlüsse für das zweite Modul am Wechselrichter sind offen. 
Es ist für die Funktion unerheblich, welches Paar von Modulanschlüssen 
am Wechselrichter benutzt wird.

Ich würde einen Defekt des nRF24L01+ nicht ausschließen.

[Hubi (Gast)]

DerJens schrieb:
> Mit einem HM-300 passen noch nicht alle Werte - siehe angehängter
> Screenshot.

Geänderte Tabelle ist in meinem Repo.
Bei mir läuft das Webinterface schon seit Wochen durch. Versuch mal mit 
dem Stacktrace und dem Tool "ESP Exception Decoder" die Stelle zu finden 
wo's crashed. Wie man das macht ist hier im Thread irgendwo zu finden 
bzw auch im Netz beschrieben.

[DerJens (Gast)]

Hallo Hubi,
ich bekomme im Log 82er Meldungen, die sehen so aus:

   12   14   16   18   20   22
   Hz   P_AC ?    I_AC ?    TEMP
82 138A 0121 0000 000C 03E8 011E 0006 11A2 E35F 95 // Beispiel 1
82 1387 0108 0000 000B 03E8 0119 0006 B62A E8ED E6 // Beispiel 2

Demnach müsste die Tabelle für P_AC, I_AC, Hz und Temp so aussehen:

{ IDX_PAC,    CH0, UNIT_W,  CMD82, 14, BYTES2, DIV10  },
{ IDX_IPV,    CH0, UNIT_A,  CMD82, 18, BYTES2, DIV100 },
{ IDX_FREQ,   CH0, UNIT_HZ, CMD82, 12, BYTES2, DIV100 },
{ IDX_WR_TEMP,CH0, UNIT_C,  CMD82, 22, BYTES2, DIV10  }

Muss U_AC dann berechnet werden? U_AC = P_AC / I_AC?

Src: 
https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.md, 
Abschnitt CMD0x82

[Herbert K. (avr-herbi)]

DerJens schrieb:
> Hallo Hubi,
...
> Muss U_AC dann berechnet werden? U_AC = P_AC / I_AC?

U_AC muss nicht berechnet werden bei HM-3..
Es ist der letzte 16 Bit payload Wert /10 im Telegram 01 vor CRC.
(ist im übrigen seit vor dem 10.05.2022 schon bekannt)

[Rene M. (Firma: Bitte wählen) (renmo)]

Weiß jemand was das für Meldungen sind?
ID 12 und 46?

[DerJens (Gast)]

Noja, dann sollte das whl so für Hubis HoyDtuSim passen:

const measureDef_t hm400_measureDef[] = {
  { IDX_UDC,    CH1, UNIT_V,  CMD01, 14, BYTES2, DIV10  },
  { IDX_IDC,    CH1, UNIT_A,  CMD01, 16, BYTES2, DIV100 },
  { IDX_PDC,    CH1, UNIT_W,  CMD01, 18, BYTES2, DIV10  },
  { IDX_E_TAG,  CH1, UNIT_WH, CMD01, 24, BYTES2, DIV1   },
  { IDX_E_TOTAL,CH1, UNIT_KWH, CMD01, 20, BYTES4, DIV1000 },
  { IDX_UAC,    CH0, UNIT_V,  CMD01, 26, BYTES2, DIV10  },

  { IDX_IPV,    CH0, UNIT_A,  CMD82, 18, BYTES2, DIV100 },
  { IDX_PAC,    CH0, UNIT_W,  CMD82, 14, BYTES2, DIV10  },
  { IDX_FREQ,   CH0, UNIT_HZ, CMD82, 12, BYTES2, DIV100 },
  { IDX_WR_TEMP,CH0, UNIT_C,  CMD82, 22, BYTES2, DIV10  }
};

[Hubi (Gast)]

DerJens schrieb:
> Noja, dann sollte das whl so für Hubis HoyDtuSim passen:

Wenn das dann so passt, vielen Dank. Ich habe das so dann in mein Repo 
übernommen.

[DerJens (Gast)]

So passt es, siehe Screenshot :)

Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define 
MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte 
mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?!

[SM D. (bandit7311)]

Sylvester D. schrieb:
> Hallo Leute,
> Klasse Projekt und Zusammenarbeit, Hut ab.
> Aber auch ich hänge leider etwas und habe noch keinen 100% Erfolg. Hab
> es mit einem MINI D1 ESP32 und einem NRF24L01+ aufgebaut. Weboberfläche
> läuft alles. Allerdings bekomme ich keine Verbindung zum HM-600 und
> somit auch keine Daten. Es werden nur Nullwerte angezeigt.

Hallo welches NRF24L01+ Modul hast du denn, mit externer Antenne, LNA 
(Low Noise Amplifier) ?

Worauf man generell achten sollte dass der ESP mit seinem eigenen Wlan 
und der NRF24 körperlich etwas voneinander weg montiert werden, die 
Sendestufen von beiden Teilen können sich gegenseitig so taub machen, 
dass schlichtweg nichts mehr empfangen wird. Zustopfen nennt sich dass.

Ebenso sollte man auf eine gute stabile Spannungsversorgung für den 
NRF24 achten.

Die Pinbelegung muss man entweder so nutzen wie sie im Sourcecode 
verankert ist oder man muss sich eine eigene Version bauen und 
komplilieren. Hierbei muss man aufpassen dass man Pins verwendet die 
auch universell so zu nutzen sind.

Was sagt die serielle Schnittstelle, gibts da einen Protokollmitschnitt?

Viel Erfolg
Solong
B

[Eike (Gast)]

Hallo herbert,
das finde ich mega gut. gerade wenn man nicht mit dem vertraut ist was 
hier alles so passiert. ich zum beispiel habe es hinbekommen aber kann 
mit diesen zeilen null anfangen.
es wahr wohl mehr glück als alles andere das es läuft.
wie auhc immer ein howto wie man diese dinger einfach flashen kann.oder 
ein tool dazu was dies macht ohne eben 23 andere tools zu installieren 
wäre toll.


und wenn jemand das geflshed anbietet wäre ja auch so ne idee.
zumindest die amazon links zu den richtigen modulen wäre schon hilfreich 
ohne das man es wie ich dann 3 mal hin und her schicken muss weil das 
falsche kam.

die idee ist geboren und sie ist gut nun sollten es aber auch mehr leute 
nutzen können und nicht nur ne hand voll


eike

[Sylvester D. (sylvester_d)]

Vielen Dank für die Tips.

NRF24L01 +PA LNA SMA und externer Antenne.

Heute Abend hat das Teil doch plötzlich mal sporadisch mit dem HM-600 
geredet. Zwar nicht viel und benötigte auch einmal einen Retransmit. Es 
war auch das erstemal dass ich an der seriellen Schnittstelle "Interrupt 
received" gesehen hab und nicht nur nach einem TX

RX Period End
> All missing
> Nothing received, resend whole request

Also prinzipiell funtioniert es wohl. Ich hatte, zumindest mir bewusst, 
nichts geändert, nur nochmal kontrolliert ob alle Verbindungen richtig 
sind.

Nun, der NRF und der ESP32 könnten wirklich weiter auseinander sein. 
Sieht wirklich so aus als wäre die Funkverbindung bzw. insbesondere der 
Empfang nicht sonderlich stabil, oder anderweitig gestört.

Jetzt habe ich zumindest mal die Sicherheit dass die Schaltung 
funktioniert und die Konfiguration richtig ist. Ist auch schon mal viel 
Wert.

Morgen probiere ich mal einen größeren Abstand zwischen den beiden 
Modulen (ESP und NRF). Kann gut sein dass das das Problem ist.
Wenn ich rausfinde was es war lasse ich es Euch natürlich wissen.

Danke schon mal für Eure Hilfe. Es ist immer etwas schwierig wenn man 
nicht genau weiß unter welchen Bedingungen das System wie genau 
reagieren soll ob man auf dem richtigen oder einem abwegigen Pfad ist.

Sylvester

[Hubi (Gast)]

DerJens schrieb:
> Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define
> MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte
> mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?!

Sorry, aber das gibt meine SW leider noch nicht her. Ich habe leider nur 
eine Anlage auf dem Gartenhaus mit einem HM-600, das Testen mit mehreren 
WR also unmöglich. Ich sende zwar an alle "registrierten" Anlagen, aber 
die empfangenen Daten werden noch nicht korrekt zugeordnet. Da sind die 
Projekte OpenDTU und ahoy wohl etwas weiter. Wenn entsprechender Bedarf 
und auch Tester sich finden mache ich da gerne weiter.

[isnoAhoy (Gast)]

Habe mal angefangen eine FAQ zu erstellen wie von AVR Herbi gewünscht 
und von Juergen vorgeschlagen im Wiki:

Wie zu erwarten ist das ganze etwas Protokoll lastig geworden =^D

# FAQ Häufig gestellte Fragen
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

[Lukas P. (lumapu)]

Stefan, danke für das Anlegen des FAQs, das ist ja schon sehr 
umfangreich. Mir ist aufgefallen, das oft aus der ich Perspektive 
geschrieben ist. Evtl. finden sich ja Freiwillige, die hier bisschen 
formulieren helfen :-)
Finde es toll wie sich die Zusammenarbeit hier entwickelt hat.

[Herbert K. (avr-herbi)]

isnoAhoy schrieb:
> Habe mal angefangen eine FAQ zu erstellen wie von AVR Herbi gewünscht
> und von Juergen vorgeschlagen im Wiki:

> # FAQ Häufig gestellte Fragen
> https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

War ja nur ein Vorschlag :-)
Ich hoffe und würde es Allen, die hier schon länger und regelmäßig 
mitlesen wünschen, das alle Neuhinzugekommenen sich die Zeit nehmen, das 
zu lesen.

TOP Arbeit für den Anfang !  Ich sage einfach mal Danke, auch wenn es 
weniger für mich ist, sondern für Andere.

[locke987 (Gast)]

Rene M. schrieb:
> Weiß jemand was das für Meldungen sind?
> ID 12 und 46?

ID 12 hatte ich auch in Zusammenhang mit Grid Overvoltage, schaut für 
mich wie eine wieder gut Meldung nach dem Fehler aus.

[Lars (Gast)]

Kannst du mal ein Bild hochladen wie du das verdrahtet hast? Habe die 
gleiche Zusammensetzung aber die pin Belegung ist irgendwie anders an 
dem kleinen Board

[Lars (Gast)]

Kannst du mal ein Bild hochladen wie du das verdrahtet hast? Habe die 
gleiche Zusammensetzung aber die pin Belegung ist irgendwie anders an 
dem kleinen Board

Heinrich P. schrieb:
> Hallo zusammen,
> und vielen Dank für euere tolle Arbeit.
> Hab mir vor 2 Tagen bei komputer.de die Chips bestellt:
> 1 Stk.  nRF24L01+ PA SMA mit Antenne  3.20EUR
> 1 Stk.  ESP32 Development board NodeMCU kompatibel  6.50EUR
> Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens
> mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die
> beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen.
> Nach nur 6 Jahren! Gruselig…
> Grüße, Matze

[Hubi (Gast)]

DerJens schrieb:
> Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define
> MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte
> mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?!

Die SW HoyDtuSim aus meiner Repo 
[[https://github.com/hm-soft/Hoymiles-DTU-Simulation/ ]] sollte es jetzt 
auch mit mehreren WR können. Kann das aber leider nicht testen.

[Daniel R. (daniel92)]

isnoAhoy schrieb:
> Habe mal angefangen eine FAQ

Vielen Dank, sehr gut! :)
Edit: Sorry das ich hier nicht mehr so aktiv bin (mehr Discord GitHub), 
das hat hier teils überhand genommen und wenn ich am ReverseEngeneering 
dran bin kann ich nicht gleichzeitig Support spielen. :)

https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-modelle-werden-unterst%C3%BCtzt 
- Sollen hier noch die Modelle Aufgelistet werden, damit jeder weiß 
welche Modelle Unterstützt werden? Ich glaube nähmlich das neue User 
nicht ganz sonst durchsteigen?

[Günter H. (gnter_h534)]

Sylvester D. schrieb:
> Nun, der NRF und der ESP32 könnten wirklich weiter auseinander sein.
> Sieht wirklich so aus als wäre die Funkverbindung bzw. insbesondere der
> Empfang nicht sonderlich stabil, oder anderweitig gestört.

> Morgen probiere ich mal einen größeren Abstand zwischen den beiden
> Modulen (ESP und NRF). Kann gut sein dass das das Problem ist.
> Wenn ich rausfinde was es war lasse ich es Euch natürlich wissen.

Das Thema Abstand ESP-Board <---> nRF24L01+-Modul sollte aus meiner 
Sicht nicht überbewertet werden:

- In der Original-DTU ist der Abstand auch nicht riesig groß,
- ein realisiertes Muster von mir läuft stabil (grindylow /
ahoy, Firmware 0.4.25) und, solange der Wechselrichter aktiv ist, 
praktisch ohne "Receive fail". Auch ein nFR24L01+-Modul mit 
Print-Antenne ist problemlos einsetzbar. Die Bausteine sind gesteckt, um 
bei Bedarf verschiedene Ausführungen testen zu können, somit ist auch 
der USB-Anschluss prinzipiell zugänglich.

Leider ist die "Streubreite" der Qualität der nRF24L01+-Klone wohl sehr 
groß - siehe z. B. hier:
Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"

Bei einem früheren Aufbau war ein Stecker des Dupont-Kabels 
"ausgeleiert" und verursachte so eine Instabilität.

[Gerald R. (visitor)]

isnoAhoy schrieb:
> # FAQ Häufig gestellte Fragen
> https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

Sehr schön, Danke an alle!

Sollte jemand einen Tester für die Leistungsbegrenzung brauchen, ich und 
mein HM800 sind bereit. :-D

[Ralla66 (Gast)]

Wäre es möglich im FAQ mal mit aufzunehmen wie man ein Kommando an den 
WR sendet. Habe hier die Kombi Arduino / Esp 8266 mit NRF Plus, WR 
HM600.
Wie wird die Anfrage gesendet ? Beispiel Hterm sendet per Serial TX an 
Arduino der nach NRF ? Ist das richtig so.
Kleines Beispiel wäre nett wie man sendet.

Würde gerne mittesten da ich eine Leistungsreduzierung von Vorteil sehe
und von der Leistungsreduzierung AE Conversion nach Hoymiles wechseln 
möchte.
Wünschenswert wäre halt wie beim AE ein Request aus IoBroker an den HM 
senden zu können damit die Energie aus der Batterie gezielt abgegeben 
werden kann.

[Canon.Fritz (Gast)]

Hallo,
erst einmal ein großes Dankeschön für dieses tolle Projekt.
Ihr habt da etwas großartiges auf die Beine gestellt :)

Gerald R. schrieb:
> Sollte jemand einen Tester für die Leistungsbegrenzung brauchen, ich und
> mein HM800 sind bereit. :-D

Ich wäre mit meinem HM600 auch am Start um die Leistungsbegrenzung zu 
testen :)

[DerJens (Gast)]

Hubi schrieb:
> Die SW HoyDtuSim aus meiner Repo
> [[https://github.com/hm-soft/Hoymiles-DTU-Simulation/ ]] sollte es jetzt
> auch mit mehreren WR können. Kann das aber leider nicht testen.

Soeben ausprobiert:
Mit einem WR klappts, da bekomme ich nach jedem Send... eine Antwort.

18:32:03.082 -> Send... CH3
18:32:03.129 -> Request cmd=1
18:32:03.129 -> Send... CH23
18:32:04.160 -> rcv CH:40 00 1234567801 ...
18:32:04.160 -> rcv CH:61 00 1234567801 ...
18:32:06.930 -> Send... CH40
18:32:07.024 -> rcv CH:75 00 1234567801 ...
18:32:07.024 -> rcv CH:61 00 1234567801 ...
18:32:16.923 -> Send... CH61
18:32:17.016 -> rcv CH:23 00 1234567801 ...
18:32:17.016 -> rcv CH:3 00 1234567801 ...
18:32:26.958 -> Send... CH75

Mit 3 WR kommt sehr lange erstmal nicht.

18:36:50.507 -> Send... CH3
18:36:50.553 -> Send... CH23
18:36:50.599 -> Send... CH40
18:36:53.407 -> Send... CH61
18:36:56.406 -> Send... CH75
18:36:59.396 -> Send... CH3
18:37:02.392 -> Send... CH23
18:37:05.395 -> Send... CH40
18:37:08.413 -> Send... CH61
18:37:11.415 -> Send... CH75
18:37:14.400 -> Send... CH3
18:37:17.377 -> Send... CH23
18:37:20.386 -> Send... CH40
18:37:23.397 -> Send... CH61
18:37:26.398 -> Send... CH75
18:37:29.413 -> Send... CH3
18:37:32.399 -> Send... CH23
18:37:35.385 -> Send... CH40
18:37:38.412 -> Send... CH61
18:37:41.412 -> Send... CH75
18:37:44.387 -> Send... CH3
18:37:47.416 -> Send... CH23
18:37:50.412 -> Send... CH40
18:37:53.381 -> Send... CH61
18:37:56.423 -> Send... CH75
18:37:59.415 -> Send... CH3
18:38:02.385 -> Send... CH23
18:38:05.393 -> Send... CH40

Irgendwann kommen dann selten Antworten von allen 3 WR, dazwischen 
liegen aber zum Teil mehrere Minuten.

[locke987 (Gast)]

Canon.Fritz schrieb:
> Ich wäre mit meinem HM600 auch am Start um die Leistungsbegrenzung zu
> testen :)

Wäre mit einem HM-1500 und iobroker/mqtt auch beim Testen dabei...

[locke987 (Gast)]

Günter H. schrieb:
> ein realisiertes Muster von mir läuft stabil

Kann man das Carrier Board käuflich erwerben, und wenn ja wo? Schaut gut 
aus!
Gruß Stefan

[IsnoAhoy (Gast)]

Welche EXPERIMENTELLEN Software Funktionen sind bisher noch nicht im 
Standard enthalten (Pull Request / Merge)
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-experimentellen-software-funktionen-sind-bisher-noch-nicht-im-standard-enthalten-pull-request--merge

Power Limit via mqtt https://github.com/grindylow/ahoy/pull/109

[Tobias G. (tobias_g841)]

Für das Logbuch: Leerzeichen in der WR Bezeichnung innerhalb AHOY wird 
dadurch bestraft, dass zB keine Entitäten (über MQTT) autom. in Home 
Assistant erkannt werden.
Leerzeichen entfernt, schwupps, alles da.

[MaLa (Gast)]

Noch ein Beitrag für das Logbuch:
Die Verbindung zum NTP Zeitgeber muss möglich sein. In den fertigen 
Binaries ist "pool.ntp.org" eingetragen.
Im Code lässt sich das natürlich anpassen (z.B. auf einen lokalen 
Zeitgeber im Heimnetz), womit aber selbst compiliert werden muss.


Da ich in meiner FritzBox den Geräten der Hausautomatisierung keinen 
Zugriff auf das Internet erlaube, bin ich da leider ein paar Stunden 
hängegeblieben - nun läuft aber alles.

Super Forum, vielen Dank an alle kreativen Köpfe!!!!!

[dtuuser (Gast)]

Mein Cloud MQTT (HiveMQ) Broker verwendet TLS-Verschlüsselung auf Port 
8883, kann AhoyDTU dies unterstützen?

[Steffen D. (steffen_d)]

Hallo, die Ahoy Esp8266 Version 0.4.25 verbindet sich ja gut mit meinem 
HassIO MQTT Broker. HassIO zeigt mit auch alle Entitäten. OpenDTU mit 
einem ESp32 läuft Rauch top und verbindet sich auch mit dem MQTT Broker 
aber HassIO zeigt mir keine Entitäten oder das Gerät an. Wo liegt da der 
Hund begraben?

[Sylvester D. (sylvester_d)]

Problem gefunden

Wie bereits zuletzt berichtet lief die HW & SW bei mir zumindest einmal 
kurzzeitig am Abend. Jetzt ist mir auch klar wo das Problem lag, nachdem 
gestern Morgen das System, ohne irgendeiner weiteren Änderung und für 
mich völlig überraschend, problemlos und dann den ganzen Tag anstandslos 
lief.

Die Ursache? Die Uhrzeit zu denen ich Zeit hatte zu testen......nämlich 
entweder sehr sehr spät Abends oder früh am Morgen. Tagsüber habe ich es 
nicht laufen lassen und auch nicht mitgeloggt.
Es schien einfach zu wenig Licht auf das eine am HM-600 angeschlossenen 
Panel. Das Panel steht testweise noch am Boden an eine Südwand gelehnt. 
Sobald einige Watt Leistung auf dem Panel zusammen kommen läuft die 
Kommunikation einwandfrei. Bei 5W ganz sicher, teilweise sogar noch im 
Bereich von ~1W.

Ich hatte zwar gelesen dass die Kommunikation nur geht wenn Strom vom 
Panel erzeugt wird, deshalb ja auch die Tests am Morgen, aber das war 
einfach noch zu wenig Licht obwohl man als Mensch schon den Eindruck von 
hell, Morgendämmerung hat und farbig sieht.

Als es am Abend kurzzeitig lief, hatte ich ausnahmsweise einmal deutlich 
früher am Abend getestet.....und gestern Morgen später als sonst......

Gestern Abend war dann die letzte Meldung mit 0,7W und heute Morgen lief 
es dann wiederum problemlos.

Obwohl der HM-600 am 230V Netz angeschlossen ist, scheint er, ohne 
ausreichende Energieversorgung durch zumindest ein Panel, nicht auf den 
DTU zu antworten, was ja schon mal hier im Thread angesprochen wurde. 
Allerdings braucht es unter Umständen einfach mehr als Dämmerlicht. Ich 
hoffe diese Erfahrung hilft anderen, nicht den gleichen Fehler zu 
wiederholen.

Sylvester

[Canon.Fritz (Gast)]

Tobias G. schrieb:
> Leerzeichen in der WR Bezeichnung innerhalb AHOY wird
> dadurch bestraft, dass zB keine Entitäten (über MQTT) autom. in Home
> Assistant erkannt werden.
> Leerzeichen entfernt, schwupps, alles da.

Ich versuche das ganze in FHEM zu integrieren. Mit meinem Mosquitto MQTT 
Server hat er sich auch laut AHOY Software verbunden.

Wie muss ich das Topic denn jetzt zusammen bauen ?
Leider werde ich auch aus dieser Anleitung nicht ganz schlau :
Power Limit via mqtt https://github.com/grindylow/ahoy/pull/109

Es wäre toll wenn mir jemand anschaulich erklärt wie ich das Topic 
zusammenbauen muss :) z.b. so Device Name/Inverter_0_Name/Topic

[Daniel M. (daniel_m821)]

Canon.Fritz schrieb:

> Es wäre toll wenn mir jemand anschaulich erklärt wie ich das Topic
> zusammenbauen muss :) z.b. so Device Name/Inverter_0_Name/Topic

In den Einstellungen hast du ein Base Topic. In OpenDTU schaut es 
folgenermaßen aus:
BaseTopic/INV_Serial/Channel/Abzufragender_Wert

Beispiel: solar/116181101507/0/power
Channel 0 ist AC, Channel 1 und folgende (max. 4) sind die DC-Eingänge.

Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was 
alles kommt und wie es bei dir genau aussieht.

Für die DTU sieht es so aus:
solar/dtu/name
solar/dtu/uptime
solar/dtu/ip

[Claus T. (Gast)]

Canon.Fritz schrieb:
>
> Ich versuche das ganze in FHEM zu integrieren. Mit meinem Mosquitto MQTT
> Server hat er sich auch laut AHOY Software verbunden.
>
Ich habe das MTTQ2 Modul von FHEM definiert, also keinen extra mosquito 
installiert und der MTTQ2 hat bei mir dann automatisch ein MTTQ-Device 
mit allen readings angelegt.

[Ralla66 (Gast)]

Test über Nacht,
Kombi WemosD1 mit Ahoi 0.4.25
Morgens Spannung der Module da
Spannung sichtbar mit Sonoff Dual R3
Keine Daten empfangen, gesendet werden 6 gleiche Pakete Transmit 27 | 15
Last Frame missing
usw mit anderem Zeitstempel
Reboot keine Besserung
Wemos Stromlos
Keine Daten empfangen, gesendet werden 1 mal 6 gleiche Pakete Transmit 
27 | 15
Last Frame missing
Keine Daten empfangen, gesendet wird 1 Pakete Transmit 27 | 15 danach 
95er
Pakete unterschiedlicher Anzahl,
Last Frame missing
Pakete 27 | 15 mit 95er werden 5 mal angezeigt
Danach Daten Receive mit Transmit 11 | 15
Transmit 11 | 15
81 86 77 21 78 56 34 12 82 CE 95
81 86 77 21 81 86 77 21 02 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 
BE AF 95
81 86 77 21 81 86 77 21 02 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 
BE AF
I: Payload (42): 00 01 01 03 00 4D 00 C7 00 08 00 02 00 00 00 00 2B 16 
00 00 00 00 00 3F 00 00 09 1A 13 84 00 BE 00 00 00 08 03 E8 01 0C 04 30

Soweit der Übernachttest

[Hubi (Gast)]

DerJens schrieb:
> Soeben ausprobiert:
> Mit einem WR klappts, da bekomme ich nach jedem Send... eine
> Antwort.18:32:03.082 -> Send... CH3
> 18:32:03.129 -> Request cmd=1
> 18:32:03.129 -> Send... CH23
> 18:32:04.160 -> rcv CH:40 00 1234567801 ...
> 18:32:04.160 -> rcv CH:61 00 1234567801 ...
> 18:32:06.930 -> Send... CH40
> 18:32:07.024 -> rcv CH:75 00 1234567801 ...
> 18:32:07.024 -> rcv CH:61 00 1234567801 ...
> 18:32:16.923 -> Send... CH61
> 18:32:17.016 -> rcv CH:23 00 1234567801 ...
> 18:32:17.016 -> rcv CH:3 00 1234567801 ...
> 18:32:26.958 -> Send... CH75
>
> Mit 3 WR kommt sehr lange erstmal nicht.18:36:50.507 -> Send... CH3
> 18:36:50.553 -> Send... CH23
> 18:36:50.599 -> Send... CH40

Probier mal in der Settings.h andere Einstellungen, zB
#define PA_LEVEL    RF24_PA_MAX oder RF24_PA_HIGH.
Außerdem wird die Wartezeit (WAIT_TILL_NEXT_SEND) bis zum nächsten 
Senden auf dir WRs aufgeteilt, also bei 3 WR wird lediglich 3 Sekunden 
gewartet.
setze mal fest WAIT_TILL_NEXT_SEND=10 am Ende von setupInverters()

[oxylog (Gast)]

Günter H. schrieb:
> Das Thema Abstand ESP-Board <---> nRF24L01+-Modul sollte aus meiner
> Sicht nicht überbewertet werden:

Selbiges hier
- Läuft auf beiden Platinen fehlerfrei, auch unter 04.22
- Ebenfalls steckbar. Auch hatte ich einen Wemos D1mini-Clone, der 
fehlerhaft war.

[Joni N. (hal_9000)]

Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen. 
3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann 
einfach email mit Postanschrift an [e-mail]

Es ist dieses Fritzing File hier: 
https://github.com/tbnobody/OpenDTU/tree/master/docs

P.S:
Ich seh das ganze als "Pay It Forward" Aktion :-)

[Joni N. (hal_9000)]

Joni N. schrieb:
> Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen.
> 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann
> einfach email mit Postanschrift an [e-mail]
>
> Es ist dieses Fritzing File hier:
> https://github.com/tbnobody/OpenDTU/tree/master/docs
>
> P.S:
> Ich seh das ganze als "Pay It Forward" Aktion :-)

Ging schnell ... sind jetzt alle weg :-D

[Steffen D. (steffen_d)]

Joni N. schrieb:
> Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen.
> 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann
> einfach email mit Postanschrift an [e-mail]
>
> Es ist dieses Fritzing File hier:
> https://github.com/tbnobody/OpenDTU/tree/master/docs
>
> P.S:
> Ich seh das ganze als "Pay It Forward" Aktion :-)

Wo hast Du die machen lassen? Würde die mit deiner Erlaubnis (Datei) 
fertigen lassen.

[DerJens (Gast)]

Hubi schrieb:
> Probier mal in der Settings.h andere Einstellungen, zB
> #define PA_LEVEL    RF24_PA_MAX oder RF24_PA_HIGH.
> Außerdem wird die Wartezeit (WAIT_TILL_NEXT_SEND) bis zum nächsten
> Senden auf dir WRs aufgeteilt, also bei 3 WR wird lediglich 3 Sekunden
> gewartet.
> setze mal fest WAIT_TILL_NEXT_SEND=10 am Ende von setupInverters()

Soeben ausprobiert:
- bei PA_LEVEL auf HIGH ändert sich nichts
- bei WAIT_TILL_NEXT_SEND=10 dauert es länger bis ein Send... kommt, es 
kommt aber trotzdem nicht schneller eine Antwort. Zum Teil nur von einem 
WR, von den anderen kommen gar keine Antworten.

Ich habe mal jeden WR einzeln mit MAX_ANZ_INV 1 angesprochen, da kommt 
bei jedem innerhalb der ersten 1-2 Send... eine Antwort. Ich habe den 
Eindruck, dass mit mehreren WR die Antworten irgendwie nicht mehr 
erwischt werden...?

[Joni N. (hal_9000)]

Steffen D. schrieb:

> Wo hast Du die machen lassen? Würde die mit deiner Erlaubnis (Datei)
> fertigen lassen.

Die Datei ist ja nicht von mir, sondern von tbnobody ;-)
https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz

Fertigen habe ich sie bei JLCPCB lassen. Ging super einfach.

Hier die Anleitung wie du aus dem .fzz ein Gerber File machst:
https://support.jlcpcb.com/article/171-how-to-generate-gerber-and-drill-files-in-fritzing

[Holger F. (holger_f)]

Hallo, bin schwer beeindruckt, was ihr hier geschafft habt!

Kennt jemand folgendes Verhalten?

Es sieht aus, als würde mein HM-600 erst genau 1800 Sekunden (30 
Minuten) nach seinem Start antworten, also nachdem DC Spannung vom 
Labornetzteil am Wechselrichter-Eingang vorhanden ist.
Die ersten 30 Minuten schweigt er einfach ("All missing" im Log), danach 
antwortet er ziemlich zuverlässig ("Interrupt received" im Log).

All meine vorangegangenen Fehlversuche mit Kondensatoren, anderen 
Antennen, Abstand, anderen NRF-Modulen, ESP-Neustarts usw. hatten gar 
keinen Einfluss. Es waren schlicht die 30 Minuten Wartezeit. Das könnte 
auch die Probleme manch anderer Forenteilnehmer beim RX erklären.

Versuchsaufbau: OpenDTU auf ESP32 mit NRF24L01+, HM-600 mit 
Labornetzteil am DC-Eingang

(War da nicht auch was mit Epoch-Zeitstempeln in den Nachrichten? Nur 
mal gesponnen, vielleicht ja irgendein Schutz vor Replay-Attacken 
basierend auf Zeitstempeln?)

[Steffen D. (steffen_d)]

Joni N. schrieb:

> https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz
> Fertigen habe ich sie bei JLCPCB lassen. Ging super einfach.
> Hier die Anleitung wie du aus dem .fzz ein Gerber File machst:
> 
https://support.jlcpcb.com/article/171-how-to-generate-gerber-and-drill-files-in-fritzing

Okay wie ich sehe ist es nur die Platine mit Lötaugen für den ESP32 und 
den NRF+ ohne Leiterbahnen!?

Du kannst mir gerne auch das Gerber File zukommen lassen. Ich muss mich 
erstmal mit Fritzing und autoroute beschäftigen.

[Horst G. (horstg-57)]

Habe hier inzwischen einen WimosD1 mit Ahoi 0.4.25 in Dauerbetrieb 
laufen.
Großartige Leistung von allen die die Software bis hier vorangetrieben 
haben.

Bei mir bringt der Ahoi sehr zuverlässig seine Daten und überträgt die 
auch zuverlässig zu einem Mosquito MQTT Server, auch über den 
Tageswechsel.

Es sollte aber sichergestellt sein, das der Abstand zwischen HM ( hier 
ein HM400) und dem Aufbau nicht zu groß ist und ein mehr oder weniger 
freies Funkfeld besteht. Bei 2,4 GHz wirken sich gemauerte Wände doch 
schon erheblich    aus.

Was mir allerdings aufgefallen ist, wenn man zwei Ahoi's betreibt
( einen Produktiv und einen zur Fehlersuche des MQTT reconnect Problems 
; auch mit unterschiedlichen Device-Namen im Setup )
stören sich diese beim versenden der MQTT Daten.
Ursache ist, das beim MQTT anmelden nicht der Device-Name wie im Setup 
eingetragen genommen wird, sondern der im Source-Code voreingestellte.
Nachdem ich hier eine Erweiterung in der App.cpp und MQTT.h eingebaut 
habe, so das auch hier der Devicename aus dem Setup genommen wird, 
stören sich die beiden Ahoi's nicht mehr.

Ausserdem habe ich eine kleine Anpassung eingebaut, so das nach jeder 
erfolgreicher Datenaufbereitung, mit einer Verzögerung von 2 Sekunden, 
die neuen Daten per MQTT übertragen bekomme, indem ich den MQTT 
Intervall Zähler auf "MQTT-Intervallzeit - 2" setze.

[Hubi (Gast)]

DerJens schrieb:
> Ich habe mal jeden WR einzeln mit MAX_ANZ_INV 1 angesprochen, da kommt
> bei jedem innerhalb der ersten 1-2 Send... eine Antwort. Ich habe den
> Eindruck, dass mit mehreren WR die Antworten irgendwie nicht mehr
> erwischt werden...?

Ich konnte testweise einen 2. WR simulieren, indem ich meinen einzigen 
WR 2x lade, mit je richtigen und falschen SerialNo beim Senden und 
Empfang warten.
Und es funzt jetzt. Update ist im Repo.
@DerJens: Wenn's bei dir immer noch Probleme gibt, schreib per Mail an 
hubi.mora(at)gmail.com

[Klaus H. (klahi)]

Hallo, ich bin auf der Auswahl eines Mikrowechselrichters auf dieses 
Forum gestoßen. Ich möchte bei dem zukünftigen Modell keinem Cloud-Zwang 
unterworfen sein und die Ausgangsleistung des Wechselrichters begrenzen 
können. Das aber nur zur Einordnung.

Zu Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" : Aus Interesse 
habe ich mir das gitee-Repository zur DTU-PRO geladen. Ein Repository 
vergisst nichts :-)  Vor dem Commit mit dem Text "Document" mit der 
Commit-Kennung 2d24e2b7a261282501b44da26a5693d5033e8ba6 finden sich 
viele gelöschte Dokumente, unter anderem auch RF通讯协议-V6.6.xlsx 
(übersetzt RFprotocol-V6.6.xslx). Vielleicht finden sich dort aktuellere 
Informationen als in V6.5.
Ansonsten finden sich in den älteren Commits sehr viele gelöschte 
Verzeichnisse und Dateien. Ich forsche mal noch weiter ...
Dieses Forum und die Teilnehmer machen Lust darauf sich zu beteiligen. 
Danke für die bisher geleistete Arbeit.

[Klaus H. (klahi)]

Ergänzend: Es gibt zwei Repositories bei gitee zum gleichen Thema:
https://gitee.com/iotloves/hoymiles-DTU-PRO
https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO

Das Erstere ist jünger. Ich habe mich daraus bedient.

[guilligan71 (Gast)]

Hi, ich reihe mich ein in die vielen Danksagungen.
Ich habe mit die fertige 0.4.25 hier aus board runtergeladen. auf github 
(unter actions) finde ich Sie jedoch nicht.
Gibt es eine Möglichkeit das Abfrageintervall MQTT von 90s zu 
reduzieren, damit die Daten ein bissl aktueller sind?

VG

[Canon.Fritz (Gast)]

Daniel M. schrieb:
> Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was
> alles kommt und wie es bei dir genau aussieht.


Ich konnte die Topics mittels MQTT Explorer raussuchen.
Besten dank für den Tipp :)

Nun funktionierte auch bei mir die Integration in Fhem.

Jetzt stellt sich mir nur noch die Frage wie ich den Topic für die 
Leistungslimitierung formen muss.

Ich verwende die Ahoy 0.4.25.bin hier aus dem Forum, da mir VS Code 
immer 70 Fehler beim kompilieren rauswirft und ich mir daher keine 
eigene .bin exportieren kann ;(  Ich hoffe es geht auch schon in dieser 
Version.

[guilligan71 (Gast)]

guilligan71 schrieb:
> Hi, ich reihe mich ein in die vielen Danksagungen.
> Ich habe mit die fertige 0.4.25 hier aus board runtergeladen. auf github
> (unter actions) finde ich Sie jedoch nicht.
> Gibt es eine Möglichkeit das Abfrageintervall MQTT von 90s zu
> reduzieren, damit die Daten ein bissl aktueller sind?
>
> VG

Das geht wohl schon über die config.h. aber so tief bin ich noch nicht 
in der Materie drin. Dann warte ich wohl noch ein bissl und versuche 
mich schlau zu machen wie man selbst compilen kann. Dazu habe ich leider 
noch keine (ausführliche) Anleitung für Anfänger gefunden. Weiter so 
*daumenHOCH

[Gerald R. (visitor)]

Ich habe mich nochmal als Programmierer versucht und in die aktuelle 
Ahoy Version von grindy https://github.com/grindylow/ahoy.git die 
SD-Karte eingepflegt.
Dieses mal an - und abwählbar mit einstellbarem Intervall im setup.html.

Der CS pin für die SD kommt auf D0.

Ich würde gerne die Firmware hier zur Verfügung stellen, bin mir aber 
nicht ganz sicher welche der beiden die Richtige ist.
Selsamer Weise flasht PlatformIO meine D1 mini 2x.
zuerst /build/d1_mini/firmware.bin
sofort danach mit /build/node_mcu_v2/firmware.bin
Ich nehme an beide sind ident sonst würde ja mein D1 mini mit der 
node_mcu_v2 firmware nicht funktionieren.

[Gerald R. (visitor)]

Tja, wer lesen kann ...
Stehen ja beide in der platform.ini.

Also hier die Firmware dazu für diejenigen die sie nicht selber bauen 
können oder wollen.

[Gerald R. (visitor)]

Habe testweise mal in Ahoy MIN_MQTT_INTERVAL auf 10 gesetzt.
Könnt ihr ja testen.
Ist die Version mit SD-Karte, die muss man ja nicht nutzen.

Keine Ahnung ob das dann auch funktioniert.

[Sven K. (svenk)]

Gerald R. schrieb:
> Ich habe mich nochmal als Programmierer versucht und in die aktuelle
> Ahoy Version von grindy https://github.com/grindylow/ahoy.git die
> SD-Karte eingepflegt.
> Dieses mal an - und abwählbar mit einstellbarem Intervall im setup.html.
>
> Der CS pin für die SD kommt auf D0.
>
> Ich würde gerne die Firmware hier zur Verfügung stellen, bin mir aber
> nicht ganz sicher welche der beiden die Richtige ist.
> Selsamer Weise flasht PlatformIO meine D1 mini 2x.
> zuerst /build/d1_mini/firmware.bin
> sofort danach mit /build/node_mcu_v2/firmware.bin
> Ich nehme an beide sind ident sonst würde ja mein D1 mini mit der
> node_mcu_v2 firmware nicht funktionieren.

Hallo Gerald,
ich habe noch mal schnell das diff File überflogen:
Kann es sein das die SD Karte initialisiert wird ohne das Flag
zu prüfen ob die SD Karte ein oder ausgeschaltet ist?
Zeile mit Code

„if (!SD.begin(chipSelect)) {„

Könnte ja sein das jemand gerne
den Code übernimmt aber noch keine
SD Karte angeschlossen hat ?

Gruß Sven

[Holger S. (skusi)]

Wie ich schon auf Discord bekannt gegeben hab, sind 30 Platinen von mir 
unterwegs. Kommen wohl nächste Woche. Ich gebe die gerne für 3 € das Stk 
ab. Oder auf Wunsch auch fertige Geräte.

[Steffen D. (steffen_d)]

Holger S. schrieb:
> Wie ich schon auf Discord bekannt gegeben hab, sind 30 Platinen von mir
> unterwegs. Kommen wohl nächste Woche. Ich gebe die gerne für 3 € das Stk
> ab. Oder auf Wunsch auch fertige Geräte.

Top, sind die für den Wemos oder den Esp32?

[Gerald R. (visitor)]

Sven K. schrieb:
> Kann es sein das die SD Karte initialisiert wird ohne das Flag
> zu prüfen ob die SD Karte ein oder ausgeschaltet ist?
> Zeile mit Code
>
> „if (!SD.begin(chipSelect)) {„
>
> Könnte ja sein das jemand gerne
> den Code übernimmt aber noch keine
> SD Karte angeschlossen hat ?
>
> Gruß Sven

Hallo Sven!

Ja, das hast du richtig gesehen.
Beim jedem Start wird überprüft ob eine SD vorhanden ist.
Da könnte man noch nachbessern, danke für den Hinweis!

Hatte aber in meinen Tests ohne SD keinen negativen Einfluss und es wird 
nicht versucht zu schreiben nach dem die Meldung:
I: SD card failed, or not present
kommt.
Das habe ich mit einer LED am CS pin überprüft.

Werde das morgen nochmal probieren, denn ohne Sonne wird nichts 
geschrieben ;-)

[Tobias G. (tobias_g841)]

Hallo zusammen,
hat jemand eine Idee, was man gegen "MQTT: not connected" tun kann?
Mal läuft es bei mir einen Tag durch, dann alle 30 Minuten der 
Verbindungsabbruch. Es hilft dann nur ein Reboot.
0.4.25 ist installiert, AHOY befindet sich ca 1,5m direkt neben den 
Hoymiles.

[oxylog (Gast)]

Hallo allerseits,
ich hatte mir auch ein paar Platinen fertigen lassen.
Falls Bedarf besteht gebe ich von diesen gerne welche ab.
https://www.ebay-kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoy-dtu-esp8266/2171544569-168-9361

[Horst G. (horstg-57)]

Also bei mir läuft MQTT ansich sehr stabiel ( bei mir ein Mosquito MQTT 
Server auf Debian 11 ).  Mir ist nur mal aufgefallen, wenn der Ahoi zu 
dicht am WLAN Access Point dran ist, wird der Empfänger für die 
Verbindung zum HM400 hin und wieder gestört ( Zustop effeckt ).Das kann 
natürlich auch anders herum vorkommen. Beide senden im gleichen 
Frequenzband.

Ein Problem ergibt sich noch , sobald der MQTT Client von Ahoi ( 0.4.25 
) die Verbindung zum MQTT Server verliert.
Die Reconnect Procedure in der mqtt.h wird sauber aufgerufen, nur 
bekomme der TCP_Client der unter der MQTT Verbindung liegt, die 
Verbindung nicht wieder aufgebaut ( Soweit konnte ich das bis jetzt 
nochvollziehen ).
Nach einer Verbindungsunterbrechung bringt
der MQTT Client sauber den Status -3 ( LOSS CONNECTION ) und
der TCP-Client bringt den Status 0.
Danach bekommt der TCP Client bzw. der MQTT Client die Verbindung nicht 
wieder aufgebaut. Ich habe es hier schon mit einem Disconnect probiert ( 
nachdem festgestellt wurde das die MQTT Verbindung abgebrochen ist ) 
bzw. mit einer Verzögerung vom bis zu 60 Sekunden bevor ein neuer 
connect Versuch unternommen wird. Auch ein "flush" und ein "stop" der 
TCP Verbindung haben keine Verbesserung der Situation gebracht.

[Tobias G. (tobias_g841)]

Danke für Deinen Hinweis @Horst
ich selbst kann damit aber nur wenig anfangen. Ich hoffe auf eine neuere 
Firmware, die das Problem behebt, da es ja mehrere User haben.

[Holger S. (skusi)]

Hallo, das soll jetzt keine Werbe Veranstaltung werden, aber wen es 
interessiert, hier mal ein paar Bilder von meinem Platinen Layout das 
ich entworfen und bestellt habe.

Ich würde 3,- pro Platine + 1,60 Versand nehmen.
Wer nicht löten kann oder will, kann auch ein fertiges Gerät für 45,- 
inc Versand bekommen.

Nur ein Angebot... Keine Profitabsichten ;-) Ich hab das eigentlich für 
mich und meinem Kumpel gemacht, und weil ich mit KiCad umgehen lernen 
wollte. Nun kann und soll aber auch gerne die Community was davon haben.

[Eike (Gast)]

Hi,
ich bekomme keine Connect hin zum Wechselrichter.
ich habe nicht in den DTU settings eingetragen muss da was rein ?

Wlan klappt zu dem Modul....nur eben nicht zum Wechselrichter

ideen ?

eike

[Gerald R. (visitor)]

Betreffend SD init.

So wird die SD Karte nur dann initialisiert wenn man das Loggen im Setup 
aktiviert.

    if(mSDValues == true)
        {
        if (!SD.begin(chipSelect)) {
            DPRINTLN(DBG_INFO, String("SD card failed, or not present"));
            // don't do anything more:
            return;
        }
        DPRINTLN(DBG_INFO, String("SD card initialized."));
    }

Ob das notwendig ist, keine Ahnung.
Ich habe wie bereits erwähnt keine Nachteile durch eine nicht vorhandene 
SD bemerkt.

Aber trotzdem nochmal ein bin und ein diff für diese Version.

[Gerald R. (visitor)]

Eike schrieb:
> ich habe nicht in den DTU settings eingetragen muss da was rein ?
>
> Wlan klappt zu dem Modul....nur eben nicht zum Wechselrichter

Du musst die Seriennummer deines Wechselrichters im Setup eintragen 
damit sich dein DTU damit verbinden kann.
Die Seriennummer findest du auf einem Aufkleber am Wechselrichter.

[Eike (Gast)]

ja in inverter settings aber doch nicht in dtu settings oder ?

[Gerald R. (visitor)]

Ich nehme an es geht um OpenDTU?

Das habe ich gerade nicht in Betrieb, aber da sollte eine Seriennummer 
für den DTU bereits eingetragen sein.

Funktionierte bei mir auf Anhieb.

Verkabelung OK?
Der verwendete NRF24 ist auch sicher ein NRF24L01+?

[Eike (Gast)]

Jau da war auch eine drin die habe ich bei ersten Male gelöscht weil ich 
dachte ich muss da meine serial eintragen

[Gerald R. (visitor)]

Die ist standardmäßig drinnen
99978563412

[Eike (Gast)]

Eingetragen...klappt nicht wie nah muss das Teil beim Umrichter sein?

[Holger F. (holger_f)]

@Eike Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist, 
d.h. DC-seitig Spannung hat und die LED blinkt. Ursache unbekannt. Kann 
es daran liegen?

[Eike (Gast)]

ich habe noch einen tasmota powr r2 dran der misst schon die ganze zeit 
also power hat die kiste und alles klappt.......ich verstehe es 
nicht......ich kann sonst morgen mal ein foto von meinem Gehäuse machen

[Eike (Gast)]

Gerald R. schrieb:
> Verkabelung OK?
> Der verwendete NRF24 ist auch sicher ein NRF24L01+?

System Info
Firmware Information
Hostname  OpenDTU-%06X
SDK Version  v4.4.1-1-gb8050b365e
Firmware Version  0.1.18
Git Hash  12df602
Reset Reason CPU 0  Vbat power on reset
Reset Reason CPU 1  for APP CPU, reseted by PRO CPU
Config save count  14
Uptime  0 days 00:28:17
Hardware Information
Chip Model  ESP32-D0WDQ6
Chip Revision  1
Chip Cores  2
CPU Frequency  240 MHz
Memory Information
Type  Usage  Free  Used  Size
Heap
31%
211 KByte  95 KByte  306 KByte
LittleFs
4%
308 KByte  12 KByte  320 KByte
Sketch
78%
335 KByte  1201 KByte  1536 KByte

[Gerald R. (visitor)]

Da sehe ich das nicht, schau mal hier:
Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"

[Eike (Gast)]

https://www.amazon.de/gp/product/B07Z83MF5W/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1

das gekauft

https://www.amazon.de/gp/product/B09MKCZ7WT/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1

und das

[Rene M. (Firma: Bitte wählen) (renmo)]

@Eike
einmal Serial Log ansehen

[Eike (Gast)]

und wie digga?

[Maik R. (bastelbarney)]

locke987 schrieb:
> Wäre mit einem HM-1500 und iobroker/mqtt auch beim Testen dabei...

Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein 
einfaches Tutorium empfehlen, wie ich in ioBroker ein 
Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin 
MQTT-Neuling, aber sehr interessiert.

[Maik R. (bastelbarney)]

Zur Diskussion mit den Abständen zwischen ESP8266 und nRF24 kann ich nur 
sagen: ich kann Eure Probleme nicht nachvollziehen, mit einem HM-1500 in 
10m Entfernung hinter einer Hausecke.

Ich habe meine Breadboard-Lösung (Bild rechts) mit 10 cm Kabel zwischen 
ESP und nRF heute zerlegen müssen (Breadbord wurde gebraucht) und den 
ESP auf eine 50-polige SCSI-Buchsenleiste (für 
Flachband-Schneidklemm-Montage) gesteckt, den nRF kurz dahinter und 
alles per hand "gecrimpt". Abstand zwischen WLAN-Antenne und nRF-Modul 
nur noch ca. 10 MILLIMETER, und zwar die WiFi-Antenne direkt neben dem 
nRF (Bild links).

Läuft hinreichend stabil! Ja, nur jedes 3 Frame ist ein Receive success. 
Aber da sabbelt ja auch noch ein original DTU-Pro dazwischen.

[Maik R. (bastelbarney)]

Holger F. schrieb:
> Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist

Mein HM-1500 scheint erst zu antworten, sobald er in Summe 2 Watt von 
den Modulen bekommt, jedenfalls ist das der kleinste Wert, den ich Life 
sehe. Ich weiss nicht, ob er dabei die MPP Kurve durchprobiert oder 
einfach nur ein paar Minuten lang angeschlossene Module stabil sehen 
will. Wäre das ein Hinweis für Dich?

30 Minuten sind es mit dem 1500er eher nie. Na, vielleicht an 
Schlechtwettertagen. Aber beobachtet habe ich bislang eher wenige 
einstellige Minuten. Habe Ahoy gerade in ioBroker eingebunden, dann kann 
man es vllt. genauer nachvollziehen.

B.T.W:
An die Cloud senden der DTU-Pro und der DTU-W die Info zudem nur, wenn 
die Ports von vorne beginnend bestückt sind. Hatte zwei Tage mal A1 und 
A2 ab, da hat Ahoy kein Problem mit, aber die Cloud-DTUs sehen das als 
Störung und melden auch die Leistung nicht weiter, obwohl die Anlage 
auch laut 230V Zähler schön produziert.

Das soll jetzt keine Aufforderung sein, die Macke in Ahoy nachzubilden
=:-)

[Maik R. (bastelbarney)]

Eike schrieb:
> ich bekomme keine Connect hin zum Wechselrichter.
> ich habe nicht in den DTU settings eingetragen muss da was rein ?

schau mal in den angehängten Screenshot

[isnoAhoy (Gast)]

von Klaus H. (klahi)
> Zu Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" : Aus 
Interesse
> habe ich mir das gitee-Repository zur DTU-PRO geladen. Ein Repository
> vergisst nichts :-)  Vor dem Commit mit dem Text "Document" mit der
> Commit-Kennung 2d24e2b7a261282501b44da26a5693d5033e8ba6 finden sich
> viele gelöschte Dokumente, unter anderem auch RF通讯协议-V6.6.xlsx
> (übersetzt RFprotocol-V6.6.xslx). Vielleicht finden sich dort aktuellere
> Informationen als in V6.5.
> Ansonsten finden sich in den älteren Commits sehr viele gelöschte
> Verzeichnisse und Dateien. Ich forsche mal noch weiter ...

Das ist interessant, muß das mal extrahieren und durch den Translator 
schicken

von Maik R. (bastelbarney)
> An die Cloud senden der DTU-Pro und der DTU-W die Info zudem nur, wenn
> die Ports von vorne beginnend bestückt sind. Hatte zwei Tage mal A1 und
> A2 ab, da hat Ahoy kein Problem mit, aber die Cloud-DTUs sehen das als
> Störung und melden auch die Leistung nicht weiter, obwohl die Anlage
> auch laut 230V Zähler schön produziert.

Ja das kann ich aus dem Source Code in UsartNrf3_Process_DevRunReality 
aka UsartNrf3_Process_DevRunDebug bestätigen. Dort werden die Werte 
immer überprüft bevor sie übernommen werden. Wenn er 0 Werte findet 
springt er aus der Parser Routine.

Auch das Bild mit den Angaben zur Konfiguration ist prima, werde es 
demnächst mal in die FAQ übernehmen.


PS: Ich habe die FAQ aktualisiert. Jetzt sind Dank @klahus1 einige 
DevInform Kommandos und deren Antworten dazugekommen. Vielleicht kann / 
wollen das einige implementieren, da man damit auch die FW / HW Version 
der Wechselrichter auslesen könnte.

https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

[isnoAhoy (Gast)]

Hallo Klaus H.,
kannst Du eventuell den Link zum Git Commit / Dokument angeben ?
Ich habe nur 6.4 und 6.3 gefunden und die bereits bekannte aktuellste 
6.5.
Ich würde mir gerne mal die 6.6 ansehen wenn ich Sie zu lesen bekomme.

[isnoAhoy (Gast)]

Found it: RF通讯协议-V6.6.xlsx last entry from 2020.03.10

[Ha F. (harry_f)]

Zu dem Problem, dass keine Daten kommen, kann ich folgendes hinzufügen.

Mein Steckbrett liegt seit Wochen an einem "geeigneten" Ort, 
mittlerweile habe ich die Sendeleistung auf MIN eingestellt und es 
funktioniert. Abstand 20m, eine Ziegelwand.

ABER ich hatte es auch schon, dass nach einem OTA erstmal keine Daten 
geliefert wurden. Erst nach einem längerem Zeitfenster konnte des ESP 
Daten liefern. Evlt. ein Problem mit fehlerhaften Zeitstempeln in den 
Abfragen?
Sprich nach dem Neustart ist das Datum/Uhrzeit des ESP im Vergleich zum 
WR in der Vergangenheit und deshalb können keine Daten geliefert werden? 
Nur eine Vermutung.

Im Anhang eine Grafik wie die Produktion am Morgen beginnt.

[Eike (Gast)]

Maik R. schrieb:
> schau mal in den angehängten Screenshot

Ich kann da gar nichts eintragen, da ich opendtu habe :(


Eike

[HM (Gast)]

Hat schon mal jemand versucht ein Scanner zu bauen für Wechselrichter, 
deren Seriennummer nicht bekannt ist?
Gibt es eine Broadcast Seriennummer auf die alle antworten oder 
Bruteforce?

[Tom K. (mrfloppy)]

Hallo
Mein Ahoy läuft ganz gut soweit.
Habe einen Shelly auch drauf hängen, siehe Screenshot.
Mqtt in Richtung IoBroker funzt auch gut.
Nur welcher Wert ist nun der richtig von dem was ich Einspeise in mein 
Haus?
P_AC oder P_DC ?
Der Shelly misst und zeigt immer gleich mit P_DC.
Welchen soll ich in IoBroker loggen zum auswerten?

Danke für die tolle Arbeit.
LG Thomas

[Steffen D. (steffen_d)]

Tom K. schrieb:
> Hallo
> Mein Ahoy läuft ganz gut soweit.
> Habe einen Shelly auch drauf hängen, siehe Screenshot.
> Mqtt in Richtung IoBroker funzt auch gut.
> Nur welcher Wert ist nun der richtig von dem was ich Einspeise in mein
> Haus?
> P_AC oder P_DC ?
> Der Shelly misst und zeigt immer gleich mit P_DC.
> Welchen soll ich in IoBroker loggen zum auswerten?
>
> Danke für die tolle Arbeit.
> LG Thomas

P_AC logge ich mit. Der Shelly ist zu ungenau. Meiner zeigt zuwenig an. 
P_DC ist Leistung des Moduls (Gleichspannung).

[Ha F. (harry_f)]

ACHTUNG: Laienerklärung:

P_DC --> Power DC  ist die erzeugte Leistung der Module in Gleichstrom
P_AC --> Power AC  ist die erzeugte Leistung in Wechselstrom des WR aus 
dem gelieferten Gleichstrom.

Die Differenz ist der bei der Umwandlung entstehende Verlust bei der 
Umwandlung. Bzw. der Wirkungsgrad.


PV1_P_DC + PV2_P_DC = HM-800_P_DC

Efficiency 95.26%  ==   P_DC / P_AC *100  ->  Wirkungsgrad

[Holger F. (holger_f)]

Maik R. schrieb:
> Holger F. schrieb:
>> Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist
>
> Mein HM-1500 scheint erst zu antworten, sobald er in Summe 2 Watt von
> den Modulen bekommt, jedenfalls ist das der kleinste Wert, den ich Life
> sehe. ... Wäre das ein Hinweis für Dich?

Danke, aber die 30 Minuten Wartezeit scheinen noch was anderes zu sein. 
Vom Labornetzteil habe ich sofort 30 V mit max. 2 A, also max. 60 Watt. 
Ohne Verbindung zum AC-Stromnetz nimmt sich mein HM-600 1.1 Watt zum 
Betrieb; ab da lebt (blinkt) er.

Habe jetzt nochmal ganz genau gemessen:

Es dauerte genau 29 Minuten 50 Sekunden zwischen Anschalten meines 
Labornetzteils auf der DC-Eingangsseite bis zum ersten erfolgreichen 
Datenempfang in OpenDTU. Ab dann stabiler Empfang.

Das ist unabhängig von
- DC an String 1 oder 2
- AC-Seite mit Stromnetz verbunden oder nicht
- erfolgreicher Datenlieferung vor WR-Neustart (vor DC aus-ein) oder 
nicht
- OpenDTU Neustarts

=> Jeder neue WR-Start bringt wieder die 30 Minuten Zwangspause.

Ha F. schrieb:
> ABER ich hatte es auch schon, dass nach einem OTA erstmal keine Daten
> geliefert wurden. Erst nach einem längerem Zeitfenster konnte des ESP
> Daten liefern. Evlt. ein Problem mit fehlerhaften Zeitstempeln in den
> Abfragen?

Ich habe auch irgendeine Logik auf Basis der Zeitstempel im Verdacht. 
OpenDTU sendet aber erst nach erfolgreichem NTP-Sync Abfragen zum WR, 
das habe ich im Code so gesehen und mit ein paar Debug-Ausgaben 
überprüft. Der erste für Abfragen verwendete Zeitstempel war bereits 
korrekt und Rücksprünge konnte ich nicht sehen.

Hat der HM-600 eine gepufferte Uhr?

[Ralla66 (Gast)]

Bei meinem HM-600 mit ESP8266 mit Ahoi ist seriell zu sehen das nur 
Transmit 27 / 15 gesendet wird mit der Fehlermeldung das ein Frame 
fehlt. Erst nach Stromtrennung des ESP wird dann Transmit 11 / 15 
gesendet worauf der Payload angezeigt wird.Zeitstempel sind aber ok.

[Eike (Gast)]

Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot und ich 
erreiche das Teil gar nicht mehr.
Wie bekomme ich eine bin von dem ayoli zeig her ?


Eike

[Oswald S. (obmaroszi)]

Also das OpenDTU Mist ist kann ich nicht behaupten. (würde ich auch 
nicht blos wenns mal wo klemmt)
ich würde wenns schon nicht funktioniert einfach noch mal von vorne 
beginnen.
Habe beide Systeme laufen und derzeit läuft bei mir OpenDTU stabiler und 
länger trotz deutlich größerem Abstand zum WR.

[Rene M. (Firma: Bitte wählen) (renmo)]

Merkwürdig.
OpenDTU läuft bei mir seit Wochen einwandfrei.
Ich würde sagen, der Fehler sitzt selber vor dem Teil,....

[locke987 (Gast)]

Maik R. schrieb:
> Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein
> einfaches Tutorium empfehlen, wie ich in ioBroker ein
> Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin
> MQTT-Neuling, aber sehr interessiert.

Ich mache das mit dem influxdb adapter der die Objekte bzw. geloggten 
Daten in eine influxdb schreibt und mittels Grafana mache ich dann die 
Auswertung. Tutorial habe ich leider keines. Beides habe ich als 
container in unraid laufen, hat keine halbe Stunde gedauert bis ich die 
ersten Graphen zusammen hatte.

[Ha F. (harry_f)]

Eike schrieb:
> Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot
> und ich
> erreiche das Teil gar nicht mehr.
> Wie bekomme ich eine bin von dem ayoli zeig her ?
>
> Eike

Hallo,

steht schon mehrfach immer wieder mal weiter oben:
https://github.com/grindylow/ahoy/actions

Man muss angemeldet sein!


Hier die FAQ:
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu

[Oswald S. (obmaroszi)]

Ich mache es mit Openhabian da ich mit IObroker generell nicht zurecht 
kam
Mit Openhabian hat bei mit super funktioniert. (auch E2 Boxen, Smart 
Steckdosen, temp Messung)
Anbei Vergleich Bild Gosund / WR Leistung

[Joachim (Gast)]

Hallo zusammen, zunächst einen großen Dank an alle, die das Projekt hier 
zustande gebracht haben! Ich bin eher 'erfahrener Anfänger' und habe 
hier mal eine kleine Anleitung einschl. der PIN-Belegung für den D1 mini 
angehängt. Das erspart dem einen oder anderen vielleicht eine längere 
Suche im Forum oder woanders - jedenfalls ging es mir so.

Und: falls jemand mal wieder Platinen bestellen sollte - ich hätte noch 
Bedarf für eine Platine :-)

[Canon.Fritz (Gast)]

Könnte einer von euch nochmal das Mqtt Topic für die Leistungsbegrenzung 
posten?

Ich habe die Ahoi Version mit der 0.4.25.bin hier aus dem Forum am 
laufen. WR ist der HM600

Danke ;)

[Daniel M. (daniel_m821)]

Holger F. schrieb:
> @Eike Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist,
> d.h. DC-seitig Spannung hat und die LED blinkt. Ursache unbekannt. Kann
> es daran liegen?

Hallo Holger und Eike,

das Problem ist bekannt, offenbar fehlt noch ein Resetbefehl für die 
Kommunikation.
Wir analysieren das demnächst, muss aber das Dauerlogging vorbereiten.

lg

[Eike (Gast)]

Danke, ich Jan schon gedacht ich bin bescheuert. Sieht ja alles Klasse 
aus soweit nur ich würde gern sehen ob ich alles richtig installiert 
habe. Ich kann das ja nicht testen und sehen das alle Module dran sind.


Danke

Eike

[Stefan T. (isnoahoy)]

Hier eine Neuigkeit aus der Welt der AlarmData Events dank der 
Aufzeichnungen von @klahus1:

Anscheinend wandern die Events aus dem AlarmData langsam nach oben raus.
Ich habe nur 15 Einträge in den beiden o.g. Antworten des 
Wechselrichters finden können:

$ sdiff -w $COLUMNS AlarmData1.txt AlarmData2.txt 
0001                                   |    0001
B001 0006 8D99 8D99 0000 0000          |    B001 0006 8D93 8D93 0000 0000
B002 2783 5EC0 5EC0 FFFF E3E7          |    B002 2784 5EF2 5EF2 0000 1C19
B002 2784 5EF8 5EF8 0000 1C19          |    B002 2785 5EF6 5EF6 FFFF E3E7
B002 2785 5EFC 5EFC FFFF E3E7          |    B002 2786 5F10 5F10 0000 1C19
B002 2786 5F16 5F16 0000 1C19          |    B002 2787 5F14 5F14 FFFF E3E7
B002 2787 5F1A 5F1A FFFF E3E7          |    B002 2788 5F4C 5F4C 0000 1C19
B002 2788 5F52 5F52 0000 1C19          |    B002 2789 5F50 5F50 FFFF E3E7
B002 2789 5F56 5F56 FFFF E3E7          |    B002 278A 5F6A 5F6A 0000 1C19
B002 278A 5F70 5F70 0000 1C19          |    B002 278B 5F6E 5F6E FFFF E3E7
B002 278B 5F74 5F74 FFFF E3E7          |    B002 278C 5F88 5F88 0000 1C19
B002 278C 5F8E 5F8E 0000 1C19          |    B002 278D 5F8C 5F8C FFFF E3E7
B002 278D 5F92 5F92 FFFF E3E7          |    B002 278E 6031 6031 FFFF FFFB
B002 278E 6037 6037 FFFF FFFB          |    B002 278F 6036 6036 0000 0005
B002 278F 603C 603C 0000 0005          |    B002 2790 71AE 71AE FFFF FFFB
B002 2790 71B4 71B4 FFFF FFFB          |    B002 2791 7380 7380 0000 0005
D6EC                                   |    6E24

Was mir dabei aufgefallen ist:
* der ESP schickt fast immer den selben Zeitstempel mit (praktisch immer 
62E98701)
* die Zeitstempel in den beiden o.g. AlarmData Ausgaben differieren um 
ein paar Sekunden:
  - Event 2790 um 71B4 und beim zweiten Aufruf um 71AE. Das sind ca. 6 
Sekunden.
  - 22:20:21.978 .. 22:20:27.649 sind 5,671 Sekunden.
Ich vermute daher der WR aktualisiert seine interne RTC nachdem er immer 
die selbe Zeit vom ESP bekommt.

Es ist also wichtig bei Retransmits und anderen Angaben immer die RTC 
der DTU in den Zeitstempel einfließen zu lassen, sonst gibt es die oben 
beobachteten Zeitverschiebungen.

[Olli (Gast)]

Hallo,

ich habe hier nach Anleitung auch mal alles in Betrieb genommen und 
erhalte grundsätzlich auch Daten vom Wechselrichter.
Diese sind aber bisher alls andere als zuverlässig.

Ich erhalte zumr Zeit 3 Arten von Datensätzen.
Zum einen, die richten Werte die man auch erwarten würde.
Hier passen die Werte, z.B. 500W P_AC, YieldDay passt z.B. auch.

Einige Sekunden später werden dann mal wieder alle Werte als 0 
angegeben.
Und bei der nächsten Abfrage sind es utopische Werte. z.B. 4000V U_DC, 
oder 9500W P_AC.

Das Verhalten ist mit unterschiedlichen WR so.
Das Modul befindet sich testweise in der Nähe des WR.

Amplifier Power Level Einstellungen machen hier keinen Unterschied.

Hatte das schon mal jem. von euch?

Danke schon mal.

[Rene M. (Firma: Bitte wählen) (renmo)]

@Olli
Das hat man normal, wenn parallel eine original DTU mitläuft.

[Dirk (Gast)]

Hi zusammen, ich hab seit etwa 1 Woche 3x1500ter am Start mit der hier 
beschriebenen Konfiguration. Hat bis gestern alles super funktioniert. 
Aber seit gestern 18 Uhr erreiche ich einen gar nicht mehr. DTU wird 
jede Nacht ( wegen MQTT-Verbindungsverlust) neu gestartet. WR war die 
Nacht auch Stromlos (auch 230V).
Was kann ich tun jemand ne Idee ?

[Tobias G. (tobias_g841)]

Dirk schrieb:
> Hi zusammen, ich hab seit etwa 1 Woche 3x1500ter am Start mit der hier
> beschriebenen Konfiguration. Hat bis gestern alles super funktioniert.
> Aber seit gestern 18 Uhr erreiche ich einen gar nicht mehr. DTU wird
> jede Nacht ( wegen MQTT-Verbindungsverlust) neu gestartet. WR war die
> Nacht auch Stromlos (auch 230V).
> Was kann ich tun jemand ne Idee ?

Ich habe heute früh auch schon bestimmt 10x reboot gemacht, weil immer 
wieder MQTT not connected erscheint - irgendwie ist heute der Wurm 
drinnen.
Sonst passiert es nur 2-3x pro Tag.

[Olli (Gast)]

Rene M. schrieb:
> @Olli
> Das hat man normal, wenn parallel eine original DTU mitläuft.

Hey,

vielen Dank für die Info.
Das ist bei mir nicht der Fall. Weitere Ideen?

Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht 
funktionieren würden?

[Highlander (Gast)]

Olli schrieb:
> Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht
> funktionieren würden?

Es kann nur einen geben;-)

[Olli (Gast)]

Highlander schrieb:
> Es kann nur einen geben;-)

Warum ist das so?
Ich ging davon aus, dass die WR Ihre Daten einfach in die Welt raus 
schreien und die DTUs diese empfangen.

[Stefan T. (isnoahoy)]

Hallo Zusammen,

der RECV_CHANNEL 0x61 ist m.W. der mit dem er loslegt. Es wurde bei 
ersten Tests herausgefunden, dass bei TX auf Kanal 0x61 die nächste 
Antwort auf Kanal 0x03 relativ gut empfange wurde, d.h. zwei Kanäle 
Unterschied. Ob das am Timing zwischen Senden und Empfangsbereitschaft 
des Ahoy DTU Codes ist, oder etwas anderes weiß ich nicht.

Die Originalaufzeichnungen mit Hack RF und anderen Geräten von martin 
(Gast), B. G. (golf2010) und Oliver F. (of22) auf Seite 1 & 2 des Forums 
hatten gezeigt, daß auch der Wechselrichter alle 2-5 Antwortpakete die 
Frequenz wechselt.

Dafür gibt (bzw. gab da in der Zwischenzeit immer aktiv) es das sog. 
Channel Hopping das die mRxChList[4]={03, 23, 40, 61, 75} der Reihe nach 
durchgeht. Für die mTxChLst[0]=40 gibt es das bisher noch nicht. Wer 
also Probleme mit dem Funk hat könnte sich daran machen auch für das 
Senden ein Channel Hop einzubauen und vor allem die beiden irgendwie 
sinnvoll miteinander zu koordinieren, damit er auch den nächsten 
Empfangskanal des Wechselrichters möglichst gut errät. Dazu muß man sich 
wie gesagt die o.g. Hack RF Aufnahmen ansehen und einen geschickten 
Algorithmus finden.

Hier noch die Links zum Source Code für die mTxChLst und mRxChLst:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L59-L69

Allgemeine Beobachtung von Oliver F. die aber den Spezifikationen in der 
FCC Application Note für die HMS-100 widersprechen. Dort sind 
tatsächlich nur die o.g. Kanäle (2403, 2423, 2440, 2461, 2475MHz) 
beantragt und werden m.W. auch ausschließlich genutzt.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Hier einige Beiträge von B.G. (golf2010) der das Channel Hopping auf 
seinen Scans relativ gut darstellt.
Was mir dabei aufgefallen ist, sind die Retry-Kaskaden von 15 
Retransmits jeder Nachricht.
Das liegt m.E. eventuell daran, daß die DTU mit diesen aktuellen 
Retransmit Settings ebenso viele Anfragen sendet ?
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Kann man die o.g. Beobachtungen nicht auch mit einem RTL-SDR (RTL2832U) 
mit einem der Tools unter 
https://www.rtl-sdr.com/big-list-rtl-sdr-supported-software/ machen. 
Solange es nur um das Aufzeichnen des Channel Hoppings einer einsamen 
DTU-Pro und eines WR geht sollte das doch zumindest helfen die Kanäle 
und das Muster zu erkennen ?

[Harry G. (sorentodriver)]

Holger S. schrieb:
> Hallo, das soll jetzt keine Werbe Veranstaltung werden, aber wen es
> interessiert, hier mal ein paar Bilder von meinem Platinen Layout das
> ich entworfen und bestellt habe.
>
> Ich würde 3,- pro Platine + 1,60 Versand nehmen.
> Wer nicht löten kann oder will, kann auch ein fertiges Gerät für 45,-
> inc Versand bekommen.
>
> Nur ein Angebot... Keine Profitabsichten ;-) Ich hab das eigentlich für
> mich und meinem Kumpel gemacht, und weil ich mit KiCad umgehen lernen
> wollte. Nun kann und soll aber auch gerne die Community was davon haben.

Hallo Holger,
ich würde gerne dein Angebot in Anspruch nehmen.Und ein fertiges Gerät + 
Versand kaufen.
H.G.

[guilligan (Gast)]

Ha F. schrieb:
> Eike schrieb:
>
>> Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot
>> und ich
>> erreiche das Teil gar nicht mehr.
>> Wie bekomme ich eine bin von dem ayoli zeig her ?
>> Eike
>
> Hallo,
> steht schon mehrfach immer wieder mal weiter oben:
> https://github.com/grindylow/ahoy/actions
> Man muss angemeldet sein!
> Hier die FAQ:
> 
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu

Hi, ich bin angemeldet, kann aber leider keine fertige .bin finden. Auch 
die FAQ ist an der Stelle noch nicht fertig aufgebaut. Da kommt aber 
bestimmt noch Hilfe oder ?

VG Frank

[Giuseppe M. (drdigital)]

Highlander schrieb:
> Es kann nur einen geben;-)

Ich kann das so nicht bestätigen.
Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32.
Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten.
Aktuell wird bei mir ein HM-600 und ein HM-700 ausgelesen und es kommt 
demnächst noch ein weiterer HM-700 dazu. Entfernung von DTU-Pro und 
ESP32 zu HM-600 ist in etwa 3 Meter durch eine Sicherheitsverglasung und 
zum HM-700 ca. 8 Meter durch zwei Wände.

Als ich diesen Thread und das OpenDTU mit ESP32 gefunden hatte war meine 
DTU-Pro schon unterwegs.
Da ich evtl. das Limit Active Power nutzen möchte habe bzw. werde ich 
die DTU-Pro trotzdem behalten.

Hat das hier schon jemand erfolgreich benutzt?

Ich verstehe den Modbus Befehl nicht so richtig.
Laut Anleitung in der DTU-Pro soll Function Code 0x05 an die Adresse 
0xC001 gesendet werden (siehe auch Anhang). Dabei soll man Werte bei HM 
von 2 bis 100% senden können.
Nach meinem Verständnis kann Function Code 0x05 aber nur 1 Bit Werte 
senden bzw. schreiben also nur 1 oder 0.

Kann mir da jemand weiter helfen bzw. den entscheidenden Tipp geben?

Wenn es eine Möglichkeit gibt über OpenDTU per MQTT diese limit Active 
Power zu setzen wäre das natürlich auch super.

[Günter H. (gnter_h534)]

guilligan schrieb:
> Hi, ich bin angemeldet, kann aber leider keine fertige .bin finden.

In dem angehängten Bild habe ich den Weg zur .bin am Beispiel "ahoy" 
skizziert. Die neuste .bin ist jeweils oben in der Liste.

Für "OpenDTU" gelten die Angaben sinngemäß.

Viel Erfolg - Günter

[Olli (Gast)]

Ist OpenDTU eine Alternive zu Ahoi und kann auch auf einem Esp8266 
installiert werden?

[Günter H. (gnter_h534)]

...einfach 'mal die FAQ

https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu

bemühen, genau dafür sind sie da.

[Olli (Gast)]

Danke Dir.

[JedernureinKreuz (Gast)]

Vermutlich ist es ein simpler Anfängerfehler, aber ich bekomme ahoy 
nicht auf meinem RasPi zum laufen. Das getting_started von RF24 läuft 
und ich sehe die SPI Kommunikation auf dem Oszi, aber wenn ich ahoy 
starten will bekomme ich folgendes:

pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config 
ahoy.yml
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "/home/pi/ahoy-tool/hoymiles/__init__.py", line 14, in <module>
    from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, 
RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
ModuleNotFoundError: No module named 'RF24'

Aber in der pip list ist es, so soll es doch eigentlich sein?

pi@ahoy:~/ahoy-tool $ python3 -m pip list
Package       Version
------------- ---------
certifi       2020.6.20
chardet       4.0.0
colorzero     1.1
crcmod        1.7
distro        1.5.0
gpiozero      1.6.2
idna          2.10
paho-mqtt     1.6.1
pip           22.2.1
python-apt    2.2.1
PyYAML        6.0
requests      2.25.1
RF24          1.4.5
RPi.GPIO      0.7.0
setuptools    63.4.0
six           1.16.0
spidev        3.5
ssh-import-id 5.10
urllib3       1.26.5
wheel         0.34.2

Hat jemand eine Idee?

[Olli (Gast)]

Giuseppe M. schrieb:
> Ich kann das so nicht bestätigen.
> Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32.
> Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten.

Hallo,

ist was etwas technisches, dass sich die Systeme stören, oder liegt das 
an der Software?
Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?

[Ziyat T. (toe_c)]

Giuseppe M. schrieb:
>
> Ich verstehe den Modbus Befehl nicht so richtig.
> Laut Anleitung in der DTU-Pro soll Function Code 0x05 an die Adresse
> 0xC001 gesendet werden (siehe auch Anhang). Dabei soll man Werte bei HM
> von 2 bis 100% senden können.
> Nach meinem Verständnis kann Function Code 0x05 aber nur 1 Bit Werte
> senden bzw. schreiben also nur 1 oder 0.
>
> Kann mir da jemand weiter helfen bzw. den entscheidenden Tipp geben?
>
das Handbuch hat viele Fehler!
Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport. 
Raspi/PyModbus:
clientDTU.read_holding_registers und
clientDTU.write_register
für alle DTU-Pro Register
also nicht mit FC 0x05

[Ziyat T. (toe_c)]

JedernureinKreuz schrieb:

> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
mit sudo

> pi@ahoy:~/ahoy-tool $ python3 -m pip list
ohne sudo

kann sein dass die beiden aufrufe andere "environments" haben

[Ziyat T. (toe_c)]

Olli schrieb:
> Giuseppe M. schrieb:
>> Ich kann das so nicht bestätigen.
>> Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32.
>> Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten.
>
> Hallo,
>
> ist was etwas technisches, dass sich die Systeme stören, oder liegt das
> an der Software?
> Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?

JA es laufen beide parallel wenn die DTU-Adressen gleich sind

[Ziyat T. (toe_c)]

Stefan T. schrieb:

> gab da in der Zwischenzeit immer aktiv) es das sog.
> Channel Hopping das die mRxChList[4]={03, 23, 40, 61, 75} der Reihe nach
> durchgeht. Für die mTxChLst[0]=40 gibt es das bisher noch nicht. Wer
> also Probleme mit dem Funk hat könnte sich daran machen auch für das
> Senden ein Channel Hop einzubauen und vor allem die beiden irgendwie
> sinnvoll miteinander zu koordinieren, damit er auch den nächsten
> Empfangskanal des Wechselrichters möglichst gut errät. Dazu muß man sich
> wie gesagt die o.g. Hack RF Aufnahmen ansehen und einen geschickten
> Algorithmus finden.

Das habe ich ja schon lange hier geschrieben und so ist meine SW 
implementiert. Mein MI-1500 aendert die kanaele staendig, so muss ich 
auf RX UND TX hoppen. Ich glaube auch, dass nicht nur der MI so macht..

[Giuseppe M. (drdigital)]

Olli schrieb:
> Hallo,
>
> ist was etwas technisches, dass sich die Systeme stören, oder liegt das
> an der Software?
> Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?

Zum präzisieren.
Ich verwende einen ESP32 keinen ESP8266 bzw. WemosD1
Ich habe zum flashen des ESP32 das hier verwendet
https://github.com/tbnobody/OpenDTU
Es gibt keine fertigen Bin Dateien bzw. habe ich keine gefunden musste 
also genau nach Anleitung per Vscode den ESP32 bespielen.
Nach meinem Verständnis basieren aber Ahoy Wemos D1 und das OpenDTU für 
den ESP32 auf dem gleichen Basis Code sollten also sehr ähnlich sein.
Der ESP32 hat lediglich etwas mehr Speicher und CPU-Speed.

Ich habe die DTU-Pro und den ESP32 im Abstand von ca. 0,5 m gleichzeitig 
im Betrieb.
Der ESP32 ist per MQTT an meinem Smarthome System (Symcon) angebunden.
Die Daten werden zuverlässig übertragen und geloggt (siehe beigefügte 
Screenshots).
Die DTU-Pro wird aktuell nur mit der Cloud genutzt also kein ständiges 
auslesen per Modbus oder ähnliches. Aber in der Cloud werden die zwei 
Wechselrichter ebenfalls zuverlässig geloggt (siehe Screenshot).

[Giuseppe M. (drdigital)]

Ziyat T. schrieb:
> das Handbuch hat viele Fehler!
> Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport.
> Raspi/PyModbus:
> clientDTU.read_holding_registers und
> clientDTU.write_register
> für alle DTU-Pro Register
> also nicht mit FC 0x05

Vielen Dank für die Rückmeldung.
Sind die Register in der Anleitung korrekt?
Oder sind diese ebenfalls fehlerhaft?
Das lesen der Daten also Leistung etc. mit 0x03 funktioniert bei mir 
soweit ohne Probleme.
Nach Deiner Erklärung müsste ich also z.B. zum limitieren aller 
Wechselrichter  in das Register 0xC001 per Function 0x06 einen Wert von 
2-100 schreiben.
Das werde ich morgen mal ausprobieren.

Wenn Du dies schon länger verwendest, wie lange dauert es bis die 
Wechselrichter auf den neuen Limit Wert reagieren?

[Ziyat T. (toe_c)]

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> das Handbuch hat viele Fehler!
>> Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport.
>> Raspi/PyModbus:
>> clientDTU.read_holding_registers und
>> clientDTU.write_register
>> für alle DTU-Pro Register
>> also nicht mit FC 0x05
>
> Vielen Dank für die Rückmeldung.
> Sind die Register in der Anleitung korrekt?
> Oder sind diese ebenfalls fehlerhaft?
> Das lesen der Daten also Leistung etc. mit 0x03 funktioniert bei mir
> soweit ohne Probleme.
> Nach Deiner Erklärung müsste ich also z.B. zum limitieren aller
> Wechselrichter  in das Register 0xC001 per Function 0x06 einen Wert von
> 2-100 schreiben.
> Das werde ich morgen mal ausprobieren.
>
> Wenn Du dies schon länger verwendest, wie lange dauert es bis die
> Wechselrichter auf den neuen Limit Wert reagieren?

- ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006 
ist nicht für  Port 1 sondern für WR 1
- beim MI unter 10% schaltet er fast auf 0
- er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche 
v. mppt ist, dann klar etwas laenger)

[JedernureinKreuz (Gast)]

Ziyat T. schrieb:
> JedernureinKreuz schrieb:
>
>> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
> mit sudo
>
>> pi@ahoy:~/ahoy-tool $ python3 -m pip list
> ohne sudo
>
> kann sein dass die beiden aufrufe andere "environments" haben

Abgefahren, jetzt muss ich das nur noch bereinigt bekommen...


pi@ahoy:~ $ sudo python3 -m pip list
Package       Version
------------- ---------
certifi       2020.6.20
chardet       4.0.0
colorzero     1.1
crcmod        1.7
distro        1.5.0
gpiozero      1.6.2
idna          2.10
paho-mqtt     1.6.1
pip           20.3.4
python-apt    2.2.1
PyYAML        6.0
requests      2.25.1
RPi.GPIO      0.7.0
setuptools    52.0.0
six           1.16.0
spidev        3.5
ssh-import-id 5.10
urllib3       1.26.5
wheel         0.34.2

[Giuseppe M. (drdigital)]

Ziyat T. schrieb:
> - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006
> ist nicht für  Port 1 sondern für WR 1
> - beim MI unter 10% schaltet er fast auf 0
> - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche
> v. mppt ist, dann klar etwas laenger)
Das es WR1 sein muss dachte ich mir schon.
Adresse ist C006?
Weil in der Anleitung steht C007.
Ich werde es morgen testen und noch mal Rückinfo geben.
Vielen Dank

[Stefan T. (isnoahoy)]

Für alle die Ahoy DTU (ESP8266) nutzen, @baloo und ich haben uns heute 
das Problem mit dem MQTT Reconnect angesehen und einen Wechsel des TX 
Kanals für diejenigen, die manchmal 30 Minuten keine Daten vom WR 
bekommen eingebaut.

Der Pull Request dafür ist gestellt.

fix MQTT problem and add TX channel switch to send loop #119
https://github.com/grindylow/ahoy/pull/119

[Olli (Gast)]

Giuseppe M. schrieb:
> Zum präzisieren.
> Ich verwende einen ESP32 keinen ESP8266 bzw. WemosD1
> Ich habe zum flashen des ESP32 das hier verwendet
> https://github.com/tbnobody/OpenDTU
> Es gibt keine fertigen Bin Dateien bzw. habe ich keine gefunden musste

Vielen Dank für die Infos.
Die .bin Files kannst du doch über "Aktions" generieren.

[Stefan T. (isnoahoy)]

Hallo Olli,
Thomas B. schreibt OpenDTU gerade großteils um / neu um die in der 
Zwischenzeit neu hinzugekommenen Kommandos unterzubringen. Es gibt m.W. 
für OpenDTU noch keine GitHub Actions die automatisch die Binaries 
erzeugen.
Wenn Du also Lust hast und weißt wie es geht, kannst Du gerne die 
Actions erstellen und in einem Fork testen.

[HM (Gast)]

Hallo,
ist in OpenDTU oder Ahoy die Möglichkeit schon eingebaut die Leistung zu 
limitieren? Ich muss meinen Elektriker zeigen, dass ich die Geräte auf 
70% eingestellt habe.

LG

[Thomas B. (tbnobody)]

Stefan T. schrieb:
> Es gibt m.W. für OpenDTU noch keine GitHub Actions die automatisch die Binaries 
erzeugen.

Doch gibt es...

[Ziyat T. (toe_c)]

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006
>> ist nicht für  Port 1 sondern für WR 1
>> - beim MI unter 10% schaltet er fast auf 0
>> - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche
>> v. mppt ist, dann klar etwas laenger)
> Das es WR1 sein muss dachte ich mir schon.
> Adresse ist C006?
> Weil in der Anleitung steht C007.
> Ich werde es morgen testen und noch mal Rückinfo geben.
> Vielen Dank

0xc006 on/off wr1
0xc007 limit wr1

[Horst G. (horstg-57)]

habe mal einen Fork mit meiner Lösung für das MQTT-Reconncet Problem und 
dem Anmeldenamen am MQTT erstellt.

Der Reconncet läuft bei mir jetzt sehr zuverlässig und für die Anmeldung 
am MQTT wird jetzt der Device-Name verwendet ( wie er im Setup steht ).

Ausserdem sende ich die MQTT Daten jedesmal sofort aus,
nachdem die WR Daten intern aufbereitet wurden.

Ich lese den WR alle 30 Sekunden aus und erhalte die Daten mit 2 
Sekunden Verzögerung ( so gewollt wegen Funkfeld Belegung ) sofort im 
MQTT-Broker.

Den Pull Request dafür habe ich erstellt.

[Lukas P. (lumapu)]

Hier kann man die neueste Version von Ahoy ESP8266 runterladen, mit MQTT 
Reconnect von isnoAhoy

Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link 
auch jede neuere Version bekommen (ohne Login):
https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip

[Olli (Gast)]

Stefan T. schrieb:
> Wenn Du also Lust hast und weißt wie es geht, kannst Du gerne die
> Actions erstellen und in einem Fork testen.

Hallo Stefan,

da bin ich leider der Falsche, da mir da einige Kenntnisse fehlen.
Aber "Actions" gibt es doch bereits über die man sich eine .bin erzeugen 
kann.

[Dirk S. (fusebit)]

Ziyat T. schrieb:
> JedernureinKreuz schrieb:
>
>> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
> mit sudo
>
>> pi@ahoy:~/ahoy-tool $ python3 -m pip list
> ohne sudo
>
> kann sein dass die beiden aufrufe andere "environments" haben

Jetzt auch wieder mit Login, bitte nicht meckern :-)

Ich habe diesen Teil
python3 -m pip install --upgrade pip
python3 -m pip install .
von hier https://github.com/grindylow/ahoy/tree/main/tools/rpi

nochmal als sudo ausgeführt und nun ist das Modul gelistet.

Danach bekam ich syntax errors, nachdem ich in

ahoy/tools/rpi/hoymiles/decoders/__init__.py

Die Kommentareinleitungen von // auf # geändert habe funktioniert es 
jetzt (vermutlich). Mein HM-300 ist noch unterwegs, aber ahoy versucht 
jetzt zu pollen :-)

[Tobias G. (tobias_g841)]

Vielen Dank an alle Beteiligten für die 0.4.26 - ich bin gespannt.

Wo bringe ich den Wunsch ein, oben bei Visualisation eine summierte 
Gesamtübersicht (YieldTotal, Day, P_AC, P_DC) haben zu können?
Jeder, der mehrere Wechselrichter betreibt, dürfte sich darüber freuen.

Idealerweise per Checkbox im Setup auswählbar (Display SUM).

[Günter H. (gnter_h534)]

Lukas P. schrieb:
> Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link
> auch jede neuere Version bekommen (ohne Login):
> https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip

Über "Actions" bei GitHub ist nun wirklich kein Hexenwerk, der Link ist 
aber noch komfortabler.

Danke dafür und für die ganze Entwicklungsarbeit - natürlich auch an das 
ganze "Team".

[Stefan T. (isnoahoy)]

Danke auch an HorstG-57 und baloo die beim finden und beheben des MQTT 
Problems tatkräftig unterstützt haben. Jetzt bin ich gespannt ob das 
auch tatsächlich allen Betroffenen hilft und wir einige Issues schließen 
können.

@Tobias G. wenn ich mich recht entsinne hat das bereits jemand 
umgesetzt. Der Code / Pull Request steht aber noch aus...

[Frank L. (guilligan)]

Ich habe auf Version 0.4.26 geupdatet. Bei mqtt ist immernoch nur 
read-only 75s möglich (also keine Eingabe einer kürzeren Zeit)? Oder 
sehe ich das nur nicht?
Kann diese Version schon Befehle zur Limitierung über Mqttfx umsetzen 
und wenn ja wie wären die zu schreiben? Bei mir "dtu/hm600/Ch0/??????" 
Und was anstelle der "?" ?
Danke für Hilfe und die Supi-Arbeit hier.

VG Frank (Anfänger mit technischem Verständnis, aber ohne 
Programmierung)

[Holger F. (holger_f)]

Stefan T. schrieb:
> ... und einen Wechsel des TX
> Kanals für diejenigen, die manchmal 30 Minuten keine Daten vom WR
> bekommen eingebaut.
>
> Der Pull Request dafür ist gestellt.
>
> fix MQTT problem and add TX channel switch to send loop #119
> https://github.com/grindylow/ahoy/pull/119

Habe mir jetzt neben der ESP32 OpenDTU auch noch eine ESP8266 Ahoy DTU 
zum Vergleich gebastelt und ich kann bestätigen, dass die 30 Minuten 
Empfangslücke nach WR-Neustart mit der aktuellen Ahoy-Version nicht 
auftreten. Es kommen sofort alle Daten. Spitze!!!

[Dirk (Gast)]

Hallo ich würde gerne die 0.4.26er bin Version testen. Wie kann ich 
meine aktuelle Version 0.4.25 am besten upgraden ?
Was ist der Unterschied zwischen Firmware und Filesystem Upgrade ?

[Günter H. (gnter_h534)]

1. Einige Beiträge nach oben scrollen, dort hat Lukas P. heute einen 
Link zur jeweils aktuellen .bin eingestellt.
2. zip-Datei entpacken.
3. Update Firmware durchführen (Wozu Update FileSystem gut sein kann, 
weiß ich auch nicht).

[Dirk Z. (dirk007)]

Super danke ...

[Joachim (Gast)]

Moin! Eine kurze Frage bzgl. Verbindungsproblemen: welche 
Minimal(!)voraussetzungen genau gibt es, damit über Funk eine erste 
erfolgreiche Verbindung zum WR hergestellt werden kann? Meine 
Vermutungen:
1. Mindestens ein Panel muss angeschlossen sein und Strom produzieren.
2. Der WR muss auch an AC angeschlossen sein (sonst blinkt die LED wohl 
im Sekundentakt rot auf)
3. Laut Forenberichten muss der WR wohl zunächst 30 Minuten laufen - ist 
das wirklich so?

[Olli (Gast)]

Joachim schrieb:
> 1. Mindestens ein Panel muss angeschlossen sein und Strom produzieren.
> 2. Der WR muss auch an AC angeschlossen sein (sonst blinkt die LED wohl
> im Sekundentakt rot auf)
> 3. Laut Forenberichten muss der WR wohl zunächst 30 Minuten laufen - ist
> das wirklich so?

Nur 1. muss gegeben sein.

[Joachim (Gast)]

Danke! Ich frage deshalb, weil er bei mir bisher keine Verbindung 
herstellen kann, es ist ein 300W-Modul dran und die LED blinkt im 
Sekundentakt rot (da noch kein AC angeschlossen ist). Die 30 Min. sind 
bald rum, ich fürchte nur, dass sich nicht viel ändern wird. Die SN ist 
korrekt eingetragen, zwischen Antenne und WR liegen nur 3m. Die 
Meldungen sind bisher nicht vielversprechend:
I: Requesting Inverter SN 11417201xxxx
-> I: Transmit 27 | ...
Inverter #0 I: no Payload received! (retransmits: 5)
....
Hab das Modul im Setup sowohl mal unter Port 1 als auch unter Port 2 
ausprobiert, die Meldungen sind leider die gleichen.

[Joachim (Gast)]

Das hier sind die Meldungen (Anhang)

[Tobi D. (tobidd)]

Joachim schrieb:
> Das hier sind die Meldungen (Anhang)

Probier mal sowohl hardwaremässig als auch Softwaremässig d3 und d4 zu 
tauschen, bei mir gehts damit, siehe

https://github.com/grindylow/ahoy/issues/36

[Joachim (Gast)]

Danke für den Tipp! Auf diese Idee wäre ich natürlich nicht gekommen. 
Ich schau mal, wie ich das umsetzen kann, dummerweise ist das alles 
bereits gut verlötet (angepasste Platine). Aber trotzdem. Wenn ich die 
PINs nur softwareseitig vertausche, bleibt zumindest die Startmeldung 
zur Antenne identisch:
17:04:25.532 -> I: RF24 Amp Pwr: RF24_PA_MIN
17:04:25.532 -> I: Radio Config:
17:04:25.532 -> SPI Frequency    = 1 Mhz
17:04:25.579 -> Channel      = 3 (~ 2403 MHz)
17:04:25.579 -> RF Data Rate    = 250 KBPS
17:04:25.579 -> RF Power Amplifier  = PA_MIN
17:04:25.579 -> RF Low Noise Amplifier  = Enabled
17:04:25.579 -> CRC Length    = 16 bits
17:04:25.579 -> Address Length    = 5 bytes
17:04:25.579 -> Static Payload Length  = 32 bytes
17:04:25.579 -> Auto Retry Delay  = 250 microseconds
17:04:25.579 -> Auto Retry Attempts  = 0 maximum
17:04:25.579 -> Packets lost on
17:04:25.579 ->     current channel  = 0
17:04:25.579 -> Retry attempts made for
17:04:25.579 ->     last transmission  = 15
17:04:25.579 -> Multicast    = Disabled
17:04:25.579 -> Custom ACK Payload  = Disabled
17:04:25.579 -> Dynamic Payloads  = Enabled
17:04:25.579 -> Auto Acknowledgment  = Disabled
17:04:25.579 -> Primary Mode    = RX
17:04:25.579 -> TX address    = 0xdeadbeef01
17:04:25.579 -> pipe 0 (closed) bound  = 0xdeadbeef01
17:04:25.626 -> pipe 1 ( open ) bound  = 0x1234567801
17:04:25.626 -> pipe 2 (closed) bound  = 0xc3
17:04:25.626 -> pipe 3 (closed) bound  = 0xc4
17:04:25.626 -> pipe 4 (closed) bound  = 0xc5
17:04:25.626 -> pipe 5 (closed) bound  = 0xc6

Falls es keine anderen Tipps gibt, werde ich nachher wohl nochmal den 
Kolben in die Hand nehmen müssen :-(

[Olli (Gast)]

Mit welcher Software flasht Ihr die OpenDTU bin Files auf den ESP32?

[Steffen D. (steffen_d)]

Olli schrieb:
> Mit welcher Software flasht Ihr die OpenDTU bin Files auf den
> ESP32?

Mit Visual Studio Code + PlatformIO

[Joachim (Gast)]

OK, ich werde wohl eine neue Antenne bestellen müssen, das Entfernen hat 
sie wohl irgendwie nicht überlebt, obwohl die Kontakte eigentlich 
funktionieren. Ich werde sowas zukünftig besser nicht mehr löten, bevor 
alles auf dem Breadboard läuft.

[Giuseppe M. (drdigital)]

Ziyat T. schrieb:
> 0xc006 on/off wr1
> 0xc007 limit wr1
Hallo,
ich habe es heute mal probiert aber irgendwie hat es nicht richtig 
geklappt.
Könntest Du mir mal bitte ein Beispiel geben welchen Wert man senden 
muss?
Also ich meine muss man Dezimal 2-100 senden?
Oder muss man einen Wert z.B. 400 für 400 Watt senden?
Ich habe mehrere Werte an den Wechselrichter gesendet, irgendwann hat er 
nichts mehr produziert, aber eine Limitierung auf einen bestimmten Wert 
ist mir nicht gelungen.

[Eike (Gast)]

Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen? Also 
opendtu und ahoi?

[Rene M. (Firma: Bitte wählen) (renmo)]

@Eike
wäre vielleicht toll, wenn du einmal die Wikis von OpenDTU und Ahoy 
lesen würdest.
Ein bisschen selber informieren und denken kann nicht schaden.

[Eike (Gast)]

Ne geile FAQ wäre auch toll. Gibt es aber auch nicht.

[Steffen D. (steffen_d)]

Eike schrieb:
> Ne geile FAQ wäre auch toll. Gibt es aber auch nicht.

Vielleicht mal ein wenig mitlesen .....
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

[Rene M. (Firma: Bitte wählen) (renmo)]

Eigentlich ist alles gut beschrieben.
Wenn jemand fragt, o man für OpenDTU und Ahoy die selbe Hardware 
verwenden kann, da liegt es wieder einmal beim Fragesteller.
Hatten wir schon einmal. Da hast ja gleich OpenDTU schlecht geredet, nur 
weil es nicht funktioniert.
Zitat von dir am 02.08 "Das opendtu ist Mist"

Wie so oft, liegt der Fehler vor dir, wenn du in den Spiegel siehst.
Da machen sich andere die Mühe und entwickeln so etwas geniales, und 
dann kommen solche wie du daher, und sagen das ist "Mist"

[Ha F. (harry_f)]

Eike schrieb:
> Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen?
> Also
> opendtu und ahoi?
Hier nachzulesen:

https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-hardware-brauche-ich-f%C3%BCr-die-verschiedenen-software-projekte

[Hermann (Gast)]

Rene M. schrieb:
> Eigentlich ist alles gut beschrieben.

Schenkelklopfer, Zitat aus der achso geilen FAQ:

Q: "Reicht ein ESP8266 mit 1MB oder muss es unbedingt ein ESP8266 mit 
4MB sein?"

A: NIX

Q: Muß es ein nrf24L01+ sein oder funktioniert auch ein nrf24L01 (ohne 
Plus)?

A: NIX

Q: Ich will mir eines bestellen, wo gibt es eine sichere Quelle?

A: NIX

Q: Wie ist das Gerät mit Spannung zu versorgen

A: "Stabile Stromversorgung ..." -> Schenkelklopfer, warum schreibt man 
hier nicht "aus der Steckdose"?

Q: Wo und wie kommt man direkt ohne Entwicklungsumgebung an die .bin?

A: NIX, ein Link wäre wohl zu anstrengend ;)

Q: o liegen die verschiedenen Versionen der .bin´s?

A: NIX, ein Link wäre wohl zu anstrengend ;)

usw. usf.

Das sollte umgehend umbenannt werden in 
FAQ-Frequently-Asked-Questions-without-helpful-answers

Hochachtung vor der Programmierleistung und dem Reverse-Engineering, 
aber Doku? Katastrophe!

Und so zu tun als wäre die superduper und hilfreich (wie die zahlreichen 
Links zur "FAQ" hier im Endlospost zeigen) kann man nicht 
unwidersprochen stehen lassen ;)

[Ha F. (harry_f)]

Naja die FAQ gibt es erst seit wenigen Wochen /einigen Tagen.

Ich denke der Ersteller ist dankbar für jeden hilfreichen Text den er 
bekommt um ihn einzufügen.

Hermann schrieb:
> A: "Stabile Stromversorgung ..." -> Schenkelklopfer, warum schreibt man
> hier nicht "aus der Steckdose"?

Mit der Antwort "aus der Steckdose" kann auch niemand etwas anfangen. 
Hier geht es genau darum, dass das Netzteil entsprechend geeignet sein 
muss um den ESP mit Strom zu versorgen und zwar auch dann wenn er mal 
kurzzeitige etwas mehr zieht (WLAN etc). Ein Netzteil mit 1A kann 
funktionieren, kann aber auch dafür sorgen, dass es Neustarts gibt.

[Joni N. (hal_9000)]

Mein OpenDTU läuft absolut stabil und fehlerfrei seit dem ich es 
angesteckt habe, seit 9 Tagen.

WR steht etwa 5 Meter vom ESP32 entfernt, es ist eine dicke Betondecke + 
Kies dazwischen.

PA Level: Maximum (0 dBm)

Komponenten:
https://www.amazon.de/gp/product/B071P98VTG
https://www.amazon.de/gp/product/B07VQ838KT
https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz

Strom bekomme ich so (direkt von einem der USB-Anschlüsse):
https://www.amazon.de/gp/product/B096BFKWSK


Ein herzliches Dankeschön an alle Entwickler!

[Rene M. (Firma: Bitte wählen) (renmo)]

Hermann schrieb:

> Und so zu tun als wäre die superduper und hilfreich (wie die zahlreichen
> Links zur "FAQ" hier im Endlospost zeigen) kann man nicht
> unwidersprochen stehen lassen ;)


Würde man einfach nur selbst ein bisschen Hirn einschalten und sich die 
Mühe machen etwas selber zu informieren, wäre das kein Problem.
Aber es wird immer Leute geben, die alles vorgekaut brauchen, weil sie 
es selbst nicht schaffen, etwas zu googeln.

Ist aber noch immer kein Grund, irgendetwas schlecht zu mache wie der 
User Eike, den ich zukünftig sicher ignorieren werde

[Eike (Gast)]

Eigentlich ist es ganz einfach...entweder es sollen nur Hardcore User 
nutzen die wissen wie man Datenströme mitloesst und was was ich alles 
oder eben auch normalos.

Normalos. Rauchen eben Amazon links und einfache antworten. Müsst ihr 
euch entscheiden was ihr wollt oder was das für ein prot werden soll so 
einfach ist das.


Eike

[FrankW (Gast)]

@Eike und Hermann

kauf doch einfach das fertige kommerzielle Gerät.
Da musst Du nicht mitdenken und bekommst für Dein Geld ein (hoffentlich) 
fertig entwickeltes und marktreifes Produkt - gleich mit Cloud. Hier 
dreht es sich um ein Projekt von freiwilligen in der Entwicklungsphase. 
Wenn beim kommerziellen Produkt etwas nicht gleich geht, kannst Du gerne 
dem Hersteller schreiben sein Produkt wäre "Mist".

So ist das einfach im Leben. Wer nur Ansprüche hat ohne mithelfen und 
ausprobieren zu wollen, der muss halt einfach ein fertiges Produkt 
kaufen und die Entwicklungsarbeit, Marketing, Vertrieb, Gewinn usw. des 
Herstellers bezahlen.

[Bibo (Gast)]

Hallo zusammen und vielen Dank für eure tolle Leitung bisher.

Ich werde in den nächsten Tagen meinen HM400 aktivieren und hab vorab 
schon mal einen ESP8266 (Wemos D1 mini) + NRF24L01(plus) 
zusammengesteckt und mit der Version 0.4.26 geflasht.

Als Funkmodul hab ich dieses verwendet:
https://www.amazon.de/WayinTop-NRF24L01-Transceiver-Regulator-kompatibel/dp/B07PBBC4H9

Auf dem Chip steht nrf24l01+. Ich hab das Modul über den mitgelieferten 
Adapter an den Wemos angeschlossen. Die Stromversorgung des Adapters 
kommt vom 5V PIN des Wemos.

Nach dem Flashen konnte ich wunderbar auf die Weboberfläche zugreifen 
und alle Einstellungen vornehmen und alles sieht normal aus. Ich bekomme 
natürlich noch keine Daten, da der Wechselrichter noch nicht in Betrieb 
ist.

Was ich aber feststellen musste ist, dass der ESP Chip sehr heiss wird.

Kennt jemand das Verhalten?
Woran kann das liegen?

Viele Gruße,
Bibo

[Ralla66 (Gast)]

Es wäre mal nett wenn jemand erklärt wie man die Commandos für die 
Leistungsbegrenzung über einen ESP8266 zum NRF sendet.
Geschieht dies per Mqtt oder funktioniert dies per Terminal Programm wie 
z.B. Hterm.
Also Command per Hterm TX in hex an ESP senden der dies zum NRF sendet 
oder ist das in der HoyDTUsimu nicht mit enthalten ?

[Klaus H. (klahi)]

Solche Projekte leben vom konstruktiven Mitmachen. Da sind Kommentare 
wie "Mist" oder "NIX, ein Link wäre wohl zu anstrengend ;)" nicht 
hilfreich.

Es gibt da auf Youtube ein Video mit dem Titel 
"Hoymiles-Mikrowechselrichter – DTU für Monitoring einrichten – Tipps 
und Tricks" . Ich war erstaunt wie viele Einschränkungen und 
Fehlfunktionen bei der originalen DTU von Hoymiles erwähnt wurden. Da 
scheint im Kommunikationsverfahren zwischen DTU und Wechselrichter mehr 
als ein bekannter Bug eingebaut zu sein. Open Source Reverse-Engineering 
Projekte diskutieren wenigstens darüber und lösen. Die Hersteller 
wechseln im besten Fall das Produkt aus.

Hochachtung vor allen, die sich bisher eingebracht haben.

[Peter L. (leliep)]

Hermann schrieb:
> …
> Das sollte umgehend umbenannt werden in
> FAQ-Frequently-Asked-Questions-without-helpful-answers
>
> Hochachtung vor der Programmierleistung und dem Reverse-Engineering,
> aber Doku? Katastrophe!
> …
Du weisst aber, dass es sich hier um ein gemeinschaftlich entwickeltes 
Projekt handelt, bei dem jeder herzlich eingeladen ist, einen Beitrag zu 
leisten, um das Gesamtergebnis zu verbessern?

Also: finde die Lücken in der Doku, arbeite Dich durch den ganzen 
Diskussions-Thread und fülle die Lücken mit Deinem erarbeiteten Wissen 
auf. Hat den Effekt, dass Du danach schlauer bist und die, die nach Dir 
Informationen suchen, sie auch mühelos finden.

Und wenn Du erwartest, ein fertiges Produkt zu erhalten, dann schau Dich 
auf dem kommerziellen Markt um. Vielen Dank.

Und ein herzliches „Danke“ an alle hier, die ihre Zeit, ihr Gehinschmalz 
und ihre Arbeit investieren! -pl

[Dirk Z. (dirk007)]

Hallo zusammen, ich find euer Projekt und die Leistung hier echt super. 
Ich würde euch gerne beim ausfüllen der Faqs (soweit es mir möglich ist) 
unterstützen bzw. auch gerne mal ne Anleitung schreiben. Wie kann man 
das organisieren ?

[Günter H. (gnter_h534)]

Bibo schrieb:
> Was ich aber feststellen musste ist, dass der ESP Chip sehr heiss wird.

Was heißt denn "sehr heiß"? Bei den ESP8266 auf meinem Wemos D1 mini ist 
im Dauerbetrieb eine "leichte Erwärmung" feststellbar.

Kannst du die Stromaufnahme messen? Bei mir mit Netzteil (also an 230 V) 
gemessen 0,6 W.

[HM (Gast)]

Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade 
eingestellt ist, da ich das für die EVU brauche.

[Bibo (Gast)]

Günter H. schrieb:
> Was heißt denn "sehr heiß"? Bei den ESP8266 auf meinem Wemos D1 mini ist
> im Dauerbetrieb eine "leichte Erwärmung" feststellbar.

Wenn ich mit meinem Finger ;) die Temperatur messe halte ich es nicht 
lange aus. Ich schätze > 50 °C.

Günter H. schrieb:
> Kannst du die Stromaufnahme messen? Bei mir mit Netzteil (also an 230 V)
> gemessen 0,6 W.

Den Strom werde ich heute Abend mal messen.

[Daniel M. (daniel_m821)]

Dirk Z. schrieb:
> Hallo zusammen, ich find euer Projekt und die Leistung hier echt super.
> Ich würde euch gerne beim ausfüllen der Faqs (soweit es mir möglich ist)
> unterstützen bzw. auch gerne mal ne Anleitung schreiben. Wie kann man
> das organisieren ?

Hallo Dirk,

am einfachsten ist es aktuell, wenn du auf den Discord kommst:
https://discord.gg/6Y4dAs2v

Da können wir die FAQ übersichtlicher erweitern und es ist allen dabei 
geholfen.

Danke für dein Angebot zum Mitmachen :)

lg

[Daniel M. (daniel_m821)]

Liebe Leute,

die Diskussionskultur hier ist vereinzelt unter aller Sau.
Dieses Projekt lebt von konstruktiver Kritik, Verbesserungsvorschlägen 
und dem Mitwirken von Entwicklern, die das ganze hier in ihrer Freizeit 
machen.

Genauso lebt dieses Projekt von Leuten, die Hardware kaufen (zum Teil 
mehrere 100€), öffnen, auf Garantie verzichten und am Ende Daten 
mitloggen und Bereitstellen, aufbereiten, auswerten und das auch mal 
nachts, in der Freizeit.

Das Projekt hier ist weit voran geschritten, weil viele sich helfen, 
gute Fragen stellen oder ordentlich beantworten.
Es geht beim Basteln und Bauen nicht ohne Hirnschmalz.

Wer also der Meinung ist, hier irgendwas Steckerfertig zu kriegen und 
rummotzen kann, weil irgendwas nicht geht, ist falsch hier.
Geht auf ne Webseite, kauft euch vom Hersteller einen Datenlogger und 
schaltet euer Hirn aus. Danke.

Wer jedoch ordentlich Fragen stellt, Diskussionsettikette hat und sich 
selbst erstmal informiert, ist herzlichst willkommen und dem wird auch 
geholfen.

Beiträge wie "ist Kacke" oder "Nix" in den FAQ sind schlicht fehl am 
Platz.

Es gibt wenig Leute hier, die ein Problem damit haben, wenn die eine 
oder andere Frage doppelt oder 3fach kommt, vor allem wenn dazwischen 
Tage oder teils Wochen liegen, aber eine Suchfunktion nutzen ist keine 
Raketenwissenschaft. Das Ding zwischen den Ohren ist nicht zum Haare 
schneiden da sondern zum Denken und Mitdenken.

Stellt eure Fragen so, dass man die beantworten kann und habt etwas 
Geduld. Manche Antwort braucht eben 1-2 Tage.
Nehmt jedoch euren Undank, geht was fertiges kaufen und verstopft hier 
nicht die Pipe mit eurem sinnfreien Gesabbel und Gemotze.

Danke.

[Daniel M. (daniel_m821)]

HM schrieb:
> Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade
> eingestellt ist, da ich das für die EVU brauche.

Hallo HM,

das Powerlimit befindet sich derzeit auf einigen Forks in der Testphase.
Für OpenDTU ist dieses noch nicht verfügbar.

Eine Option um das auszulesen gibt es nicht. Ich würde beim EVU mal 
nachfragen, ob die sich sicher sind, was die da tun. Mir scheint, da ist 
eine gehörige Portion Willkür und Verhinderungstaktik dabei.

So sinnbefreit es auch ist, hier wäre vllt für dich die Option der 
DTU-Pro mit CHiNT Zähler und 0-Einspeisung der richtige Weg. Kostet zwar 
ca. 300€ plus Elektriker, ist aber sicher leichter, als den 
Netzbetreiber zu wechseln, der mindestens fragwürdige Anforderungen an 
ein "Balkonkraftwerk" hat.

Das, was dein EVU fordert, kann weder AHOY noch OpenDTU leisten 
(aktuell).
Zumal einerseits die 70% jederzeit variabel änderbar und nicht verplompt 
sind und andererseits ab 2023 die 70% eh wegfallen sollen, auch für 
Bestandsanlagen. In wie weit das schon durch ist, kann ich gerade nicht 
sagen.

lg

[Rene M. (Firma: Bitte wählen) (renmo)]

Eine Art Nulleinspeisung mit Werten von MQTT wäre das übertrüber.
Ich habe ja schon meine Werte vom Smartmeter per MQTT.
Bin schon gespannt auf die Leistungsanpassung.

Übernimmt und setzt der Wechselrichter diese auch sofort um, oder dauert 
das etwas, bis die Leistung reduziert wird?

[Daniel M. (daniel_m821)]

Rene M. schrieb:
> Eine Art Nulleinspeisung mit Werten von MQTT wäre das übertrüber.
> Ich habe ja schon meine Werte vom Smartmeter per MQTT.
> Bin schon gespannt auf die Leistungsanpassung.
>
> Übernimmt und setzt der Wechselrichter diese auch sofort um, oder dauert
> das etwas, bis die Leistung reduziert wird?

Im Test laufen die praktisch sofort auf das neue Limit, wir wissen nur 
noch nicht, wie gesund das ganze ist.

Die DTU Pro setzt auch das Limit und die WR reagieren sofort.

Welchen Smartmeter hast du im Einsatz?

lg

[Rene M. (Firma: Bitte wählen) (renmo)]

Netzbetreiber hat bei mir einen Kaifa installiert (bin aus Österreich).

Lasse mir sämtliche Smartmeter Werte sekündlich ins Iobroker senden.

Ich denke, wenn Hoymiles die Nulleinspeisung, sprich Leistungsbegrenzung 
von sich aus anbietet, sollte es ja nicht unbedingt ungesund für den 
Wechselrichter sein

[Ha F. (harry_f)]

Also ich hätte auch meinen Momentanverbrauch vom Haus per MQTT zur 
Verfügung.

IoBroker + Adapter Smartmeter + IR-Lesekopf + "Moderner Zähler"

Holley DTZ541-ZDBA  im Bayernwerk Netz.

Liefert unter anderem (ca. alle 5 Sekunden) unter den Datenpunkten:

16.7.0 Momentanwert Gesamtwirkleistung  (Total)  (saldierend)    Bsp. 
250W

2.8.0 Zählerstand 1 Summe Wirkarbeit (Abgabe)                    Bsp 60 
kWh (an der Netzbetreiber verschenkt)


1.8.1 Bezug Tarif 1 (erregt)
1.8.2 Bezug Tarif 2
2.8.0 Lieferung

[Daniel M. (daniel_m821)]

Rene M. schrieb:
> Netzbetreiber hat bei mir einen Kaifa installiert (bin aus Österreich).

Da bin ich jetzt nicht so drin, was das ist.

> Lasse mir sämtliche Smartmeter Werte sekündlich ins Iobroker senden.

Ok :)

> Ich denke, wenn Hoymiles die Nulleinspeisung, sprich Leistungsbegrenzung
> von sich aus anbietet, sollte es ja nicht unbedingt ungesund für den
> Wechselrichter sein

Das kommt drauf an, wenn der zu schnell zu viel nachregeln muss, wirds 
schon interessant, Elektronik kann viel leisten, aber es gibt eben 
Grenzen.

Komm doch gerne im Discord vorbei und mach bei den Tests mit.

lg

[Jörg R. (rejoe2)]

Hallo zusammen,

vorab mal Hut ab, was ihr da gezaubert habt!

Hätte da auch noch ein paar Fragen und Anmerkungen...

Habe einen MI-600 und die Ahoy-0.4.26 auf einem D1-Mini-Klon am laufen. 
Der WR scheint ein "echter" MI zu sein. Dementspechend macht der zwar 
fleißig Anfragen, bekommt aber derzeit (= mit dieser firmware-Version) 
keine Rückmeldungen.
Soweit ich das jetzt verstanden habe, liegt das schlicht daran, dass die 
MI-Varianten noch nicht funktionieren/eingepflegt sind. Kann ich da 
irgendwie helfen bzw. wie nähere ich mich dieser Sache?
(ich bin Hobbyist und kann mich zwar in den C-Code orientieren, aber die 
ganzen Auswertungen sind oberhalb meiner Fähigkeiten...)

Auf ESP32 umzuswitchen bringt im Hinblick auf die MI-Hardware derzeit 
auch nichts, korrekt?

Aufgrund meiner MySensors- und MiLight-Hub-Erfahrungen gehe ich auch 
davon aus, dass die Hardware an sich funktional ist - die nRF-Boards 
stammen aus MySensors-Nodes, die zwischenzeitlich auf RS485 umgestellt 
wurden, es ist eine Hilfsplatine zwischengeschaltet, die einen 
Spannungswandler und ein paar Kondensatoren mitbringt, und an der 
seriellen Schnittstelle sieht zumindest das Senden auch ok aus.
Oder ist das ggf. ein Trugschluss?

Was Doku angeht: Abgesehen von D2/D3 und der Verwendung der IRQ-Line 
entspricht der Aufbau recht genau dem, was insbesondere bei MySensors 
schon lange erprobt ist - da finden sich dann auch viele Tipps betr. der 
Spannungsversorgung des nRF, Fakes/guten Shops und ggf. sogar Platinen 
und 3D-Druck-Daten. Ich selbst habe noch das Glück gehabt, einige nRF 
"vor der großen Fake-Flut" geordert zu haben, die funktionierten zum 
großen Teil (aber auch damals schon nicht alle). Wenn ich heute 
einkaufen müßte: nur noch die "geschieldeten" mit pa+nla (3.100m oder 
so), da scheint das Risiko für fakes nicht ganz so hoch zu sein...

Wünsche bzw. Anregungen hätte ich dann auch noch:
- sowas wie ein "LWT" wäre klasse (vielleicht komme ich dazu, da was 
beizutragen)
- die jeweils zusammengehörenden Datensätze (z.B. pro Eingang?) in einen 
JSON zu verpacken wäre super - das würde weniger Last auf dem von mir 
eingesetzten FHEM erzeugen.
Vielleicht hat ja jemand Lust, das (als Option?) umzusetzen...

Grüße jedenfalls, J.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hallo zusammen,
>
> vorab mal Hut ab, was ihr da gezaubert habt!
>
> Hätte da auch noch ein paar Fragen und Anmerkungen...
>
> Habe einen MI-600 und die Ahoy-0.4.26 auf einem D1-Mini-Klon am laufen.
> Der WR scheint ein "echter" MI zu sein. Dementspechend macht der zwar
> fleißig Anfragen, bekommt aber derzeit (= mit dieser firmware-Version)
> keine Rückmeldungen.

habe eine esp8266 version für MI veröffentlicht, weiter oben

[Ziyat T. (toe_c)]

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> 0xc006 on/off wr1
>> 0xc007 limit wr1
> Hallo,
> ich habe es heute mal probiert aber irgendwie hat es nicht richtig
> geklappt.
> Könntest Du mir mal bitte ein Beispiel geben welchen Wert man senden
> muss?
> Also ich meine muss man Dezimal 2-100 senden?
> Oder muss man einen Wert z.B. 400 für 400 Watt senden?
> Ich habe mehrere Werte an den Wechselrichter gesendet, irgendwann hat er
> nichts mehr produziert, aber eine Limitierung auf einen bestimmten Wert
> ist mir nicht gelungen.

in 0xc007 (uint8)2 bis 100 schreiben, prozent der angeschlossene 
nennleistung
z.B. 1000W angeschlossen, wenn du 500W willst dann ist der wert 50

edit:
> Ich habe mehrere Werte an den Wechselrichter gesendet
an den wr? ne, du schickst an die dtu-pro über modbus, oder?

[Stefan T. (isnoahoy)]

Hallo Joerg,
ich glaube Ziyat T. hatte sich mit dem MI-Protokoll beschäftigt und den 
Code für seinen MI-1500 angepaßt. Analog dazu geht es auch für 
MI-600-800 und die kleine MI-300-500. Beim MI-250 bin ich mir nicht 
sicher, was der tatsächlich verwendet, könnte laut DTU-Pro Source Code 
noch ein Spezialfall sein, da sozusagen der Urschleim der Hoymiles WR.
Such doch mal ob er den Code auch hochgeladen hat oder vielleicht in 
seinem github Repo hinterlegt hat, seit das mit dem ActivePowerLimit 
Kommando bei ihm geklappt hat =^D.

[Giuseppe M. (drdigital)]

Ziyat T. schrieb:
> an den wr? ne, du schickst an die dtu-pro über modbus, oder?

Danke für die Antwort.
Ich habe an die DTU-Pro gesendet.
Per Modbus TCP also an die IP-Adresse des DTU-Pro über Port 502.
Vielleicht habe ich aber auch dort noch einen Fehler bei den RS485 
Einstellungen.
Wie sind diese bei Dir eingestellt?
Einspeisesteuerung oder Fernbedienung?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> habe eine esp8266 version für MI veröffentlicht, weiter oben

Danke, auch an Stefan T..
Hoffe, nichts neueres übersehen zu haben, das scheint die zip vom 13.07. 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") zu sein. Habe die 
Daten zum MQTT-Server, Wifi und der Seriennummer (meine beginnt mit 
1041) angepaßt, aber leider will die Arduino-IDE nicht durchlaufen 
(1.8.19). Wenn ich die erweiterten debug-Ausgaben richtig deute, beißt 
sich da was. Vielleicht kann jemand mit dem Schnipsel was anfangen, ich 
vermute, dass die ESP-libs jetzt "zu neu" sind:

In file included from /home/joerg/Arduino/libraries/ESP8266WiFi/src/ESP8266WiFi.h:39,
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/wifi.h:10,
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/mqtt.h:3,
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:21:
/home/joerg/Arduino/libraries/ESP8266WiFi/src/WiFiClient.h:89:10: error: conflicting return type specified for 'virtual size_t WiFiClient::availableForWrite()'
   89 |   size_t availableForWrite();
      |          ^~~~~~~~~~~~~~~~~
In file included from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Stream.h:27,
                 from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/HardwareSerial.h:32,
                 from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Arduino.h:288,
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:11:
/home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Print.h:80:21: note: overridden function is 'virtual int Print::availableForWrite()'
   80 |         virtual int availableForWrite() { return 0; }
      |                     ^~~~~~~~~~~~~~~~~

Werde jetzt erst mal was anderes machen...

Danke aber auf alle Fälle bis hierhin!

[Ziyat T. (toe_c)]

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> an den wr? ne, du schickst an die dtu-pro über modbus, oder?
>
> Danke für die Antwort.
> Ich habe an die DTU-Pro gesendet.
> Per Modbus TCP also an die IP-Adresse des DTU-Pro über Port 502.
> Vielleicht habe ich aber auch dort noch einen Fehler bei den RS485
> Einstellungen.
> Wie sind diese bei Dir eingestellt?
> Einspeisesteuerung oder Fernbedienung?

es wird als fernbedienung eingestellt, damit sagst du der dtu was sie 
machen soll

da ich auch einen DTSU (smartmeter) abfrage mein modbus laeuft nur über 
rs485

hatte auch mal mit tcp über port 502 verbunden, no problem

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> habe eine esp8266 version für MI veröffentlicht, weiter oben
>
>>>>>>>>>>
> /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:11:
> /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp 
8266/Print.h:80:21:
> note: overridden function is 'virtual int Print::availableForWrite()'
>    80 |         virtual int availableForWrite() { return 0; }
>       |                     ^~~~~~~~~~~~~~~~~[/code]
> Werde jetzt erst mal was anderes machen...
>
> Danke aber auf alle Fälle bis hierhin!

- bei mir laeuft mit arduino-ide 2.0.0-rc6 und 1.8.19, also die esp libs 
sollten bei mir die neueste sein.
- additional board manager url: 
https://arduino.esp8266.com/stable/package_esp8266com_index.json
- selected board: LOLIN(WEMOS) D1 R2 & mini
dann müsste es beim compiler durchkommen

edit:
# ESP8266 platform
name=ESP8266 Boards (3.0.2)
version=3.0.2

[ohnePlan (Gast)]

Hallo, hat jemand schon mal vom ESP8266 oder ESP32 eine Verbindung per 
USB auf ein Samsung Smartphone realisiert (per USB Kabel natürlich) um 
dort die Ertragsdaten abzulegen. Also z.B. pro Tag eine Datei und z.B. 
alle 10 Min. einen Datensatz mit den PV Daten ans Ende der Datei anfügen 
(append) ?  Hab hier nämlich eines herumliegen, das so noch eine 
sinnvolle Verwenung hätte.

[Ziyat T. (toe_c)]

@Jörg R, @Stefan T.

Bin als "keineahnungvongithub" auch auf den github Zug gesprungen.

QUICK&DIRTY  DTUsim für MI
---------------------------
https://github.com/Ziyatoe/DTUsimMI

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> - selected board: LOLIN(WEMOS) D1 R2 & mini
> dann müsste es beim compiler durchkommen
>
> edit:
> # ESP8266 platform
> name=ESP8266 Boards (3.0.2)
> version=3.0.2

OK, DANKE!

Problem saß (zum Teil) vor dem Bildschirm... Meine Arduino-IDE hat schon 
ein paar Versionen hinter sich, und es lagen schlicht noch ein paar 
betagte Versionen von diversen libs im "Arduino"-Folder. Nachdem die da 
gelöscht waren, lief es durch.

Was jetzt aber nicht klappen will, ist der connect zum MQTT-Broker. Der 
ESP schreibt in der seriellen Konsole unglaublich viele Zeichen in den 
Versuch rein, die Subscriptions anzumelden (?), und Werte zeigt er auch 
per Web-Interface bisher keine an. Jetzt lasse ich den mal die 
"verdächtigen 30 Minuten" laufen, vielleicht wird es bis dahin dann 
was...

Als MQTT-Server habe ich es sowohl mit dem in FHEM integrierten 
MQTT2_SERVER versucht (mit der Ahoy-Version kein Problem) wie auch mit 
einem Mosquitto (2.0, anonyme Anmeldung ist erlaubt).

Ziyat T. schrieb:
> @Jörg R, @Stefan T.
>
> Bin als "keineahnungvongithub" auch auf den github Zug gesprungen.
>
> QUICK&DIRTY  DTUsim für MI
> ---------------------------
> https://github.com/Ziyatoe/DTUsimMI

THX, hab's direkt geklont. Bin auch nicht wirklich firm mit github, 
obwohl schon "ewig" dabei...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> - selected board: LOLIN(WEMOS) D1 R2 & mini
>> dann müsste es beim compiler durchkommen
>>
>> edit:
>> # ESP8266 platform
>> name=ESP8266 Boards (3.0.2)
>> version=3.0.2
>
> OK, DANKE!
>
> Problem saß (zum Teil) vor dem Bildschirm... Meine Arduino-IDE hat schon
> ein paar Versionen hinter sich, und es lagen schlicht noch ein paar
> betagte Versionen von diversen libs im "Arduino"-Folder. Nachdem die da
> gelöscht waren, lief es durch.
>
> Was jetzt aber nicht klappen will, ist der connect zum MQTT-Broker. Der
> ESP schreibt in der seriellen Konsole unglaublich viele Zeichen in den
> Versuch rein, die Subscriptions anzumelden (?), und Werte zeigt er auch
> per Web-Interface bisher keine an. Jetzt lasse ich den mal die
> "verdächtigen 30 Minuten" laufen, vielleicht wird es bis dahin dann
> was...

- wichtigste ist die wr-adresse im settings.h
- im settings.h mal tx- und rx-debug einschalten, laeuft was?
- wie weit ist der wr? ev. mit pa_level per serial command 
erhöhen/verringern
- auch wenns nix kommt müssten die null werte auf der web-interface 
sichtbar sein
- ich verwende eigenen mqtt-broker auf dem pi

edit:
als serial monitor nicht den arduino-ide-monitor verwenden, direkt im 
terminal mit dem z.B. minicom auf /dev/ttyXXX gehen, ich verwende ascii 
steuerung im terminal

hast du im settings.h wifi on?

[Rene M. (Firma: Bitte wählen) (renmo)]

Daniel M. schrieb:
>
> Komm doch gerne im Discord vorbei und mach bei den Tests mit.
>

Ich bin da keine Hilfe leider. Schaffe es nicht einmal, den 
Wechselrichter per Hand in eine Leistungsbegrenzung zu bringen.
Wollte das mit MQTT machen, aber klappt nicht.

[Volker.B. (Gast)]

Ich habe gerade auf die 0.5.1 upgedatet.
Bei "Aktive Power Level" hatte ich nichts eingetragen, also stand es bei 
0.
Nun produzierte mein HM600 nichts mehr, auch nicht nachdem ich 600 
eigetragen habe.
Erst nach einem Neustart des WR produziert er wieder.
Ist das so beabsichtigt?

Zusatzfrage, kann (darf) man das Limit auch nach oben setzen?

[Volker.B. (Gast)]

Volker.B. schrieb:
> Zusatzfrage, kann (darf) man das Limit auch nach oben setzen?

Hat sich erledigt, bringt nichts, habe es getestet.

[Rene M. (Firma: Bitte wählen) (renmo)]

Wie funktioniert das mit dieser Leistungsbegrenzung?
ich habe einen HM1500
habe nun  ohne Leistungsbegrenzung 250Watt.
Setze ich die Begrenzung auf 200 Watt habe ich danach plötzlich nur mehr 
um die 100Watt.
Setze ich das ganze wieder auf 1500Watt Begrenzung habe ich wieder die 
250Watt.

[Canon.Fritz (Gast)]

Volker.B. schrieb:
> Ich habe gerade auf die 0.5.1 upgedatet.

@Volker.B. : Wo hast du die Version 0.5.1 her ?
Ich konnte im Repo noch keine neue Version finden :/

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> - wichtigste ist die wr-adresse im settings.h
Die ist eingetragen, das ULL am Ende bleibt ja, oder?

> - auch wenns nix kommt müssten die null werte auf der web-interface
> sichtbar sein
Die sind da, das Ding wird aber als MI-1500 gelabelt. Muss man da für 
MI-600 noch irgendwo anders was umstellen?
> - ich verwende eigenen mqtt-broker auf dem pi
Im Moment habe ich einen ziemlichen "Mesh-up" zwischen deinem 
aktuellsten zip aus github und meinen "Altdaten" und da dann auch noch 
eine Client-Id reingemogelt, die dürfte für den MQTT2_SERVER 
erforderlich sein (Mosquitto ging vorher ja aber auch nicht). In minicom 
sehe ich im Moment trotzdem keine anderen Infos wie den Versuch, sich am 
Server anzumelden, die tx- und rx-debug-Settings habe ich auf "1" 
gesetzt. Das einzige, das sich ändert ist von "LOOP" beim ersten Versuch 
auf "loop" bei allen weiteren.

Man kann den/die Verbindungsversuch/e (?) bei der Variante MQTT2_SERVER 
in FHEM per verbose-Änderung sichtbar machen, das schaut dann so aus:

2022.08.06 14:02:47 5: in@192.168.2.59:52662 SUBSCRIBE: (130)(12)(0)(1)(0)(7)ImpExpW(0)
2022.08.06 14:02:47 4:   MQTT2_FHEM_Server_192.168.2.59_52662 HOY-DTU SUBSCRIBE
2022.08.06 14:02:47 4:   topic:ImpExpW qos:0
2022.08.06 14:02:47 5: out@192.168.2.59:52662 SUBACK: (144)(3)(0)(1)(0)
2022.08.06 14:02:55 4: Connection closed for MQTT2_FHEM_Server_192.168.2.59_52662: EOF
2022.08.06 14:02:55 4: Connection accepted from MQTT2_FHEM_Server_192.168.2.59_58027
2022.08.06 14:02:55 5: in@192.168.2.59:58027 CONNECT: (16)(19)(0)(4)MQTT(4)(2)(0)<(0)(7)HOY-DTU
2022.08.06 14:02:55 4:   MQTT2_FHEM_Server_192.168.2.59_58027 cid:HOY-DTU CONNECT V:4 keepAlive:60
2022.08.06 14:02:55 5: out@192.168.2.59:58027 CONNACK:  (2)(0)(0)
2022.08.06 14:02:55 5: in@192.168.2.59:58027 SUBSCRIBE: (130)(12)(0)(1)(0)(7)ImpExpW(0)
2022.08.06 14:02:55 4:   MQTT2_FHEM_Server_192.168.2.59_58027 HOY-DTU SUBSCRIBE
2022.08.06 14:02:55 4:   topic:ImpExpW qos:0
2022.08.06 14:02:55 5: out@192.168.2.59:58027 SUBACK: (144)(3)(0)(1)(0)

Der ESP meldet sich also mit der vergebenen ClientId an, die Verbindung 
wird aber 8 Sek. später wieder zugemacht, k.A. warum.

> - wie weit ist der wr? ev. mit pa_level per serial command
> erhöhen/verringern
PA-Level steht noch auf LOW, aber das sollte nicht das Problem sein, 
sind nur ca. 3m+ein paar Ziegel + Gips... Den nRF habe ich auch nochmal 
hin- und hergetauscht, kein Unterschied.

Werde mir das nochmal in Ruhe ansehen müssen, und dann ausgehend von 
deinem letzten zip erst mal alles der Reihe nach anpassen und versuchen 
zu verstehen, wann da was warum stattfindet.

EDIT: hier noch die sich ständig wiederholenden Zeilen aus minicom:

MQTT connected = 0
Subscribing to topics.. No MQTT..
Attempting to connect to the MQTT broker: <ip-Adresse>

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> - wichtigste ist die wr-adresse im settings.h
> Die ist eingetragen, das ULL am Ende bleibt ja, oder?

ja, richtig

>
>> - auch wenns nix kommt müssten die null werte auf der web-interface
>> sichtbar sein
> Die sind da, das Ding wird aber als MI-1500 gelabelt. Muss man da für
> MI-600 noch irgendwo anders was umstellen?

eigentlich nicht, meine version erwartet 3 PV's aber es sollte trotzdem 
etwas zeigen


> Der ESP meldet sich also mit der vergebenen ClientId an, die Verbindung
> wird aber 8 Sek. später wieder zugemacht, k.A. warum.

lieg das ev am broker? timeout oder so?

>
> EDIT: hier noch die sich ständig wiederholenden Zeilen aus minicom:
>

MQTT connected = 0
> Subscribing to topics.. No MQTT..
> Attempting to connect to the MQTT broker: <ip-Adresse>
>

ja, mqtt nicht vorhanden
ich nehme an dass du im mqtt.h diese zeilen angepasst hast
const char MQTTbroker[] = "192.168.1.11";
int        MQTTport     = 1883;


ich würde mal im settings.h wifi = 0 stellen dann schauen was vom wr 
kommt, falls die pv's/wr etwas liefern, dann weiter machen mit wifi, 
mqtt

ach ja noch in der "uint8_t checkAllPV(void)"
die Zeile
if (pvCnt[0]+pvCnt[1]+pvCnt[2]==3)  >> ich habe 3 PV's
anpassen, nehme an du hast 2 PV's
if (pvCnt[0]+pvCnt[1]==2)
muss ich mal diese auch irgendwie inn settings.h zügeln

EDIT:
jetzt ist glaube klar, ich abboniere von meinem mqtt broker den 
"ImpExpW", das ding kommt vom meinem DTSU-Smart meter und du hast das 
ding natürlich nicht. füge in deinem broker irgendwie den "ImpExpW"

[Volker.B. (Gast)]

Canon.Fritz schrieb:
> @Volker.B. : Wo hast du die Version 0.5.1 her ?
> Ich konnte im Repo noch keine neue Version finden :/



https://github.com/grindylow/ahoy/actions/runs/2808392417

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> EDIT:
> jetzt ist glaube klar, ich abboniere von meinem mqtt broker den
> "ImpExpW", das ding kommt vom meinem DTSU-Smart meter und du hast das
> ding natürlich nicht. füge in deinem broker irgendwie den "ImpExpW"
OK, da habe ich jetzt mal ein "600" mit retain-Flag reingeschubst.

Dann ändert sich das auf

Subscribing to topics.. ImpExpW Watt 600.0Watt  | All PVs received?:0
No MQTT..

Die erscheinen dann auch als "600.00W" im Web-Interface. Soweit so gut, 
aber irgendwie scheint der ESP was anderes/noch mehr zu erwarten?
(Wo finde ich das? Und wie kann man es ggf. abschalten?)

(Eine originale DTU ist nicht vorhanden, ich könnte natürlich den 
Messwert aus dem zwischengeschalteten Aktor da reinschieben.)

Die übrigen Anpassungen mache ich dann bei Gelegenheit.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ch würde mal im settings.h wifi = 0 stellen dann schauen was vom wr
> kommt, falls die pv's/wr etwas liefern, dann weiter machen mit wifi,
> mqtt
>
> ach ja noch in der "uint8_t checkAllPV(void)"
> die Zeile
> if (pvCnt[0]+pvCnt[1]+pvCnt[2]==3)  >> ich habe 3 PV's
> anpassen, nehme an du hast 2 PV's
> if (pvCnt[0]+pvCnt[1]==2)
> muss ich mal diese auch irgendwie inn settings.h zügeln

Wenn WITHWIFI auf 0 steht (und man dann auch noch die PINS richtig 
anpaßt) kommt dann sowas im "sniffer"-Mode:

40 00 1234567801 00A0 14 0  52 56AD1089 2D434553 EA4AE14B1092078000C8EA150C 0                                     
CH61 00 1234567801 00D5 1A 2  B4 F5BB6BAA A554A84D 0B2AAA84AD369A9955598AA495283690A95255 0                              
CH23 00 1234567801 012A 25 1  55 726ABA6A C9AFAAB5 DAA59D95A5B5F54AB8724ED56D2B0CA551B7654E96000000000000000000 0        
CH23 00 1234567801 0075 0E 2  6D 7A896B5D B548BADE 953A2AA884D8D0 0                                                      
CH40 00 1234567801 003C 07 2  EDAB15B55256AAAAD5                                                                         
CH75 00 1234567801 0095 12 2  69 AB5AA332 759DADDE D5959B612B59295515A515 0
CH61 00 1234567801 00AA 15 1  64 59149A29 D4892271 069250AA6D488A3693512C208B56 0
CH23 00 1234567801 002A 05 1  D46B65DA95323A 
CH61 00 1234567801 0086 10 3  28 B9CE5215 2A2AA462 44D4A4D57294582A56 0
CH23 00 1234567801 016A 2D 1  D6 AE255922 5A9A5D6B Ill remain 38
CH75 00 1234567801 009C 13 2  FF FB32E6BF AFAC1B29 56677884005090092B048288 0
CH75 00 1234567801 0055 0A 2  DA AD2E2B5B AED55492 4E91E5 0
CH75 00 1234567801 012D 25 2  AA 9512A1F2 2555755A 6A5451655455EA954552A4D49AA65AA94AAB14C395000000000000000000 0
CH61 00 1234567801 01D4 3A 2  99 C9DEBD6C A9F2DAEB Ill remain 51
CH40 00 1234567801 002A 05 1  2AA5114954B548 
CH61 00 1234567801 00A9 15 0  95 D52A556A 8556DBB5 5BFCD2A5BAAD52A2545695AAD649 0
CH3 00 1234567801 0122 24 1  F4 AA45A976 AEAD1494 F55B52C000010895220424415544424B6AA4CA696A0000000000000000 0
CH61 00 1234567801 008C 11 2  76 E9AA8246 01949E55 4A48B569245551251349 0
CH61 00 1234567801 00DB 1B 1  65 B540929A 8082D355 5A6AF5DEAAD55BB6BF7B576AAED29454644C84AA 0
CH40 00 1234567801 015F 2B 3  55 64794E0F 5592AEA5 Ill remain 36
CH75 00 1234567801 0098 13 0  C8 8928A92A F6FD5DBE EADFB7D9F35B55D667AA7D5E 0
CH75 00 1234567801 0131 26 0  06 294AB34A A45B55B5 5552A76D6955D6A7C2D6A36956A2D56ABB4ABAA5AE00000000000000000000 0
CH3 00 1234567801 0031 06 0  D4A825B41A801D52 
CH40 00 1234567801 006B 0D 1  24 63509551 5396B58E BD5FFFFFFFFF 0
CH23 00 1234567801 01FF 3F 3  FF FDFFFFFF FFFFFFFF Ill remain 56
CH40 00 1234567801 01FF 3F 3  FF FFFFFFFF FFD77FED Ill remain 56
CH61 00 1234567801 00D9 1B 0  9C 4AB3EB5A 84A2CA9B 2AB15554058322CDEF6EEFFFFDED55BDDFEDA757 0
CH40 00 1234567801 0086 10 3  F6 7FFFFFFF FFFFFFFF FFF7FA9551DFF57BFF 0
CH40 00 1234567801 014D 29 2  4C A4956A70 A868B557 Ill remain 34
CH75 00 1234567801 0155 2A 2  66 DCD957E4 28B2B2FE Ill remain 35
CH61 00 1234567801 0129 25 0  8D 5DD5969A D6DB558D 7D8559A7AD54F66EAEAFB75B5ED56E6AD79EAD774D000000EFA9CA010000 0
CH40 00 1234567801 0095 12 2  53 D2C00040 00200000 036352D556BAAAA5AA9495 0
CH3 00 1234567801 0057 0A 3  DE BAAAAF5D 26CAFD1D 559ABA 6220 B5CA CA72 9E3B 90D8 2C0E B99C D126 84C4 7837 13C0 CA72 B03B B561 CA72 2303 676A 0A2D CA72 28BA C39D 02EA 7EC4 CA72 453A 8D60
CH61 00 1234567801 0098 13 0  5A F994F958 B2B5652E B45BFDEFD555B5642B6F6FA9 0
CH3 00 1234567801 01AD 35 2  92 8D75AB52 45DB6569 Ill remain 46
CH40 00 1234567801 0055 0A 2  5A 54DBFFFE FFFFFFFF FC96AA 0
CH75 00 1234567801 00A9 15 0  54 65A55A26 164611AA 289E5474F15AC24DCAAAAAADA52B 0
CH61 00 1234567801 00A9 15 0  15 21352A58 A9135A95 6A75281A5F0295356C1A2A0A52D5 0
CH75 00 1234567801 0096 12 3  A9 746B7D95 526C6B6E B5B5B12AB1AADAF3BAEADB 0
CH40 00 1234567801 00BA 17 1  B5 B6A5A6AE 6B567B4A AA59B55BFDEBFFFEBEFFE92900000800 0
CH61 00 1234567801 00B7 16 3  29 ACD6FA65 495420C5 215F52A2BF53F0128294840C1AA733 0
CH23 00 1234567801 0022 04 1  E4B25C86AA95 
CH61 00 1234567801 0095 12 2  56 A6552D54 5BAAB6F4 DCD3ED1EDAAEF56D74EF77 0
CH23 00 1234567801 0055 0A 2  A4 8D491611 94AD8ACB 5A4A34 0
CH75 00 1234567801 00AE 15 3  56 AB34D096 E959E66B 48954AF776EACA65AAA96EB7D926 0
CH3 00 1234567801 00D6 1A 3  E7 9ED2AE6F DA0AAEDB 0ACBFFFFF5BFFFFFFFDAFDDDB7FF76DFEFFBFF 0
CH61 00 1234567801 01D5 3A 2  4A DD7AB6D5 AFEAD56E Ill remain 51
CH75 00 1234567801 01FF 3F 3  FD FFFFFFF2 43BAB2AA Ill remain 56

Entweder kommen wir der Sache grade näher, oder das ist irgendwelches 
Zigbee oder WiFi-Gefunke, oder mein MiLight-Hub macht Zicken.... (lt. 
Messgerät kamen grade ca. 308W an).

[Canon.Fritz (Gast)]

Danke @Volker.B.

[Jörg R. (rejoe2)]

Jörg R. schrieb:
> Entweder kommen wir der Sache grade näher

Scheint so:
Bisher war "ONLY_RX" eingeschaltet gewesen, was ohne DTU dann wohl 
keinen Sinn macht. Steht jetzt auf "0", mal schauen, ob dann heute noch 
irgendwelche Werte decodiert werden können. Wenn ich das richtig 
verstanden habe, muss man erst mal ca. 30 Minuten warten?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
> Wenn WITHWIFI auf 0 steht (und man dann auch noch die PINS richtig
> anpaßt) kommt dann sowas im "sniffer"-Mode:
> [code]
> 40 00 1234567801 00A0 14 0  52 56AD1089 2D434553
> EA4AE14B1092078000C8EA150C 0
> CH61 00 1234567801 00D5 1A 2  B4 F5BB6BAA A554A84D
> 0B2AAA84AD369A9955598AA495283690A95255 0
> CH23 00 1234567801 012A 25 1  55 726ABA6A C9AFAAB5
> DAA59D95A5B5F54AB8724ED56D2B0CA551B7654E96000000000000000000 0
> CH23 00 1234567801 0075 0E 2  6D 7A896B5D B548BADE 953A2AA884D8D0 0
> CH40 00 1234567801 003C 07 2  EDAB15B55256AAAAD5
> CH75 00 1234567801 0095 12 2  69 AB5AA332 759DADDE
>>>>>>
> Entweder kommen wir der Sache grade näher, oder das ist irgendwelches
> Zigbee oder WiFi-Gefunke, oder mein MiLight-Hub macht Zicken.... (lt.
> Messgerät kamen grade ca. 308W an).

das ist wie im sniffer mode, ist SNIFFER = 0? jedenfalls das ist 
airtrash!
oder DEBUG_RCV_DATA ist 1;
kannst du mal DEBUG_TX_DATA = 1 stellen?

du kannst es auch im terminal per command 8/9 stellen:
1: help 2:Status 3:PA_LOW 4:PA_HIGH 5:PA_MAX 6:Sniffer 7:ZeroEx 8:OnlyRX 
9:ShowTX 10:Wifi 11:CRC 20:WRinfo 21:Gongfa

[Jörg R. (rejoe2)]

Wie geschrieben: Das war im Sniffer-Modus.

DEBUG_RCV_DATA und DEBUG_TX_DATA stehen jetzt noch auf 1, dann sieht das 
aktuell so aus (meine aktuelle Leistung wird jetzt dahin gepublisht):

Send... CH40 376010001378563412005C.....send res 0
ImpExpW Watt 223.0Watt  | All PVs received?:0
Send... CH61 3860100013785634120053.....send res 0
Send... CH75 3960100013785634120052.....send res 0
Send... CH03 366010001378563412005D.....send res 0
Send... CH23 376010001378563412005C.....send res 0
Send... CH40 3860100013785634120053.....send res 0
Send... CH61 3960100013785634120052.....send res 0
Send... CH75 366010001378563412005D.....send res 0
Send... CH03 376010001378563412005C.....send res 0
Send... CH23 3860100013785634120053.....send res 0
Send... CH40 3960100013785634120052.....send res 0
Send... CH61 366010001378563412005D.....send res 0
Send... CH75 376010001378563412005C.....send res 0
Send... CH03 3860100013785634120053.....send res 0
Send... CH23 3960100013785634120052.....send res 0

Komisch kommt mir vor, dass sich die firmware immer wieder den Wert 
holt, man muss daher mit retain-flag publishen, aber darum kümmern wir 
uns ggf. später.
PA-Level steht jetzt auf "HIGH".

Sollte die "echt-DTU-Adresse" aktiviert werden (im Moment ist das die 
1234...)?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Wie geschrieben: Das war im Sniffer-Modus.
>
> DEBUG_RCV_DATA und DEBUG_TX_DATA stehen jetzt noch auf 1, dann sieht das
> aktuell so aus (meine aktuelle Leistung wird jetzt dahin gepublisht):
>

> Send... CH40 376010001378563412005C.....send res 0
> ImpExpW Watt 223.0Watt  | All PVs received?:0
> Send... CH61 3860100013785634120053.....send res 0
> Send... CH75 3960100013785634120052.....send res 0
> Send... CH03 366010001378563412005D.....send res 0
> Send... CH23 376010001378563412005C.....send res 0
> Send... CH40 3860100013785634120053.....send res 0
> Send... CH61 3960100013785634120052.....send res 0
> Send... CH75 366010001378563412005D.....send res 0
> Send... CH03 376010001378563412005C.....send res 0
> Send... CH23 3860100013785634120053.....send res 0
> Send... CH40 3960100013785634120052.....send res 0
> Send... CH61 366010001378563412005D.....send res 0
> Send... CH75 376010001378563412005C.....send res 0
> Send... CH03 3860100013785634120053.....send res 0
> Send... CH23 3960100013785634120052.....send res 0
>

> Komisch kommt mir vor, dass sich die firmware immer wieder den Wert
> holt, man muss daher mit retain-flag publishen, aber darum kümmern wir
> uns ggf. später.
> PA-Level steht jetzt auf "HIGH".
>
> Sollte die "echt-DTU-Adresse" aktiviert werden (im Moment ist das die
> 1234...)?

wenn deine wr-sn 104160100013 ist dann sollte es gehen, dtu adr ist egal

probiere mal ohne crc
kannst auch mal ohne interrupt probieren

ich fahre immer ohne crc und interrupt

[Jörg R. (rejoe2)]

Die Adresse paßt (jedenfalls steht die so auf dem abfotografierten 
Etikett), CRC war eh' aus (entsprechend den in der zip enthaltenen 
Vorgaben).

Aktuelle Settings lt. minicom:

DEBUG_RCV_DATA 0
DEBUG_TX_DATA 0
PA_LEVEL 2
WITHWIFI 1
ZEROEXP 0
INTERRUPT 0
SNIFFER 0
ONLY_RX 0
CHECK_CRC 0

Werde das ganze dann nochmal in Ruhe durchgehen müssen bzw. ggf. auch 
warten, ob sich das "beruhigt" (oder sind die 30 Min Wartezeit bei 
diesem Code egal?).

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Werde das ganze dann nochmal in Ruhe durchgehen müssen bzw. ggf. auch
> warten, ob sich das "beruhigt" (oder sind die 30 Min Wartezeit bei
> diesem Code egal?).

Ich habe mal in Ruhe das "RF_communication_protocol-V6.5.xlsx" 
angeschaut und gesehen dass 500/600W-Inverter nicht gleich ist wie der 
1000/1500W-Inverter, schade

EDIT:
hier
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Jörg R. (rejoe2)]

Hm, schade, ja. Trotzdem herzlichen Dank für deinen Support bis dahin, 
dann werde ich mir das mal zu Gemüte führen, vielleicht verstehe ich es 
ja...

Habe in den zwei angehängten Dateien ein paar kleinere Änderungen 
vorgenommen, damit man die nicht unbedingt direkt editieren muss, 
sondern die Einstellungen auch über settings.h vornehmen. Klappt 
zumindest teilweise, betr. MQTT ist kommentiert, inwieweit ich es prüfen 
konnte.

settings.h bekommt dann ein paar weitere Einträge:

// Pinger IP
#define PINGER_IP  {192,168,1,1}

// MQTT
bool MQTT_ON = 1;
#define MSERVER_IP   "192.168.1.99"
#define MSERVER_PORT 1883
#define MQTT_ID      "HOYMILES-DTU"
#define VALUE_TOPIC "inverter1"
#define SET_TOPIC   "inverter1/set"

[Eike (Gast)]

Hi sage mal wie kann ich meine hardwar so flashen das sie wie am anfang 
ist ?
ich komme null mehr auf das boar d drauf ganz egal wie oft ich brüber 
flashe.
gibt es einen clean befehl den ich vorher absetzen kann ?


eike

[Rene M. (Firma: Bitte wählen) (renmo)]

Der Eike der immer nur will und alles schlecht redet,...

[Eike (Gast)]

schwall schwall Gummiball.....hast heute schon dein Tabletten genommen ?

[Günter H. (gnter_h534)]

@ Eike

Im diesem Thread steht folgendes:

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Eike (Gast)]

Danke Günther,
leider komme ich gar nicht mehr auf die Oberfläche  sodas ich auch keine 
Bin laden kann :(

[Fritte (Gast)]

Es ist noch lange nicht Alles von Jedem gesagt...

[Gerald R. (visitor)]

Hallo miteinander!

Habe heute Morgen die aktuelle Ahoy 0.5.2 
https://github.com/grindylow/ahoy.git geflasht und war dann schon fast 
am Verzweifeln.

E ist ein Fehler in der defines.h wodurch der Wert für powerlimit mit 
dem Wert von NTP_ADDR überschrieben wird.

in defines.h Zeile 99

#define ADDR_NTP_ADDR       ADDR_INV_MAX_RTRY  + INV_MAX_RTRY_LEN

ändern in

#define ADDR_NTP_ADDR       ADDR_INV_PWR_LIM   + INV_PWR_LIM_LEN

Dann funktioniert das PowerLimit.

Vieln dank an alle! Jetzt kann ich auch in der Nacht einspeisen!

Bitte rasch ändern sonst gibt es einen Schwung nasse Augen heute wegen 
Limit 0W.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hm, schade, ja. Trotzdem herzlichen Dank für deinen Support bis dahin,
> dann werde ich mir das mal zu Gemüte führen, vielleicht verstehe ich es
> ja...

hallo Jörg

habe mal wieder eine quick&dirty version, dieses mal für MI300/600/1500,

kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h" 
anpassen dann auf "Settings.h" aendern und testen?
einfach ohne wifi,mqtt etc.
bool DEBUG_TX_DATA  = 1;  damit wir was sehen

nach dem wir die daten bekommen, können wir alle andere anpassen

[Ziyat T. (toe_c)]

Hallo Leute

Wir versuchen hier ein Projekt durchzuführen, mit so vielen Beitraegen 
(über 2000) wird es immer schwieriger es zu verfolgen.

Also bitte lass das Gequassel über Tabletten und so!

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h"
> anpassen dann auf "Settings.h" aendern und testen?
WOW, was ein Service! Hatte gestern noch auf das xlsx gestarrt und das 
Projekt abgehakt, und jetzt sowas....

Also, vermutlich suchen wir nach sowas hier, oder:

17 MI600
Send... CH61 11601000132143658700F2.....send res 0
New CMD  8a     CH23 00 8765432101 00C4 18 2  8A FFFFFFE6 F77FD57A BB6AAAD96656A95341A2A6BAA7AAA88634 0
9 MI600
Send... CH75 09601000132143658700EA.....send res 0
17 MI600
Send... CH03 11601000132143658700F2.....send res 0
9 MI600
Send... CH23 09601000132143658700EA.....send res 0
17 MI600
Send... CH40 11601000132143658700F2.....send res 0
9 MI600
Send... CH61 09601000132143658700EA.....send res 0
New CMD  8b     CH61 00 8765432101 0080 10 0  8B E5B35477 59DAB6DB 2D55F1B75EB6B55555 0

PS: spricht was dagegen, wifi.h und mqtt.h auszutauschen? Dann kann man 
alles zentral über Settings.h anfassen, was zu individualisieren ist 
(zumindest mittelfristig...)

EDIT: Es zuckt auch mit aktivem WiFi, ist aber nicht durchgängig 
plausibel, siehe angehängten screenshot

[A.D. (Gast)]

Gerald R. schrieb:
> Bitte rasch ändern sonst gibt es einen Schwung nasse Augen heute wegen
> Limit 0W.

Oh ja, den Schwung hatte ich :D

Danke für die Info!!!

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h"
>> anpassen dann auf "Settings.h" aendern und testen?
> WOW, was ein Service! Hatte gestern noch auf das xlsx gestarrt und das
> Projekt abgehakt, und jetzt sowas....

> 9 MI600
> Send... CH75 09601000132143658700EA.....send res 0
> 17 MI600
> Send... CH03 11601000132143658700F2.....send res 0

also wir senden 0x9 und 0x11 das ist mal gut


> PS: spricht was dagegen, wifi.h und mqtt.h auszutauschen? Dann kann man
> alles zentral über Settings.h anfassen, was zu individualisieren ist
> (zumindest mittelfristig...)

im moment will ich nur über serial/minicom die daten kommen sehen, nehme 
an du hast 2 PV's, die im setting.h definiert sind, dann müsste z.B. so 
was kommen:
CH:3 PV0 MI: xxxW Grd:   0W Lm:   0W  xxxW 38.5V 0.0A  854Wh 245.5ACV 
50.0Hz
CH:75 PV1 MI: xxxW Grd:   0W Lm:   0W xxxW 38.5V 0.0A  854Wh 245.5ACV 
50.0Hz

oder, für data
New CMD  89, New CMD 92

dann für die status meldung
New CMD  88, New CMD 91 kommen

EDIT: ev. schickst du mir ein laengeres minicom log?

[Jörg R. (rejoe2)]

Ja, 2 PV's sind definiert. Wenn man das ganze etwas länger laufen läßt, 
werden auch beide gefüllt, die Daten sind im Moment halt nur mehr oder 
weniger inkonsistent, was diese "Nebeninfos" anbelangt (siehe 
Screenshot).

Per minicom -C habe ich jetzt auch einen Mitschnitt gemacht, blöd ist 
nur, dass man da die ganzen loop-Infos drin hat, die das zum einen sehr 
aufblähen, und zum anderen halt nicht wirklich hilfreich sind... Gibt es 
einen besseren Weg, nur den relevanten Teil mitzuschneiden? Per Maus 
markieren ist auch ziemlich - na ja...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ja, 2 PV's sind definiert. Wenn man das ganze etwas länger laufen läßt,
> werden auch beide gefüllt, die Daten sind im Moment halt nur mehr oder
> weniger inkonsistent, was diese "Nebeninfos" anbelangt (siehe
> Screenshot).
>
> Per minicom -C habe ich jetzt auch einen Mitschnitt gemacht, blöd ist
> nur, dass man da die ganzen loop-Infos drin hat, die das zum einen sehr
> aufblähen, und zum anderen halt nicht wirklich hilfreich sind... Gibt es
> einen besseren Weg, nur den relevanten Teil mitzuschneiden? Per Maus
> markieren ist auch ziemlich - na ja...

ok, im .ino alles mit "\b\b\b\b" auskommentieren, dann sollten nur die 
daten geloggt werden

so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?

Kurzzeitig hatte ich mal in beiden PVx plausible Watt-Werte stehen. 
Zwischenzeitlich kamen bei den ganzen Versuchen gar keine Werte rein; 
keine Ahnung, ob ich jetzt den/die nRF geschrottet hatte, oder was grade 
los ist - bzw. jetzt habe ich den nRF wieder auf die pa+nla-Variante 
getauscht, jetzt kommen wenigstens Initial-Werte rein, aber im laufenden 
Betrieb sehe ich grade nur die ganzen Send-Anweisungen.

Problem mit der Spannungsversorgung des Ganzen? (Wie ganz am Anfang 
erläutert, ist da eine Adapterplatine dazwischen mit eigenem 
Spannungswandler 5V->3.3V + diversen Kondensatoren, siehe auch die 
Abbildung bei 
https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo).

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?
>
> Kurzzeitig hatte ich mal in beiden PVx plausible Watt-Werte stehen.
> Zwischenzeitlich kamen bei den ganzen Versuchen gar keine Werte rein;
> keine Ahnung, ob ich jetzt den/die nRF geschrottet hatte, oder was grade
> los ist - bzw. jetzt habe ich den nRF wieder auf die pa+nla-Variante
> getauscht, jetzt kommen wenigstens Initial-Werte rein, aber im laufenden
> Betrieb sehe ich grade nur die ganzen Send-Anweisungen.
>
> Problem mit der Spannungsversorgung des Ganzen? (Wie ganz am Anfang
> erläutert, ist da eine Adapterplatine dazwischen mit eigenem
> Spannungswandler 5V->3.3V + diversen Kondensatoren, siehe auch die
> Abbildung bei
> https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo).

mit der spannungsversorgung habe ich mich überhaupt nicht beschaeftigt, 
bei mir leauft es direkt PC>USB>ESP, ich würde raten, dass du beim 
sw-testen auch so faehrst.

aber immerhin waren die werte mal da und plausible..
ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder 
0x092 ist, das müssen wir noch verifizieren

[Stefan T. (isnoahoy)]

Jörg R. schrieb:
> Ziyat T. schrieb:
> Also, vermutlich suchen wir nach sowas hier, oder:
>

17 MI600
> Send... CH61 11601000132143658700F2.....send res 0
> New CMD  8a     CH23 00 8765432101 00C4 18 2  8A FFFFFFE6 F77FD57A 
> BB6AAAD96656A95341A2A6BAA7AAA88634 0
> 9 MI600
> Send... CH75 09601000132143658700EA.....send res 0
> 17 MI600
> Send... CH03 11601000132143658700F2.....send res 0
> 9 MI600
> Send... CH23 09601000132143658700EA.....send res 0
> 17 MI600
> Send... CH40 11601000132143658700F2.....send res 0
> 9 MI600
> Send... CH61 09601000132143658700EA.....send res 0
> New CMD  8b     CH61 00 8765432101 0080 10 0  8B E5B35477 59DAB6DB 
> 2D55F1B75EB6B55555 0
>

Hallo Joerg / Ziyat T.
Danke dass ihr Euch um die alten Gen2 MI Wechselrichter kümmert, ihr 
seid da ja die Vorreiter was die antiken Schätzchen angeht.
Ja wie ihr schon herausgefunden habt:
* MI-300 verwendet nur einen MPPT, daher Cmd 09
* MI-600 verwendet zwei MPPT, daher Cmd 09 und Cmd 11
* MI-1200 verwendet zwei MPPT mit je zwei Eingänge, daher Cmd 36, 37, 38 
und 39 wie von Ziyat bereits implementiert.

@Joerg R., d.h. Du wirst die Ehre haben MI-300 und MI-600 zu 
implementieren und beide MPPT testen zu können. Ich glaube die Felder 
die vom WR zurückkommen sind bei MI-300,600 und 1200 ziemlich ähnlich. 
Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den 
DTU-Pro Source Code.
Das Power Limit hatte Ziyat T. ja m.W. auch schon für die Gen2 
MI-Wechselrichter implementiert, das müsste eigentlich auch für 
MI-300/600 gehen.

Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch 
im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h, 
etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?

[Ziyat T. (toe_c)]

Stefan T. schrieb:
> Jörg R. schrieb:
>> Ziyat T. schrieb:

> Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den
> DTU-Pro Source Code.

hallo Stefan
eigentlich für mich alles klar bis auf: ich bin mit dem 2.kanal nicht 
ganz sicher, ob data receipt 0x091 oder 0x092 ist, im 
RF_communication_protocol-V6.6.xlsx stehen beide, aber wir werden es 
rausfinden.

> Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch
> im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h,
> etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?

ja, einverstanden.
es ist sowieso sinnvoller alle holymoly versionen unter einem dach 
anzubieten.

sobald es für MI600 laeuft kannst du es von meinem git holen und machen 
wir bei dir weiter.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> mit der spannungsversorgung habe ich mich überhaupt nicht beschaeftigt,
> bei mir leauft es direkt PC>USB>ESP, ich würde raten, dass du beim
> sw-testen auch so faehrst.
>
> aber immerhin waren die werte mal da und plausible..
> ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder
> 0x092 ist, das müssen wir noch verifizieren

Irgendwie ist da der Wurm drin. Im Moment bekomme ich gar keine 
Antworten rein, exemplarisch mal ein paar Zeilen (PA-Level ist egal, 
Ergebnis ist immer dasselbe:

DEBUG_RCV_DATA 1
DEBUG_TX_DATA 1
PA_LEVEL 2
WITHWIFI 0
ZEROEXP 0
INTERRUPT 0
SNIFFER 0
ONLY_RX 0
CHECK_CRC 0

SerialIn: 2 Cmd:2
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 1
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 0
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 1
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 1
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1

Aus der "1" zwischendurch hätte ich jetzt geschlossen, dass der nRF 
prinzipiell ansprechbar ist, aber halt entweder effektiv nichts sendet 
oder "nur" nichts mehr hört.

Prinzipiell ist das mit den Adapterplatinen eine feine Sache (wie 
gesagt, ich habe sowohl Erfahrung bei MySensors@nRF24 wie auch den 
MiLight-Hub von Chris Mullins im Einsatz...), aber dann werde ich das 
mit einem neuen ESP nochmal mit einem fliegenden "Direktaufbau" 
versuchen und notfalls meinen Reserve 3.000m-nRF opfern.

Betr. der 92/91-Frage: die betreffenden Stellen im Code hatte ich 
gesehen und auch den Versuch unternommen, das zu tauschen. Vermutlich 
hatte ich aber nicht alle Stellen im Code erwischt, jedenfalls wurden 
die Payloads entweder gleich als ungültig verworfen, oder es kam 
irgendwas absurdes raus. Werde daher jetzt erst nochmal ESP's suchen 
gehen und ein paar Beinchen anlöten, gehe aber davon aus, dass der 92-er 
Ansatz der zielführende bleibt (siehe auch den screenshot von vorhin; da 
passen zumindest die Leistungsdaten vom 2. Kanal)...

Stefan T. schrieb:
> @Joerg R., d.h. Du wirst die Ehre haben MI-300 und MI-600 zu
> implementieren und beide MPPT testen zu können. Ich glaube die Felder
> die vom WR zurückkommen sind bei MI-300,600 und 1200 ziemlich ähnlich.
> Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den
> DTU-Pro Source Code.
> Das Power Limit hatte Ziyat T. ja m.W. auch schon für die Gen2
> MI-Wechselrichter implementiert, das müsste eigentlich auch für
> MI-300/600 gehen.
>
> Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch
> im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h,
> etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?

Na ja, freut mich ja, wenn ich was beitragen kann, und es wäre auch 
klasse, wenn das in das allgemeine Ahoy-Projekt mit reinkäme - ich hatte 
uU. die Idee, meine Solarkapazitäten noch auszubauen, und dazu wäre es 
schön, nicht für jeden WR ein eigenes Interface zu benötigen grins.

Wie man das dann integriert, wäre eine weitere Frage, die zumindest 
derzeit noch außerhalb meiner gefühlten Kompetenz liegt. Mal schauen...

[Ziyat T. (toe_c)]

ich habe was gefunden:

https://github.com/OFreddy/hm_poll

sein copyright in allen sources:
/*
 Copyright (C)
  2022            OFreddy

die sw (inhaltlich) ist mehr oder weniger von hier, sogar die kommentare 
stimmen!

:-)

[Stefan T. (isnoahoy)]

Ziyat T. schrieb:
> aber immerhin waren die werte mal da und plausible..
> ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x91 oder
> 0x92 ist, das müssen wir noch verifizieren

Die Antworten haben i.d.R. das erste (höchstwertige) Bit gesetzt:
* Anfrage 0x09 -> Antwort 0x09|0x80=0x89
* Anfrage 0x11 -> Antwort 0x11|0x80=0x91
* Anfrage 0x36 -> Antwort 0x36|0x80=0xB6
* Anfrage 0x37 -> Antwort 0x37|0x80=0xB7
* Anfrage 0x38 -> Antwort 0x38|0x80=0xB8
* Anfrage 0x39 -> Antwort 0x39|0x80=0xB9

Hoffe das hilft.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:

> Aus der "1" zwischendurch hätte ich jetzt geschlossen, dass der nRF
> prinzipiell ansprechbar ist, aber halt entweder effektiv nichts sendet
> oder "nur" nichts mehr hört.

sniffer mode einstellen, schauen ob etwas rein kommt
auf .....send res 0 ist kein verlass

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> sniffer mode einstellen, schauen ob etwas rein kommt
> auf .....send res 0 ist kein verlass

OK, dann schaut es doch so aus, als würde der nRF was hören:

CH75 00 1234567801 0095 12 2  5A 95D95AD2 A4A25214 5555548D85328AC0001000 0
CH3 00 1234567801 00DA 1B 1  D5 AD6EEE56 572CAAAF A96D57D5377FFFCBB777DED77EA9F5BFFE3959DE 0
CH75 00 1234567801 0124 24 2  24 955AA853 500AA4AC FA8A42A5A1499A481000A404A9452052AC455912220000000000000000 0
CH3 00 1234567801 012B 25 1  3A ABAD9756 959D4656 5A8AD5A5BFBFFC550A4B255B9ACCEAAB62AA72E3B5000000000000000000 0
CH75 00 1234567801 0029 05 0  526B42AA4A85D8 
CH3 00 1234567801 00AA 15 1  C5 5A149581 A750D50E 9D3496D2954AEAA8F346ADCDE1DF 0
CH61 00 1234567801 0165 2C 2  B5 F55B2DBD FFFBFFBD Ill remain 37
CH40 00 1234567801 0135 26 2  26 5290412D 52CB4AB0 2EA52AD56AA96DAE6AD9AAAD5BA5EA4B0EB1D6A7EE00000000000000000000 0
CH75 00 1234567801 01EB 3D 1  F8 85080000 00004000 Ill remain 54
CH40 00 1234567801 0195 32 2  66 D54AC94C B5BDAAD5 Ill remain 43
CH3 00 1234567801 01C5 38 2  65 C5950416 D325610A Ill remain 49
CH3 00 1234567801 0039 07 0  8AD725212AE264AAAA 
CH23 00 1234567801 016A 2D 1  B6 D7CB9D6B 51A0B241 Ill remain 38

Oder ist das eine Fehlinterpretation?

(Wäre schön zu wissen, ob sich das mit dem Lötkolben lohnt...)

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> CH3 00 1234567801 01C5 38 2  65 C5950416 D325610A Ill remain 49
> CH3 00 1234567801 0039 07 0  8AD725212AE264AAAA
> CH23 00 1234567801 016A 2D 1  B6 D7CB9D6B 51A0B241 Ill remain 38
> [/code]
> Oder ist das eine Fehlinterpretation?
>
> (Wäre schön zu wissen, ob sich das mit dem Lötkolben lohnt...)

ich würde sagen er hört etwas, ev. NRF sendet nicht?
morgen nach dem wr reset wieder probieren

[Jörg R. (rejoe2)]

Hmmm, kann es sein, dass den WR die hohe Anfragefrequenz stört?

Hatte zwischendurch wieder den WiFi-Modus an und dann wieder Sniffer. 
Wenn ich es richtig interpretiert habe (?), wird im Sniffer-Mode nichts 
gesendet. Es kommen dann aber noch ein paar Messages rein, danach ist 
wieder ziemlich Ruhe. Vielleicht ist das eine Fehlinterpretation, aber 
ggf. ist es kontraproduktiv, zu viele Anfragen zu senden?
Also: DTU meldet: "ich bin da, sende was!"
WR sendet eine Zeitlang wie angefordert, bis wieder eine Art Ping kommt 
für "DTU ist noch da".
Anders gesagt: Das Dauerfeuer, das wir hier veranstalten kommt mir nicht 
plausibel vor....

Auf die Schnelle wäre ein Hinweis hilfreich, wo man die Sendefrequenz 
für die Anfragen reduzieren könnte?

EDIT:
Wg. der libs - bin da alles andere als erfahren, und bevor ich mich da 
reinzufuchsen versuche wäre ein Wink auch ganz nett, wenn ich mich 
einfach gedulden darf...

EDIT2: habe wieder den WiFi-Modus angemacht und jetzt sind wieder für 
Kanal 1 einigermaßen plausible Daten da (v.a. was die (halbe) Leistung 
angeht...

EDIT3: Jetzt sind mir doch noch ein paar Nachrichten ins minicom-log 
geflogen - vielleicht kann jemand was damit anfangen. Die Frequenzen im 
Web-Interface sind jedenfalls nicht plausibel (anders als (meistens) 
vorhin).

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hmmm, kann es sein, dass den WR die hohe Anfragefrequenz stört?
>
> Hatte zwischendurch wieder den WiFi-Modus an und dann wieder Sniffer.
> Wenn ich es richtig interpretiert habe (?), wird im Sniffer-Mode nichts
> gesendet. Es kommen dann aber noch ein paar Messages rein, danach ist
>>>>>>>>>>>>>

es kann schon sein dass der wr zu macht,

in void isTime2Send (void) die zeile
  if (millis() >= tickMillis) {
    tickMillis += 300;  <<<<<<< mit der kannst du spielen

vom log file:
status v. kanal B, status 3:
CH3 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1

data v. kanal A:
CH75 00 1234567801 00C4 18 2  89 60100013 60100013 
01310023093A138D040408960179D1B273 1
die sind richtig, siehe screenshot im anhang

also diese zeilen aendern:
      case 0x89:    //1-2 ports
      case 0x91:    //2 ports     <<<<<<<<<<<<<<<<<<
        MI600DataMsg(p);
      break;
       case 0x88:    //1-2 ports
       case 0x92:    //2 ports     <<<<<<<<<<<<<<<<<<
          MI600StsMsg(p);
       break;
und:
 if (p->packet[2] == 0x91)  {PV= 1; TotalP[2]=P_DC; pvCnt[1]=1;}//port 2

[Jörg R. (rejoe2)]

Eine Sekunde eingestellt und die Stellen angepaßt => Leistungsdaten für 
Kanal 2 sind plausibel freu
Kanal 1 ist zwar im Moment noch tot, aber da bin ich optimistisch... 
Vielleicht hängt es doch auch an der Spannungsversorgung, das grade 
aktive pa+nla braucht halt mehr Saft als das kleine, und die Frequenz 
ist vielleicht dann das Tröpfchen...?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Eine Sekunde eingestellt und die Stellen angepaßt => Leistungsdaten für
> Kanal 2 sind plausibel *freu*
> Kanal 1 ist zwar im Moment noch tot, aber da bin ich optimistisch...
> Vielleicht hängt es doch auch an der Spannungsversorgung, das grade
> aktive pa+nla braucht halt mehr Saft als das kleine, und die Frequenz
> ist vielleicht dann das Tröpfchen...?

ja super,
aber eine sekunde ist definitiv zu lang denke ich..
kannst du mal DEBUG_TX_DATA  = 0 stellen und ein minicom log schicken?

[Jörg R. (rejoe2)]

Anbei mal ein log mit 350.

Hab's jetzt wieder mit 300 laufen - hatte ja mal so funktioniert, mal 
schauen....
Kanal 2 kommt allerdings nichts an Leistung, dafür wieder Kanal 1...

[Peter S. (Gast)]

Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke 
und mir ist da etwas aufgefallen:
Irgendwann verabschieden sich meine beiden dauer-laufenden 
Installationen gerne mal mit einem watchdog reset (Ursache noch 
unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den 
Hanger nicht, erst nach einem Power Reset läuft alles wieder.
Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann 
sehe ich einen falschen Bootloader Mode:
 ets Jan  8 2013,rst cause:2, boot mode:(1,6)
verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man 
sollte also den IRQ besser woanders hinlegen, meine ich.

[Chris (Gast)]

Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2 
erfolgreich getestet. Allerdings habe ich das Limit in den Settings 
gesetzt.
- Ist es möglich das Limit über MQTT vorzugeben?
- Wäre eine Anzeige des aktuellen Limit über MQTT möglich / sinnvoll?

Übrigens läuft seit 0.4.26 MQTT perfekt. MQTT "not connected" gibt es 
seitdem nicht mehr!!
Super Job, Danke!!

[Günter H. (gnter_h534)]

Peter S. schrieb:
> Irgendwann verabschieden sich meine beiden dauer-laufenden
> Installationen gerne mal mit einem watchdog reset (Ursache noch
> unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den
> Hanger nicht, erst nach einem Power Reset läuft alles wieder.

Diesen Phänomen kann ich bestätigen. Meine Installation ist stabil 
augebaut, das nRF24L01+-Modul hat wird über einen separaten 
3,3V-Spannungsregler versorgt, dennoch bleiben Abstürze nicht aus. 
Erwähnt werden soll aber auch, dass die Stabilität deutlich größer 
geworden ist - mein "Rekord" liegt bei fünf Tagen.

[Joni N. (hal_9000)]

Chris schrieb:
> Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2
> erfolgreich getestet. Allerdings habe ich das Limit in den Settings
> gesetzt.
> - Ist es möglich das Limit über MQTT vorzugeben?

Von drschiffler/discord:

subcribed topics are mTopic + "/devcontrol/#" where # is <inverter_id>/<subcmd in dec>
eg. mypvsolar/devcontrol/1/11 with payload "400" --> inverter 1 active power limit 400 Watt
mTopic ist das was im Setup eingetragen ist.
mit <mTopic>/devcontrol/0/0 + payload beliebig --> einschalten
mit <mTopic>/devcontrol/0/1 + payload beliebig --> ausschalten
mit <mTopic>/devcontrol/0/11 + payload xxx --> Limit auf xxx Watt
mit <mTopic>/devcontrol/0/2 + payload beliebig --> neustart
Beispiele alle mit Inverter Id 0

Achtung: Das Limit per MQTT ist nicht-permanent (find ich auch gut & 
richtig so, sonst wird das EEPROM auf Dauer zerstört).

[Stefan T. (isnoahoy)]

Peter S. schrieb:
> Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke
> und mir ist da etwas aufgefallen:
> Irgendwann verabschieden sich meine beiden dauer-laufenden
> Installationen gerne mal mit einem watchdog reset (Ursache noch
> unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den
> Hanger nicht, erst nach einem Power Reset läuft alles wieder.
> Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann
> sehe ich einen falschen Bootloader Mode:
>  ets Jan  8 2013,rst cause:2, boot mode:(1,6)
> verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man
> sollte also den IRQ besser woanders hinlegen, meine ich.

Hallo Peter S.,

danke für den Hinweis, wir diskutieren das Problem schon seit geraumer 
Zeit in
https://github.com/grindylow/ahoy/issues/36
Ich werde Deine Antwort dort mal hinzufügen. Eigentlich war die 
ursprüngliche Intention die Pins D1/D2 für I2C oder andere zukünftige 
Anwendungen (ModBus485, etc.) freizuhalten.
Bisher hatte ich als Grund für die WDT Resets meist ein Problem in 
umm_malloc ausgemacht. Ich vermute das hängt mit der Nutzung der 
String-Implentierung im ESP8266 zusammen. Weitere Debug Output dazu 
packe ich auch in das o.g. Issue

Gibt es nicht eine einfache Möglichkeit den GPIO0 / D3 beim Booten auf 
High zu ziehen -> RC-Glied ?

[Jörg R. (rejoe2)]

Moin,

anbei mal das, was so über einen Zeitraum von etwa einer Stunde so via 
minicom reingekommen ist. Im Web-Interface ergibt das keine plausiblen 
Daten, aber immerhin wird "irgendwas" empfangen.

Sieht für mich nach einem Problem in der Auswertung aus.

Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt 
erst mal nicht möglich.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Anbei mal ein log mit 350.
>
> Hab's jetzt wieder mit 300 laufen - hatte ja mal so funktioniert, mal
> schauen....
> Kanal 2 kommt allerdings nichts an Leistung, dafür wieder Kanal 1...

einige anpassungen, mqtt on/off über settings.h
wenn ZEROEXP = 0, keine mqtt subscription "ImpExpW"
viel glück ;-)

[Fritte (Gast)]

Jörg R. schrieb:
> Sieht für mich nach einem Problem in der Auswertung aus.
>
> Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt
> erst mal nicht möglich.

Wollt ich auch schon immer mal sagen.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Moin,
>
> anbei mal das, was so über einen Zeitraum von etwa einer Stunde so via
> minicom reingekommen ist. Im Web-Interface ergibt das keine plausiblen
> Daten, aber immerhin wird "irgendwas" empfangen.
>
> Sieht für mich nach einem Problem in der Auswertung aus.
>
> Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt
> erst mal nicht möglich.

diese sind kanal A daten:
CH23 00 1234567801 00C0 18 0  89 60100013 60100013 
014F00140BF555F7FDDEB6AF5B9772FB37 0
CH40 00 1234567801 00C2 18 1  89 60100013 60100013 
01F6DECABF5B5AF55F7D79EDACAB737557 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 
01490029091013860520004D7E57F3D6DF 0

diese sind kanal B daten:
CH23 00 1234567801 00C2 18 1  91 60100013 60100013 
07AAD1FDF9F7EF75FBFDF3DF7AFDB6BB2A 0
CH40 00 1234567801 00C4 18 2  91 60100013 60100013 
01510555F576FD7DBBE7B7EBDD3D6BADBB 0
CH61 00 1234567801 00C6 18 3  91 60100013 60100013 
01CB5AF9767B2BFFF5DAA0912210850421 0

wenn 0x89 oder 0x90 kommen, hier sind sie ja, dann müsste 
"MI600DataMsg(p)" aufgerufen werden, dann müsste im serial monitor so 
was stehen:
PV:1 37.30V 0.40A 15.10W 992.00Wh 233.40V 49.99Hz 31.80C  Sts:3 Cnt:0

[Ziyat T. (toe_c)]

diese sind status msg. kanal A
CH75 00 1234567801 0080 10 0  88 60100013 60100013 0003000000008BD407 0
CH61 00 1234567801 0080 10 0  88 60100013 60100013 0003000000008BD40D 1

diese sind status msg. kanal B
CH3 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913F58 0
H61 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
CH75 00 1234567801 0080 10 0  92 60100013 60100013 0003000039EEBD6B5B 0

beide kanaele sind ON und produzieren (0003)

also, es kommen schon mal richtige daten, das ist doch mal sehr gut, den 
rest schaffen wir doch auch noch

[Ziyat T. (toe_c)]

hallo Jörg
also ich habe die daten überprüft, die sind nicht plausibel, verwende 
bitte das neue .ino im anhang.
ich würde mal in settings.h die CHECK_CRC = 1 stellen und mal keine wifi 
und so.

[Eike (Gast)]

Ich habe mir den dtu White gekauft und drangesteckt. Hier kommt jetzt 
die Fehlermeldung das die sn des Wechselrichter falsch ist. Kann ich die 
irgendwo ermitteln ? Ja ich habe die richtige vom Aufkleber eingetragen.
Ich kann zwar noch immer nicht auf mein opendtu zugreifen aber das mir 
mittlerweile egal

[Eike (Gast)]

Ist erledigt. Läuft.

[Frank L. (guilligan)]

Joni N. schrieb:
> Chris schrieb:
>> Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2
>> erfolgreich getestet. Allerdings habe ich das Limit in den Settings
>> gesetzt.
>> - Ist es möglich das Limit über MQTT vorzugeben?
>
> Von drschiffler/discord:
>
>

subcribed topics are mTopic + "/devcontrol/#" where # is 
> <inverter_id>/<subcmd in dec>
> eg. mypvsolar/devcontrol/1/11 with payload "400" --> inverter 1 active 
> power limit 400 Watt
> mTopic ist das was im Setup eingetragen ist.
> mit <mTopic>/devcontrol/0/0 + payload beliebig --> einschalten
> mit <mTopic>/devcontrol/0/1 + payload beliebig --> ausschalten
> mit <mTopic>/devcontrol/0/11 + payload xxx --> Limit auf xxx Watt
> mit <mTopic>/devcontrol/0/2 + payload beliebig --> neustart
> Beispiele alle mit Inverter Id 0

>
> Achtung: Das Limit per MQTT ist nicht-permanent (find ich auch gut &
> richtig so, sonst wird das EEPROM auf Dauer zerstört).


Hallo,
gute Aufbereitung und Hilfe. Leider komme ich damit nicht klar. Über 
Mqtt bekomme ich das nicht hin (Version 0.5.2).
Ich versuche über mqttfx die Limitierung zu senden, aber ohne Erfolg.
Topic: dtu
name: hm600
dann sollte das für den 1. Inverter doch so aussehen:
"dtu/devcontrol/0/11 + payload 400" oder nicht?

Danke für weitere Hilfe.

[Rene M. (Firma: Bitte wählen) (renmo)]

@Frank
So ist es richtig

devControl commands via MQTT Topic (/devcontrol/subcmd + payload); eg. 
mysolar/devcontrol/1/0 --> turn on inverter 1; eg. 
mysolar/devcontrol/1/1 --> turn off; mysolar/devcontrol/0/11 + payload 
"300" --> set power limit for inverter 1 to 300 W (set power is now 
remanent during inverter power cycle and remanent during power cycle of 
ahoy and power limit is set on each reboot/start up THX: @klahus1)
Set power limit in setup page; Save --> writes to eeprom --> reboot --> 
after reboot set power limit acc. to eeprom
Set power limit to zero --> inverter will not stop working (Reactive 
Power <> 0 VAr) but active power will be zero
During change of power limit eg. 200 W --> 500 W, the Powerfactor is not 
controled
Case "set to unlimited power": NOT working by setting it to large 
numbers or -1 or similar. You have to set it acc. to the specific device 
eg. Mi-1500 --> 1500. There is an error handling because the response 
from inverter differs in case the new power limit is NOT accepted. See 
logs.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> bitte das neue .ino im anhang.

Anbei das log dazu. Da aber erst mal gar nichts passiert ist, habe ich 
doch Wifi zugeschaltet.

Jetzt kann man auch besser erkennen, wie die (m.E. zu) wenigen Messages 
in etwa reinkamen. Wenn nicht verändert, macht FHEM ca. alle 5 Min. ein 
publish.

Kurzfassung: Beide Kanäle werden ausgewertet, aber es sind zu wenige 
Datenpunkte und das "Beiwerk" ist komisch. Effektiv was empfangen wird 
mehr oder weniger nur, wenn auch WiFi läuft, warum auch immer.

Habe die effektiv verwendeten Parts dann auch per pull request an dich 
geschickt.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> bitte das neue .ino im anhang.
>
> Anbei das log dazu. Da aber erst mal gar nichts passiert ist, habe ich
> doch Wifi zugeschaltet.
>
> Jetzt kann man auch besser erkennen, wie die (m.E. zu) wenigen Messages
> in etwa reinkamen. Wenn nicht verändert, macht FHEM ca. alle 5 Min. ein
> publish.
>
> Kurzfassung: Beide Kanäle werden ausgewertet, aber es sind zu wenige
> Datenpunkte und das "Beiwerk" ist komisch. Effektiv was empfangen wird
> mehr oder weniger nur, wenn auch WiFi läuft, warum auch immer.
>
> Habe die effektiv verwendeten Parts dann auch per pull request an dich
> geschickt.

das ist interresant, dass mit wifi "mehr" empfangen kannst, bei mir ist 
das genau umgekehrt!
die daten sind irgendwie in der luft zu fest gestört, darum mit 
CHECK_CRC=1 siehst du selten etwas.

wenn du mein letztes .ino verwendest:
- wir sehen welche und wie viele daten nicht plausibel sind
- in settings.h WITHMQTT = 0 stellen, dann sollten diese meldg. nicht 
mehr kommen:
Attempting to connect to the MQTT broker: 192.168.2.2
MQTT connected = 0
Subscribing to topics..

so haben wir "saubere" logs.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> die daten sind irgendwie in der luft zu fest gestört, darum mit
> CHECK_CRC=1 siehst du selten etwas.

Na ja, hier läuft halt "alles" zusammen: WLAN, BT, ZigBee, (selten 
MiLight) und nun eben (wieder) nRF24. Habe den CRC-Check jetzt mal 
ausgeschaltet und lass das Ding auch über Nacht laufen, eigentlich 
sollte kaum noch was vom WR kommen (vorhin waren 7 Watt oder so).
Der MQTT-Import-Code hat übrigens eine Macke: Immer wenn es eine Stelle 
weniger wird, bleiben die hinteren stehen, aus 101 => 98 werden dann 
981W (leider nicht in der Realität...)

[Carsten B. (carstenb)]

Manuel M. schrieb:
> Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry
> über MQTT.
>
> Mir sind zwei Dinge aufgefallen:
> 1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche
> Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel
> vom Wert des 2. Channels sofort überschrieben.

Hallo Manuel,

hast du es in FHEM eigentlich noch hinbekommen? Ich kann die Daten 
meiner beiden Wechselrichter und der Channels nicht unterscheiden im 
Fhem. Ich bin allerdings auch totaler Noob, was MQTT angeht. Hast du 
vielleicht ein Beipiel für mich aus deiner Konfig? Oder eine gute 
Quelle, wo ich mich dazu einlesen kann?

Gruß

Carsten

[Jörg R. (rejoe2)]

Carsten B. schrieb:
> hast du es in FHEM eigentlich noch hinbekommen?

Es gibt einen ersten attrTemplate-Vorschlag dazu im FHEM-Forum. Bitte 
ggf. da anhängen.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> die daten sind irgendwie in der luft zu fest gestört, darum mit
> CHECK_CRC=1 siehst du selten etwas.

....da scheint wirklich viel los zu sein, hier mal ein Auszug von dem, 
was ohne CRC-Check vorhin los war. Habe dazu mal PA_MIN eingestellt und 
bin dann etwas weiter weg, dann war das besser.

CH23 00 1234567801 00C6 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF56001900CADB78ED 0
New CMD  ff     CH23 00 1234567801 00C6 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF56001900CADB78ED 0
CH23 00 1234567801 00C6 18 3  97 FFFFFFFF FFFDCD58 E6C6AA5D2A2151BFC20000000000000000 0
New CMD  97     CH23 00 1234567801 00C6 18 3  97 FFFFFFFF FFFDCD58 E6C6AA5D2A2151BFC20000000000000000 0
CH23 00 1234567801 0080 10 0  89 6FFFFFFF FF4AD0B5 68A85A6C99A45551FF 0
CH23 00 1234567801 00DF 1B 3  FD FFFFFFFF FF7EFFFF FFFFFFFFFFFFFFFFF754001900C9DC20553FFFFF 0
New CMD  fd     CH23 00 1234567801 00DF 1B 3  FD FFFFFFFF FF7EFFFF FFFFFFFFFFFFFFFFF754001900C9DC20553FFFFF 0
CH23 00 1234567801 00C3 18 1  FF FFF02D76 AAAD1CA2 4AA2BED62EC38AFF820000000000000001 0
New CMD  ff     CH23 00 1234567801 00C3 18 1  FF FFF02D76 AAAD1CA2 4AA2BED62EC38AFF820000000000000001 0
CH23 00 1234567801 00FF 1F 3  FF FFFFF4BA 6A8A96F6 AC2A4985F55A3FA40000000000000000000B25ADC9000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFF4BA 6A8A96F6 AC2A4985F55A3FA40000000000000000000B25ADC9000000 0
CH23 00 1234567801 00C4 18 2  9F FFFFFFF7 FFFFFD4A 552EAB8B15496A27F90000000000000000 0
New CMD  9f     CH23 00 1234567801 00C4 18 2  9F FFFFFFF7 FFFFFD4A 552EAB8B15496A27F90000000000000000 0
CH3 00 1234567801 0082 10 1  91 7FFFFBFF FFFFFFFF EFFE5A94B1AC505550 0
CH3 00 1234567801 00C2 18 1  91 67FFFFFF FFFFFFEB FFFFFFFFFFFFC8ADA4FF00000000000000 0
CH3 00 1234567801 00C4 18 2  89 7FF7FFFF FFFDFFFF FDFFFBFFFFFFFFDFFFFFFFAB00CCB19974 0
CH23 00 1234567801 00C4 18 2  9F FFFFFFFF FBFFFFFF FFFFDFFFFFFFFFFFFFFF400900CCB1997C 0
New CMD  9f     CH23 00 1234567801 00C4 18 2  9F FFFFFFFF FBFFFFFF FFFFDFFFFFFFFFFFFFFF400900CCB1997C 0
CH23 00 1234567801 00FF 1F 3  FF D852A545 52AEA8A4 694B45502AEA8DF500000000000000000032B2CAA5000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF D852A545 52AEA8A4 694B45502AEA8DF500000000000000000032B2CAA5000000 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
CH23 00 1234567801 01FB 3F 1  FF FFFFFFFF BFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FB 3F 1  FF FFFFFFFF BFFFFFFF Ill remain 56
CH3 00 1234567801 00C6 18 3  91 6011FFFF FFFFFFFF FFFFFFFFFFF495584BA3FE100000000000 0
CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFDFFFFFFFF7FFFFFB7C000900CDA831F13FFFFFFF000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFDFFFFFFFF7FFFFFB7C000900CDA831F13FFFFFFF000000 0
CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFE6B7FC0000000000000000002CA552 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFE6B7FC0000000000000000002CA552 0
CH23 00 1234567801 00FF 1F 3  EF F663A89A 9394B692 AAB52652AA693FD000000000000000000036D54A65000000 FE5F FE5F 42D1 42D1 80
New CMD  ef     CH23 00 1234567801 00FF 1F 3  EF F663A89A 9394B692 AAB52652AA693FD000000000000000000036D54A65000000 0
CH23 00 1234567801 00DF 1B 3  FF FF5368B6 F6AA70EB B5120A32DBA627F80000000000000000002916AD 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FF5368B6 F6AA70EB B5120A32DBA627F80000000000000000002916AD 0
CH23 00 1234567801 00C0 18 0  8F FFFFFFFF FFFFFFFF FFE2EA98A5359EB7F90000000000000000 0
WRInfo(0x8f) is ok CMD 8f WR ff:ff:ff:ff HWPN: 255.226 HWVers: 234.152 APPFVers: 165.53 GPFCode: 158.183 GPFVers:: 249.0 0
New CMD  ff     CH23 00 1234567801 00CF 19 3  FF FFFD74E5 DCA9152A FB6ADBA54AA9ABFD00000000000000000037 0
CH3 00 1234567801 0080 10 0  91 67FFFFFF DFFFFFFF FFF7FFFFFFFFFFFFFD 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFB FFFFF3AC Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFB FFFFF3AC Ill remain 56
CH23 00 1234567801 00C0 18 0  91 7FFFFFFF FEFFFFFF FFFFFFD2D6A3AD5AD7FA00000000000000 0
CH23 00 1234567801 00C0 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFDA801B00CDC0F2F8 0
New CMD  ff     CH23 00 1234567801 00C0 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFDA801B00CDC0F2F8 0
CH23 00 1234567801 00C3 18 1  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFFF501C00CDC3EEDE 0
New CMD  ff     CH23 00 1234567801 00C3 18 1  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFFF501C00CDC3EEDE 0
CH23 00 1234567801 00C7 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF6A000900CE8C38A4 0
New CMD  ff     CH23 00 1234567801 00C7 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF6A000900CE8C38A4 0
CH23 00 1234567801 00C0 18 0  89 FFFFFFFF 7EFFFFFF FFFDFFFFFFFFFBFFFFFFD40900CE8C1032 0
CH23 00 1234567801 00C1 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFEA800900CE8C1032 0
New CMD  ff     CH23 00 1234567801 00C1 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFEA800900CE8C1032 0
CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFAD94AB0AAACFF60000000000000000002A556B56000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFAD94AB0AAACFF60000000000000000002A556B56000000 0
CH23 00 1234567801 00C6 18 3  9F FFFFFFFF FFFEFFFF FFFFFFFFFFFFFFFFFFFF401D00CEFA703D 0
New CMD  9f     CH23 00 1234567801 00C6 18 3  9F FFFFFFFF FFFEFFFF FFFFFFFFFFFFFFFFFFFF401D00CEFA703D 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FD514615 A245A5890A11D3FE0000000000000000002A8A4A 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FD514615 A245A5890A11D3FE0000000000000000002A8A4A 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
CH23 00 1234567801 00FE 1F 3  FF FEF7F7FF FFFFDFFF FFFFFFFFFFFFBFFFFBA3000A00CF63A3273FFFFDFF000000 0
New CMD  ff     CH23 00 1234567801 00FE 1F 3  FF FEF7F7FF FFFFDFFF FFFFFFFFFFFFBFFFFBA3000A00CF63A3273FFFFDFF000000 0
CH23 00 1234567801 00FF 1F 3  FF FFBFFFFF FFFFF7FF FFFDFFDFFFFFFFFFF770001E00CEEE549A3F4AAC94000000 2 CA72 6B2A 6B2A 39E80
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFBFFFFF FFFFF7FF FFFDFFDFFFFFFFFFF770001E00CEEE549A3F4AAC94000000 0
CH23 00 1234567801 00CF 19 3  FF FFFFFFFF F5FFFFFB FFFFFFFFFBFFABFF00000000000000000026 0
New CMD  ff     CH23 00 1234567801 00CF 19 3  FF FFFFFFFF F5FFFFFB FFFFFFFFFBFFABFF00000000000000000026 0
CH23 00 1234567801 00C3 18 1  FF FFFFFFFF 7FF7FFFF FFFFDFEFFFFFFDFFFFB5000A00CE7F92CE 0
New CMD  ff     CH23 00 1234567801 00C3 18 1  FF FFFFFFFF 7FF7FFFF FFFFDFEFFFFFFDFFFFB5000A00CE7F92CE 0
CH23 00 1234567801 00FF 1F 3  FA CD55D16D 6DBEB652 AF1FA155634594FF4100000000000000002B92DAA8000000 0
New CMD  fa     CH23 00 1234567801 00FF 1F 3  FA CD55D16D 6DBEB652 AF1FA155634594FF4100000000000000002B92DAA8000000 0
CH23 00 1234567801 00C2 18 1  8F FDFFDFDF FFFFBFFF FBFFBFEFFFFFFFFFFFFA800A00D066505D 0
WRInfo(0x8f) is ok CMD 8f WR ff:ff:bf:ff HWPN: 251.255 HWVers: 191.239 APPFVers: 255.255 GPFCode: 255.255 GPFVers:: 255.20
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FDFFEFFF 556AA4B53B3A9FFA0110000000000000003BBFA9BE000000 0
CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFC6D510 8D5A9C84500F6FF80000000000000000003D4A75 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFC6D510 8D5A9C84500F6FF80000000000000000003D4A75 0
CH23 00 1234567801 01FF 3F 3  FF FF504144 8500A452 Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FF504144 8500A452 Ill remain 56

Werde bei Gelegenheit wirklich nochmal neue Hardware aufbauen, irgendwie 
ist das zu wackelig, was ich grade da habe.

[Ha F. (harry_f)]

Für alle die, die die MQTT-Struktur für SubCMD 11 PowerLimit suchen.
Diese muss man selbst anlegen.

Ich benutze den IoBroker. Manchmal funktioniert die Umwandlung der 
Payload in Integer nicht korrekt.
Bsp:  Eingabe 600  und im WebIF steht dann 60000W.

[Ha F. (harry_f)]

Nachtrag zu obigen Post zum Power Limit:

Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max 
Leistung des WR.

Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W.
Es sollte 50.0% von X MaxWatt lauten.

Kann das jemand so bestätigen?

[Günter H. (gnter_h534)]

Ich betreibe einen HM600 z. Z. mit einem Modul.

Wenn ich unter 0.5.4 im Setup 150 W Limit einstelle, ist das Limit für 
das eine Modul 75W.

Mit Limit 600 W waren zu diesem Zeitpunkt ca. 230 W für ein Modul 
möglich.

[Frank L. (guilligan)]

Ha F. schrieb:
> Nachtrag zu obigen Post zum Power Limit:
>
> Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max
> Leistung des WR.
>
> Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W.
> Es sollte 50.0% von X MaxWatt lauten.
>
> Kann das jemand so bestätigen?

Ich kann das nicht bestätigen.
.../devcontrol/0/11 500   >>>bringt bei mir das 500 Watt Limit.

[Ha F. (harry_f)]

Ha F. schrieb:
> Nachtrag zu obigen Post zum Power Limit:
>
> Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max
> Leistung des WR.
>
> Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W.
> Es sollte 50.0% von X MaxWatt lauten.
>
> Kann das jemand so bestätigen?

Ok jetzt ist bei mir das Ergebnis anders wie oben beschrieben.
Jetzt regelt der WR mit dem Wert 300 (aus MQTT) auf 300W 
Ausgangsleistung (+-)

Irgendwie war durch vorherige Experimente das Verhalten heute morgen 
anders.

Oder kann man das irgendwie steuern ob Watt oder % Limitierung?

[Friedhelm E. (fritsche)]

Hallo,
@hubi
Habe die letzte Version Deiner SW aufgespielt, funktioniert sehr gut.
Da ich aber inzwischen einen weiteren HM-800 habe, frage ich mich, wie 
man den
2.WR im Setting einbinden kann. Habe die Anzahl der WR auf 2 eingestellt 
und die Daten für den 2.WR als HM-600 eingegeben. Konnte alles 
programmieren , aber auf die Channelabfrage kommt keine Antwort. Die 
Einzelabfrage vom 1.WR und vom 2.WR funktioniert. Bitte um Hilfe.

einen guten Tag
fritsche

[Gerald R. (visitor)]

Günter H. schrieb:
> Wenn ich unter 0.5.4 im Setup 150 W Limit einstelle, ist das Limit für
> das eine Modul 75W.

Das kann ich bestätigen, ist bei meinem HM 800 auch so.
Leistung pro Eingang = gedrosselte Leistung / 2
Hier wird vermutlich die Gesamtleistung limitiert und intern vom 
Wechselrichter durch die Anzahl der Eingänge dividiert.

[Klaus H. (klahi)]

Gerald R. schrieb:
> Das kann ich bestätigen, ist bei meinem HM 800 auch so.
> Leistung pro Eingang = gedrosselte Leistung / 2
> Hier wird vermutlich die Gesamtleistung limitiert und intern vom
> Wechselrichter durch die Anzahl der Eingänge dividiert.
Das wäre schon wichtig, ob die Ausgangsleistung oder an den Eingängen 
begrenzt wird. Mein Plan mit Ost-West Ausrichtung bräuchte eine 
Begrenzung der Ausgangsleistung. Wenn die Westsonne kräftig scheint, 
möchte ich bis 600W vom Westen nutzen und nicht maximal 300W vom Westen 
und nicht vorhandene 300W vom Osten.
Kann mich da jemand beruhigen?

[Hubi (Gast)]

Friedhelm E. schrieb:
> Konnte alles
> programmieren , aber auf die Channelabfrage kommt keine Antwort. Die
> Einzelabfrage vom 1.WR und vom 2.WR funktioniert. Bitte um Hilfe.

Sorry, das Problem hatte ich schon mal letzte Seite von diesem Thread 
und dachte es wäre gelöst. Ich hatte das mit einer Simulation versucht 
zu lösen,  1WR mit 2 setups und dann jeweils simulierte Serials, und das 
hat auch geklappt. im Moment weiß ich nicht wie ich dir weiterhelfen 
kann, habe eben nur 1 WR. Ich versuche nochmals das ganze zu simulieren.

[Dirk S. (fusebit)]

Habe jetzt meine Panels bekommen.
Ahoy läuft jetzt auf einem RasPi Zero.
Auch mein HM-300 antwortet erst nachdem er 30 Minuten aktiv ist.

Ab jetzt kann ich gerne mithelfen, für mehr als beta-Test reichen meine 
Programmierfähigkeiten aber nicht aus.

[Ha F. (harry_f)]

Klaus H. schrieb:
> Gerald R. schrieb:
>> Das kann ich bestätigen, ist bei meinem HM 800 auch so.
>> Leistung pro Eingang = gedrosselte Leistung / 2
>> Hier wird vermutlich die Gesamtleistung limitiert und intern vom
>> Wechselrichter durch die Anzahl der Eingänge dividiert.
> Das wäre schon wichtig, ob die Ausgangsleistung oder an den Eingängen
> begrenzt wird. Mein Plan mit Ost-West Ausrichtung bräuchte eine
> Begrenzung der Ausgangsleistung. Wenn die Westsonne kräftig scheint,
> möchte ich bis 600W vom Westen nutzen und nicht maximal 300W vom Westen
> und nicht vorhandene 300W vom Osten.
> Kann mich da jemand beruhigen?

Evlt hilft es:

Setup:
Version 0.5.4
HM-600    2x  340Wp Ost/West

Hab mal Bilder gemacht. Man beachte den Unterschied zwischen 300W und 
100W Limit auf den einzelnen Seiten.

[Jörg R. (rejoe2)]

Liest hier eigentlich noch jemand mit von den anderen "MI"-Besitzern?
Es müßte ja neben Ziyat T und mir noch ca. eine Handvoll geben, die WR 
mit "10"-er Seriennummern haben.
Die "ino3" von Ziyat T. ist jedenfalls bereits so ausgelegt, dass man 
neben diversen Zugangsdaten "nur" den WR-Grundtyp passend einstellen 
muss, also falls jemand das bisher frustriert in die Ecke gelegt hatte: 
Welcome on board again!

Irgendwo hier war zu lesen, dass man unbedingt einen nRF24L01+ 
benötigen würde. Wenn meine Interpretation von 
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners 
zutreffend ist, müßte eigentlich auch die "neue Generation" 
(insbesondere nRF52) noch das alte "shockburst"-Protokoll beherrschen, 
so dass z.B. ein E73-Board von Ebyte ebenfalls als Transceiver genutzt 
werden könnte. Ein paar der nRF52-Varianten beherrschen übrigens auch 
ZigBee, so dass man damit ggf. auch eine Art "Universalgateway" basteln 
könnte, das dann auch die APSystems-WR ansprechen könnte... (Siehe 
https://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Briefs/nRF52832-product-brief.pdf, 
Tabelle auf S. 1)

Habe gestern übrigens noch etwas gelötet, einen anderen ESP geflasht und 
das "gute" 100mW-nRF24 mit shield ausgepackt - das halft alles nichts, 
die empfangenen Packete sind weiter zum großen Teil einfach kaputt. 
Zwischenzeitlich hätte ich auch eine Theorie anzubieten, warum das so 
ist: Mein "Testort" befand sich meistens (leicht schräg, aber) _direkt 
unter der Unterseite_ des MI. Der hat aber keine externe Antenne, also 
muss das Signal nicht nur durch das Gehäuse, sondern ggf. auch "durch" 
das ganze sonstige Elektro-Material => nicht optimal. Vermutlich sind 
die so aufgebaut, dass die auch eher "zur Seite hin" optimiert 
abstrahlen: Die nRF beherrschen ja auch Mesh, und wenn man (wie in den 
Prospekten gezeigt) größere Flächen damit abdecken möchte, muss man ggf. 
eben zwischendurch einen anderen nRF als "Zwischenstation" nutzen. Dazu 
paßt ja auch, dass man immer zwei Adressen übermittelt bekommt: Die 
Sender-Adresse und die des "letzten hop" (so kann man das übrigens auch 
bei MySensors-Repeatern beobachten). Da wir meistens eine direkte 
Kommunikation sehen entspricht der letzte hop einfach der des Senders.

Werde das bei Gelegenheit mal testen, ob ich einen besseren Platz zum 
längerfristigen Testen finde, jedenfalls waren die Zwischenresultate auf 
der Terrasse eher besser als direkt unter dem MI. Für's weitere Testen 
ist eh' der Plan, den Verkehr über ein ausrangiertes MySenors-GW auf 
Arduino-Nano-Basis zu sniffen und den ESP vor sich hin tuckern zu 
lassen... (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach 
den 10-fachen Messwert).

Wird aber dauern, bis wieder Zeit ist, das etwas intensiver zu 
beleuchten (daher auch meine Frage nach weiteren Usern, die ggf. jetzt 
wieder einsteigen möchten).

[Friedhelm E. (fritsche)]

Hallo,
Hubi(Gast) schrieb: 1WR mit 2 setups und dann jeweils simulierte Serials
Habe die setting.h so abgeändert:
#define MAX_ANZ_INV             2

#include "Inverters.h"

#if MAX_ANZ_INV >= 1
#include "HM600.h"
#define WR1_NAME "HM-600"
#define WR1_SERIAL 0x1141xxxxxxxxULL
#define WR1_MEASUREDEF hm600_measureDef
#define WR1_MEASURECALC hm600_measureCalc
#define WR1_FRAGMENTS hm600_fragmentLen
uint16_t WR1_MODULEPEAKS[] = {2, 370, 370};
#endif

// Beispiel für 2. WR
#if MAX_ANZ_INV >= 2
#include "HM600.h"
#define WR2_NAME "HM-600"
#define WR2_SERIAL 0x1141yyyyyyyyULL
#define WR2_MEASUREDEF hm600_measureDef
#define WR2_MEASURECALC hm600_measureCalc
#define WR2_FRAGMENTS hm600_fragmentLen
uint16_t WR2_MODULEPEAKS[] = {2, 370, 370};
#endif
Ich bin mir nicht sicher ob Du das so gemeint hast.
Ist noch eine Eingabe für den 2ten WR notwendig?

Grüße
Fritsche

[Hubi (Gast)]

Friedhelm E. schrieb:
> Ich bin mir nicht sicher ob Du das so gemeint hast.
> Ist noch eine Eingabe für den 2ten WR notwendig?

Eigentlich ist sonst nichts zu machen, wenn du 2xHM600 hast, außer den 
Namen des 2.WR ändern, damit du unterscheiden kannst.
Den Bug habe ich gefunden, warum es mit 2 nicht funzt.
Ändere mal in der loop() die Zeile
  if ((packetBuffer.available() >= totalFragments && packetsComplete())

in
  if ((packetBuffer.available() >= inverters[aktWR].fragmentCount && 
packetsComplete())

ab, dann sollte es gehen. Wenigstens bei mir hat das in der Simulation 
mit 1 WR geklappt.
Änderung ist auch in meinem github drin.

[Klaus H. (klahi)]

Von Ha F.

>Setup:
>Version 0.5.4
>HM-600    2x  340Wp Ost/West
>
>Hab mal Bilder gemacht. Man beachte den Unterschied zwischen 300W und
>100W Limit auf den einzelnen Seiten.

Vielen Dank. Ich bin beruhigt :-) Die Leistungsbegrenzung wirkt auf die 
Leistung am Ausgang "P_AC", nicht auf die Leistungen der Eingänge 
"P_DC".

Zwar gibt es leichte Unterschiede zwischen der Summe aller P_DC und 
P_AC. Das kann durch interne Wandlungsverluste, Messfehler oder 
unterschiedliche Zeitpunkte der Datenabfrage verursacht sein. Das macht 
mir keine Gedanken.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Irgendwo hier war zu lesen, dass man unbedingt einen nRF24L01+
> benötigen würde. Wenn meine Interpretation von
> https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners

ich hab beim nordic/devzone auch gelesen:
"The nRF52 is capable of 255-byte payloads in both SB and ESB modes"

>
> Habe gestern übrigens noch etwas gelötet, einen anderen ESP geflasht und
> das "gute" 100mW-nRF24 mit shield ausgepackt - das halft alles nichts,
> die empfangenen Packete sind weiter zum großen Teil einfach kaputt.
> Zwischenzeitlich hätte ich auch eine Theorie anzubieten, warum das so
> ist: Mein "Testort" befand sich meistens (leicht schräg, aber) _direkt
> unter der Unterseite_ des MI. Der hat aber keine externe Antenne, also
> muss das Signal nicht nur durch das Gehäuse, sondern ggf. auch "durch"
> das ganze sonstige Elektro-Material => nicht optimal. Vermutlich sind
> die so aufgebaut, dass die auch eher "zur Seite hin" optimiert
> abstrahlen:

ja, kann es bestaetigen, direkt unter MI ist weniger empfang

 (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach
> den 10-fachen Messwert).
 das habe ich nicht verstanden?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ich hab beim nordic/devzone auch gelesen:
> "The nRF52 is capable of 255-byte payloads in both SB and ESB modes"
grins - die Frage ist nur, ob einen das wirklich weiterbringt...
Der E73, der hier rumliegt (weil ich erst dachte, "nordic proprietäry 
wäre vielleicht "Gazelle") ist zwar schön anzusehen, aber vermutlich 
schwieriger zu handhaben wie ein einfacher nRF24L01+ (wenn man denn 
keinen fake erwischt!), weil er die (M4?-) MCU gleich mitbringt, dafür 
aber kein WLAN oä...

> ja, kann es bestaetigen, direkt unter MI ist weniger empfang
Na dann bin ich mal positiv gespannt, wie das bei meinem nächsten 
Test-Ort sein wird und ob die "kleinen" (ohne pa etc.) dann doch 
tauglich/ausreichend sind!

Was den Teil der eigentlichen Auswertungen angeht, scheinen wir ja an 
sich soweit zu sein, dass man (ggf. abgesehen von einem gewissen 
Restbestand von echten "new CMD"-Funden beim Sniffen) versuchen könnte, 
den jetzigen Code als "mi-"Bibliotheken in den "ahoy-ESP" einzubinden?
Denn wenn was mit passendem CRC empfangen wurde, war auch die Anzeige im 
Web-Interface soweit ok.
Für's sniffen wäre dann der Arduino das Mittel der Wahl. Oder wie siehst 
du das?

Zugegebenermaßen hat das bisherige Starren auf die NRF24_SendRcv.ino 
(deine V3) einerseits und ahoy/tree/main/tools/esp8266 andererseits 
bisher nicht dazu geführt, dass das Licht besonders hell geworden wäre. 
Immerhin gibt es auch bei hmSystem.h drei (anhand der Seriennummer 
unterschiedene) Klassen von WR. Den Part könnte man also vermutlich 
recht einfach übernehmen, und auch die Nummernbereiche sollten (lt. der 
Excel-Seriennummern-Liste) soweit passen, aber dann....?!?

Vielleicht möchte doch einer der C++-Cracks hier den Versuch unternehmen 
nachobenschau - ich teste herzlichst gerne und habe aktuell auch 3x 
Hardware zur Verfügung (2*D1 mini, 1 Nano)?

>  (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach
>> den 10-fachen Messwert).
>  das habe ich nicht verstanden?
War mir nicht ganz sicher, welche Gründe es gab, unbedingt den MQTT-Teil 
abzuschalten und hatte dann vermutet, dass du darüber vielleicht die 
Leistungsvorgabe machst, was dann eben meinen MI unnötig ausgebremst 
hätte (weil ich da den laufenden Messwert reingeschubst habe). Daher der 
Gedanke, den sicherheitshalber (ohne weitere Code-Analyse) ausreichend 
hoch zu setzen, ohne auf "Aktualität" in der Web-Anzeige verzichten zu 
müssen.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> den jetzigen Code als "mi-"Bibliotheken in den "ahoy-ESP" einzubinden?

das ist wiederum nicht so ganz einfach, zuerst müssen die parser (tx/rx) 
angepasst werden, weil bei den MI's, 2 verschiedene (MI300/600 und 
MI1000/1500) völlig andere tx/rx msgs sind. da müsste grundsaetzlich im 
ahoy-esp etwas geschehen und der adressat ist mmn "isnoahoy" Stefan. den 
rest könnten wir schon noch reinkriegen.
(edit: muss sagen, dass ich die letzte version von ahoy-esp nicht 
angeschaut habe)
>
>>  (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach
>>> den 10-fachen Messwert).
>>  das habe ich nicht verstanden?
> War mir nicht ganz sicher, welche Gründe es gab, unbedingt den MQTT-Teil
> abzuschalten und hatte dann vermutet, dass du darüber vielleicht die

du kannst mqtt laufen lassen, wenn ZEROEXP=0 ist, wird die topic 
"ImpExpW" nicht mehr abonniert, also keine limitierung über 
mqtt/gridmeter

[IsnoAhoy (Gast)]

Hallo Ziyat T. und Joerg R,
Ja es ist tatsächlich so dass da noch etwas auf Ahoy Seite passieren 
müsste um die ein/zwei/vier Commands für die MI-300/MI-600/MI-1200 
Wechselrichter abzufragen. Aktuell haben wir nur das Gen3 Protokoll mit 
Single und MultiFrame Antworten implementiert.
Die Gen2 Kommandos sind idR alles Single Frame Antworten und somit kann 
die CRC16 Prüfsumme über mehrere Pakete unterbleiben. Aber wir müssen 
immer je 1/2/4 Antworten die Pakete häppchenweise in den Strukturen 
ablegen, das ist etwas anders als bei HM-Wechselrichtern bei denen wir 
ja immer alle Werte aus der Gesamtpayload ablegen.
Wie man das am besten macht bin ich auch ein wenig überfragt, aber macht 
doch mal einen Anfang in Form einer miInverter.h und miSystem.h etc.
Wir müssen wie gesagt auch eine miRadio.h und/oder eine miApp.cpp 
anlegen da sich hier die Gen2 und Gen3 Protokolle ein wenig üebrlappen / 
beissen ??
@Lukas und @Andreas S. wir wollen doch auch den Ahoy Code refaktorieren 
damit er mit OpenDTU gemeinsam genutzt werden kann… wäre das nicht ein 
erster Schritt: die app.cpp aufräumen und alles was mit Kommunikation 
mit dem WR an Protokoll/Kommandos da aktuell drin ist wieder auslagern 
in eine hmGen3.cpp und dann eine miGen2.cpp die vielleicht beide ein 
ähnliches Interface haben ?

[Joachim (Gast)]

Ich würde mich über Hinweise freuen, was bei mir falsch laufen könnte. 
Habe den D1 mini laufen, inzwischen produziert der HM-600 auch Strom 
(blinkt im Sekundentakt grün). Abstand D1 zum WR etwa 5m, was ja 
eigentlich kein Problem sein dürfte. Im Setup sollte alles stimmen, die 
SN ist korrekt. Allerdings kann er sich immer noch nicht verbinden:
I: Requesting Inverter SN 114172015695
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
I: Inverter #0 I: no Payload received! (retransmits: 5)

Ich hatte vorher schon die länger gebaute Antenne dran, hab auch mal D3 
und D4 getauscht, alles ohne Erfolg. Hatte die gleiche Situation bereits 
auf sehr kurzer Distanz, allerdings hing der WR damals noch nicht am 
Hausnetz. Momentan ist die eher quadratisch gebaute Antenne dran. 
Danke!!

[Jörg R. (rejoe2)]

Wie man (wiederholt) sieht, ist Stefan an Bord *grins*:

Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?):
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50

Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als 
"Objekte" definiert, die dann auch - je nach Modell - intern einfach 
unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen 
gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden 
Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das 
ganze in diese Richtung angelegt?

Wobei auf die Schnelle die einzige Stelle, in der das bei den HM's eine 
Auswirkung hat die Funktion "getAssignment" zu sein scheint, dort z.B. 
die Unterscheidung in 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmInverter.h#L203
Vermutlich schließt sich daran noch weiteres in der cpp-File an, aber 
wie gesagt: Orientieren im Code geht halbwegs, aber dann wird es schnell 
dünne...

Bedeutet, man würde praktisch erst mal so anfangen, dass man statt der 
hm.*.h's (bzw. cpp-Files) einfach Klone anlegt und die dann an den 
entsprechenden Stellen anpaßt...? Ufff...

Na ja, immerhin könnte man so ggf. dann wenigstens eine fertige firmware 
(MI-Version) mit "backen" lassen...

> du kannst mqtt laufen lassen, wenn ZEROEXP=0 ist, wird die topic
> "ImpExpW" nicht mehr abonniert, also keine limitierung über
> mqtt/gridmeter
ZEROEXP war die ganze Zeit auf 0, aber der ESP wollte den Wert trotzdem 
- was aber auch völlig egal ist, solange nicht weitere Tester hier an 
Bord sind. Ich weiß, wie mit dem Thema umzugehen ist, und habe 
zwischenzeitlich (neben dem "NOMQTT"-Schalter) auch noch eine weitere 
Code-Stelle ausgemacht, an der man die lästigen Connecting-to-Meldungen 
ausschalten kann.

MQTT könnte übrigens hilfreich sein, um einfach auf diesem Weg 
"unbekannte CMD"-Messages zu loggen. Z.B. einfach dieses Reading dann in 
FHEM loggen und gut ist - dann hat das ganze auch gleich einen 
Zeitstempel...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Wie man (wiederholt) sieht, ist Stefan an Bord *grins*:
>
> Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?):
> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50
>
> Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als
> "Objekte" definiert, die dann auch - je nach Modell - intern einfach
> unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen
> gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden
> Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das
> ganze in diese Richtung angelegt?

es geht in erster linie nicht um das definieren der 2.gen wr, sondern um 
den mechanismus der single frame 1/2/4 antworten und wie man die mit den 
3.gen wr antworten zusammen abarbeitet. gleiches gilt für die request 
meldungen. wie stefan auch geschrieben hat, da müssen sie zuerst mal 
"platz schaffen" und ein sw-interface für die 2.gen zur verfügung 
stellen.

>
> MQTT könnte übrigens hilfreich sein, um einfach auf diesem Weg
> "unbekannte CMD"-Messages zu loggen. Z.B. einfach dieses Reading dann in
> FHEM loggen und gut ist - dann hat das ganze auch gleich einen
> Zeitstempel...
ja sicher könnte man, i.d.regel wenns richtig laeuft sollten keine 
"unbekannte CMD" kommen

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:
> Hallo Ziyat T. und Joerg R,
> Ja es ist tatsächlich so dass da noch etwas auf Ahoy Seite passieren
> müsste um die ein/zwei/vier Commands für die MI-300/MI-600/MI-1200
> Wechselrichter abzufragen. Aktuell haben wir nur das Gen3 Protokoll mit
> Single und MultiFrame Antworten implementiert.
> Die Gen2 Kommandos sind idR alles Single Frame Antworten und somit kann
> die CRC16 Prüfsumme über mehrere Pakete unterbleiben. Aber wir müssen
> immer je 1/2/4 Antworten die Pakete häppchenweise in den Strukturen
> ablegen, das ist etwas anders als bei HM-Wechselrichtern bei denen wir
> ja immer alle Werte aus der Gesamtpayload ablegen.
> Wie man das am besten macht bin ich auch ein wenig überfragt, aber macht
> doch mal einen Anfang in Form einer miInverter.h und miSystem.h etc.

man könnte sich zuerst ein high-level kommunikation interface überlegen, 
das alle wr-typen verstehen: z.B. get_data,set_data,get_status usw.

darunter quasi je einen spez. driver für jedes modell, 2.gen a b c, 
3.gen a b c etc.

[Frank L. (guilligan)]

Hi. Also die Limitierung mit 0.5.4 funktioniert gut. Hat jemand 
Erfahrung wie oft/schnell der hm mit Befehlen aus mqqt zu recht kommt 
und ob das Auswirkungen auf die Lebensdauer hat?
Ich meine kein Sekundengenaue Limitierung Aber so alle 15/30/45 
Sekunden.
Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein 
als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?
Echt super Sache bis jetzt und wer nur mitliest sollte es endlich 
ausprobieren. Ich bereue bis jetzt noch nichts.
VG Frank

[Ziyat T. (toe_c)]

Frank L. schrieb:
> Hi. Also die Limitierung mit 0.5.4 funktioniert gut. Hat jemand
> Erfahrung wie oft/schnell der hm mit Befehlen aus mqqt zu recht kommt
> und ob das Auswirkungen auf die Lebensdauer hat?
> Ich meine kein Sekundengenaue Limitierung Aber so alle 15/30/45
> Sekunden.
> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein
> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?
> Echt super Sache bis jetzt und wer nur mitliest sollte es endlich
> ausprobieren. Ich bereue bis jetzt noch nichts.
> VG Frank

- eine zeroexport funktion macht das ja immer
- der wr , zumindest die 2.gen wr, reagiert sofort, wenn der wr den mmpt 
suchen muss dann natürlich es dauert bisschen laenger

[Stefan T. (isnoahoy)]

Hallo Joachim,
Du kannst gerne mal D1/D2 ausprobieren, es gab Hinweise dass es damit 
klappt. Wenn Du die Pins tauschst dann auch das Setup anpassen.
Vielleicht auch zwischenrein mal MQTT abschalten, da es Vermutungen gibt 
dass PubSubClient uns immer noch in die Suppe spuckt.
Optional kann man auch das nRF24L01+ Modul mit einem 10/100uF Elko 
zwischen VCC & GND Pins des Moduls, ein bißchen besser für die 
notwendige Sendeleistung des kleinen Funkzwerges kompensieren.

[Stefan T. (isnoahoy)]

Hallo Jörg & Ziyat T.,

>> Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?):
>> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50
>>
>> Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als
>> "Objekte" definiert, die dann auch - je nach Modell - intern einfach
>> unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen
>> gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden
>> Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das
>> ganze in diese Richtung angelegt?

> es geht in erster linie nicht um das definieren der 2.gen wr, sondern um
> den mechanismus der single frame 1/2/4 antworten und wie man die mit den
> 3.gen wr antworten zusammen abarbeitet. gleiches gilt für die request
> meldungen. wie stefan auch geschrieben hat, da müssen sie zuerst mal
> "platz schaffen" und ein sw-interface für die 2.gen zur verfügung
> stellen.

Ja, das habt ihr beide richtig verstanden!
Die Implementierung einfach mal in miDefines.h, miInverter.h und 
miSystem.h vornehmen.
Dann für die Anpassungen am Protokoll miRadio.h anpassen. Hierzu müssen 
m.E. viele Code Teile die aktuell in app.cpp sind (warum eigentlich ?) 
und für die Abhandlung der einzelnen Kommandos bzw. Erstellung und 
Parsen der Pakete/Frames notwendig sind hierhin bzw. in hmRadio.h oder 
eine neue hmProtokoll.h und für Euch in eine miProtokoll.h ausgelagert 
werden.

Ich weiß nicht ob sich Lukas oder Andreas sich hieran beteiligen, den 
bestehenden Code mal aufzuräumen, aber wenn ihr schon mal die ersten 
drei miDefines/Inverter/System erstellen könntet, dann geht das andere 
bestimmt auch noch irgendwann.

[Rene M. (Firma: Bitte wählen) (renmo)]

Frank L. schrieb:

> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein
> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?


Bei mir dauert es schon eine Zeitlang bis der HM1500 reagiert. Ist aber 
auch schwer nachzuvollziehen, da Ahoy so selten die Werte ausliest und 
MQTT noch seltener.

Machst du die quasi Nulleinspeisung mit einem Blockly auf iobroker?

[Friedhelm E. (fritsche)]

Hallo,
@Hubi(Gast)
Habe die neue Version mit den entsprechenden Daten eingegeben und 
festgestellt das nur der WR1 dargestellt wird. Erst mit Änderung der 
define Anzahl WR = 2
hat er beide Tabellen ausgegeben.
Danke fürs Bearbeiten.
Ist schon etwas über eine Leistungsbegrenzung angedacht?
Hintergrund: Der 2te.WR soll auf dem 2ten. Eingang eine Akkueinspeisung 
bekommen, der entweder mit einer Leistungeinstellung im WR oder extern 
funktioniert. Die externe Strom-/Spannungsbegrenzung funktioniert 
bereits mit einem E-Bike Akku (36V). Eine WR interne Begrenzung wäre mir 
lieber.

wünsche einen guten Tag
fritsche

[Ziyat T. (toe_c)]

Stefan T. schrieb:
> Hallo Jörg & Ziyat T.,
>

hast du irgend ein klassen-diagram oder ablauf-diagram von ahoy-esp? 
oder verwendest du irgendein UML-tool?
dann könnte ich mal das ganze anschauen..

[Volker.B. (Gast)]

Hallo.

Was sagt eigentlich der Wert "ALARM_MES_ID" in der Ahoy Version 0.5.5 
aus?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> auf .....send res 0 ist kein verlass
Hmm, irgendwie läßt mich das nicht so ganz los....

Hatte jetzt testweise den Standort etwas verlagert, und ja, die Daten 
waren etwas besser, aber im Prinzip immer noch grottig. Anscheinend sind 
die ersten paar Bytes oft noch ok, aber je weiter nach hinten man kommt, 
desto zufälliger scheint das zu werden.
Da es "irgendwie" manchmal klappt, dürfte das ganze kein reines 
Hardware-Problem sein, sondern irgendwas anderes.

Hier mal die Schnippsel, die bei mir in meinem Laien-Verständnis vom 
Ganzen hängen geblieben sind:
- Manche haben in den frühen Sketchen gar kein Channel-Hopping 
vorgesehen, aber trotzdem Daten bekommen. Am "zufriedensten" scheinen 
die zu sein, die ein "poor man's channel hopping" machen (hab's nicht 
nachgeschlagen, was das konkret bedeutet);
- die auf den WR vercodeten Channels liegen in dem Bereich, in dem auch 
2.4GHz-WLAN rumfunkt (ab 86? wäre in der EU nicht mehr zulässig);
- eng nebeneinanderliegende Channels bedeuten Interferenzen;

Was wir mit dem MI-Sketch aktuell machen, ist "Dauer-Channel-hopping", 
"res = 1" kommt keinerlei Bedeutung zu. Das ist m.E. Teil des Problems, 
jedenfalls, wenn meine graue laienhafte Theoriewelt nicht komplett 
danebenliegt:
- Ein Hardware-ACK (das verbirgt sich hinter der "1") bedeutet doch, 
dass wir ein starkes Indiz dafür haben, genau den Channel erwischt zu 
haben, auf dem der WR grade lauscht?
- Wenn das so ist, sollten wir erst mal auf diesem Channel bleiben, 
sowohl, was das Senden wie auch das Empfangen angeht. Das würde die 
Chance erhöhen, dass der WR mit seinen Infos "durch den Nebel" kommt. 
Erst, wenn länger nichts sinnvolles kommt, fangen wir an, wieder einen 
passenden Kanal zu suchen. (Für das ganze Netz, wohlgemerkt, s.U.).

Die sehr kurze Gesamtdurchlaufdauer des Ganzen bis zum nächsten 
Gesamtdurchlauf scheint mir für den 4-Kanaligen ok zu sein, aber 
eigentlich läge mir eine Logik ala "jeden WR nur alle 5 Sekunden 
abfragen" näher. Würde bedeuten, dass man den "tickMillis" weniger 
statisch handhaben sollte: Wenn der WR "durch" ist, könnten es 5 
Sekunden sein, wenn der nächste Kanal abzufragen ist, kann man das m.E. 
eigentlich direkt (im Auswertungscode für die Antwort-Messages?) auf "0" 
setzen, oder?

Werde mal versuchen, den Sketch entsprechend anzupassen, das sollte noch 
im Bereich meiner Skills liegen.

Ach so, vielleicht noch zum gedanklichen Hintergrund des ganzen: An sich 
sieht ein MI/HM-"Netzwerk" nicht anders aus als das, was man unter 
https://www.mysensors.org/about/network findet. Sowas funktioniert 
erwiesenermaßen ganz ordentlich - (@MySensors-nRF) vorausgesetzt, man 
kann einen statischen Kanal festlegen, auf dem nichts anderes heftig 
rumfunkt. Nach meinem Verständnis dienen die mehreren festen Kanäle nur 
dazu, Ausweichmöglichkeiten zu haben, aber das eigentliche "Ziel" des 
Codes müßte eigentlich sein, sich für alle WR in diesem Netz auf einen 
Kanal zu einigen (ähnlich zu dem, was für WLAN gilt, nur dass da eben 
(prinzipiell) mehr Kanäle wählbar sind). Auf diesem teilt dann die DTU 
die "Sendezeiten" zu, was uU. auch mal bedeuten kann, etwas geduldiger 
zu warten, bis Nachrichten "aus dem letzten Eck" ihr Ziel erreicht 
haben.
Das findet sich aber m.E. in der MI-Fassung derzeit nicht so recht 
wieder, das ist mehr auf eine 1:1-Kommunikation angelegt, deren Gelingen 
wohl auch  davon abhängt, dass die äußeren Rahmenbedingungen in etwa 
gleich sind.

Kann aber natürlich sein, dass ich einmal mehr sehr auf dem Holzweg 
bin...

[Frank L. (guilligan)]

Rene M. schrieb:
> Frank L. schrieb:
>
>> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein
>> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?
>
> Bei mir dauert es schon eine Zeitlang bis der HM1500 reagiert. Ist aber
> auch schwer nachzuvollziehen, da Ahoy so selten die Werte ausliest und
> MQTT noch seltener.
>
> Machst du die quasi Nulleinspeisung mit einem Blockly auf iobroker?

nein über node red auf raspi. Quasi den Zähler im Schrank auslesen mit 
ir-lesekopf und dann verrechnen und über mqtt und wemos+nrf an die 
wechselrichter. iobroker hab ich nicht in Gebrauch.

[Günter H. (gnter_h534)]

Volker.B. schrieb:
> Was sagt eigentlich der Wert "ALARM_MES_ID" in der Ahoy Version 0.5.5
> aus?

Diese Frage hatte ich mir auch gestellt - auf Discord 
(https://discord.com/channels/984173303147155506/992031772328075375/1006955462580781217)

bekam ich diese Antwort:

drschiffler — gestern um 18:01 Uhr
Diese Zahl erhöht sich um 1 wenn eine neue Warnung bzw ein neuer Alarm 
hinzukommt. Welcher Alarm oder welche Warnung kann man noch nicht sehen

[Friedhelm E. (fritsche)]

Hallo,
@Hubi(Gast)
Habe einen eigenartigen Effekt festgestellt. Die Original SNr. werden 
abwechselnd mit der 1141 72600000 bei der Ausgabe auf dem Handy 
angezeigt,
sowohl bei WR1 als auch WR2. Die Daten im Ausgabefeld veändern sich 
nicht.
Soweit mein Testlauf.
einen guten Tag,
fritsche

[Joachim (Gast)]

Stefan T. schrieb:
> Stefan

Hallo Stefan, einen ganz großen Dank für Deinen Tipp, der war mir 
irgendwo auf den letzten Seiten wohl entgangen. Kurz: mit meinem D1 mini 
pro funktioniert die Antenne nur mit D1/D2 (CE/IRQ), nicht aber mit 
D3/D4. Muss ich weiter nicht verstehen, aber ich freue mich sehr, dass 
es endlich klappt! Großes Lob an alle (Mit-)Entwickler, ein klasse 
Projekt!

[Freddy (Gast)]

Hallo , erstmal vielen Dank das ihr eine so tolle Arbeit kostenlos zur 
Verfügung stellt . Ich bin begeistert .
Ich hoffe meine Fragen passen hier rein .
Ich habe einen HM 1200 auf 600w über das setup limitiert . Meine Frage 
ist , wie oft aktualisiert ahoy diesen Wert und überschreibt diesen im 
wr ?
Gibt es einen Wert mit dem man den wr wieder auf max limitieren kann ? 
Also wie auf Werkseinstellung.
Ihr seid da so hinterher mit den Verbesserungen und bug fix dass kaum 
nach kommt .
Danke

[Jörg R. (rejoe2)]

@MI-Mitleser:
Das mit dem "Beharren" auf einem Channel scheint jedenfalls besser zu 
funktionieren, bin ganz begeistert. Sogar mit dem "kleinen" nRF klappt 
es, die Daten zu empfangen, in minicom ist das Verhältnis Sende- zu 
Emfangszeilen sogar mit diesem Modul (HIGH-Sendelevel, CRC an (!)) 
gefühlt bei 4:1, mit dem geshieldeten (LOW) sogar 1:1 - und das am 
vermeintlich funktechnisch schlechtesten Ort...

Aus irgendeinem Grund hopt das Ding immer noch sendseitig (kommt das aus 
der hm-lib?) und den Status sieht man auch nicht (die "3"), vermutlich 
habe ich versehentlich was abgeschaltet, das das anfragt?

Aber als Zwischenergebnis dürfte es trotzdem interessant sein grins.

Hier noch ein paar Zeilen aus minicom (mit dem "kleinen"):

Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 013200180936138503170891017FF88FCA 1
CH: 3 PV0 MI: 157W Grd:1480W Lm:   0W 79.1W 30.6V 2.4A 2193Wh 235.8ACV 50.0Hz 38.3C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013200180938138502DE08B6017D034E92 1
CH: 3 PV1 MI: 152W Grd:1480W Lm:   0W 73.4W 30.6V 2.4A 2230Wh 236.0ACV 50.0Hz 38.1C S:0 
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 013200170938138502E30891017E0D062A 1
CH: 3 PV0 MI: 147W Grd:1480W Lm:   0W 73.9W 30.6V 2.3A 2193Wh 236.0ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013100170938138502BB08B6017D6A3144 1
CH: 3 PV1 MI: 143W Grd:1480W Lm:   0W 69.9W 30.5V 2.3A 2230Wh 236.0ACV 50.0Hz 38.1C S:0 
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 013200170936138402C00892017E22CDB4 1
CH: 3 PV0 MI: 140W Grd:1480W Lm:   0W 70.4W 30.6V 2.3A 2194Wh 235.8ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013200170936138302B908B6017E607A81 1
CH: 3 PV1 MI: 140W Grd:1480W Lm:   0W 69.7W 30.6V 2.3A 2230Wh 235.8ACV 50.0Hz 38.2C S:0 
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C4 18 2  89 60100013 60100013 013200180935138302BF0892017E569B95 1
CH: 3 PV0 MI: 140W Grd:1480W Lm:   0W 70.3W 30.6V 2.4A 2194Wh 235.7ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 0133001A0935138502DE0892017E32DDD6 1
CH: 3 PV0 MI: 143W Grd:1480W Lm:   0W 73.4W 30.7V 2.6A 2194Wh 235.7ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013300190936138502F908B7017C2A02F5 1
CH: 3 PV1 MI: 149W Grd:1480W Lm:   0W 76.1W 30.7V 2.5A 2231Wh 235.8ACV 50.0Hz 38.0C S:0 
Send... CH61 0960100013785634120062.....send res 0

[Frank L. (guilligan)]

Limitierung über mqtt
Ich habe heute noch ein wenig rum probiert wie eine "Nulleinspeisung" 
über mqtt funktionieren könnte.
Ergebnis: scheint zu viel traffic zu sein. Meine 2 WR (600 und 1500) 
reagieren nur sporadisch. Das "kleben" des Limits (Limit 6000W statt 
600) ist immer noch drin bei v0.5.6.
Manuelles setzen über mqtt geht gut (mit warten von ca. 1 min). Nachdem 
jedoch die automatische Datenflut über mqtt erfolgt ist, hilft meist nur 
ein reboot über ahoy.
Mal schauen wie es weiter geht... heute wird es erst mal "dunkel" bei 
mir.

[Jörg R. (rejoe2)]

Boah, jetzt scheinen die sich auf Kanal 61 geeinigt zu haben, und da 
geht es nur noch so ab in der Kommunikation zu dem MI...

Aber nur noch 89/91-Messages. Kann es sein, dass man die 88/92 extra 
bestellen muss? (An einen anderen Channel dafür mag ich nicht so recht 
glauben, oder braucht man den doch?).

Update der ino anbei. (EDIT *2)

Mit etwas millis() in der Debug-Ausgabe (CRC-Check ausgeschaltet)...

360453 Send... CH61 360454116010001378563412007A.....send res 0
CH61 00 1234567801 00C2 18 1  89 60100013 60100013 012600070930138700D508D801595915A0 1
360490 CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH61 00 1234567801 00C2 18 1  89 60100013 60100013 012600070930138700D508D801595915A0 1
360510 CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH61 00 1234567801 00C2 18 1  89 60100013 60100013 012600070930138700D508D801595915A0 1
360534 CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
360549 Send... CH61 3605510960100013785634120062.....send res 0
365549 Send... CH61 365549116010001378563412007A.....send res 0
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365631 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365651 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60105557 6AB48057 036C400F1B6F378F00DA8AFD0B5AF6376F 0
365675 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 87.6V 1639.9A 35581Wh 702.3ACV 142.2Hz 290.6C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 87.6V 1639.9A 35581Wh 702.3ACV 142.2Hz 290.6C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365699 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365723 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365747 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365771 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Boah, jetzt scheinen die sich auf Kanal 61 geeinigt zu haben, und da
> geht es nur noch so ab in der Kommunikation zu dem MI...
>
> Aber nur noch 89/91-Messages. Kann es sein, dass man die 88/92 extra
> bestellen muss? (An einen anderen Channel dafür mag ich nicht so recht
> glauben, oder braucht man den doch?).
>
moment mal wieso sehe ich das?
360549 Send... CH61 3605510960100013785634120062.....send res 0
das ist die abfrage "cmd36" für MI1500!! das sollete beim MI600 nicht 
sein! irgendwas stimmt nicht da.


also die einigen sich überhaupt nicht für einen kanal, wir senden  und 
empfangen (channel hopping) auf ch {3,23, 40, 61, 75}, wenn der wr z.b. 
auf 11 beantwortet werden wir nicht erfahren. ich beheaupte schon lange, 
dass die wr's mit der zeit auf andere kanaele wechseln. ich bin mir 
nicht sicher, z.b. bei ahoy-esp wird nur auf ch3 empfangen, dann kann es 
natürlich lange dauern bis etwas kommt.
ich denke die 88/92 antworten sind ev. auf einem anderen kanal.

[Jörg R. (rejoe2)]

Es ist definitiv nicht auszuschließen, dass ich irgendwas grundlegend 
verbogen habe.
ABER: Ziel der Änderungen in dem Code war es, das channel-Gehopse für 
die Fälle auszuschalten, in denen was als Antwort zurückkommt. 
rx-Channel und tx-Channel sollten dabei immer gleich sein. Gesendet wird 
dabei (in Summe) sehr viel langsamer!
Kann man an den millis()-Ausgaben vor den debug-Meldungen ablesen, 
besser sogar noch, wenn CRC eingeschaltet ist.

Was ich sehen kann, ist dass der MI seit ungefähr 2 h immer auf die 
898/91-Anfragen unter Kanal 61 antwortet, und das relativ zuverlässig, 
einzelne Anfragen gehen verloren.

Ergo kann es schon sein, dass die anderen Infos unter einem anderen 
Kanal verfügbar wären, eher glaube ich daran, dass das einfach 
"Zufallstreffer" auf "unser Gerausche" waren (Fehlinterpretationen der 
Anfrage-Ziffer, sowas habe ich hier "rückwarts" teilweise auch 
gesehen...).

Die Änderungen im Code sind übrigens überschaubar - ein diff oder der 
Vergleich in notepad++ würde ggf. helfen zu verstehen, wie meine "Denke" 
dazu ist. Und bitte immer das Bildchen von MySensors gedanklich mit 
diesen Modifikationen vergleichen.
Ich behaupte, das Gehopse der MI selbst dient wirklich nur dazu, sich 
auf einen Kanal zu verständigen, und zwar "einen für alle" (!). Wenn HM 
das mit 03 hinbekommt, ohne dass sich jemand beklagt, gilt dies m.E. 
umso mehr.

Dass man damit eigentlich die ganze Abfragelogik umstellen müßte, ist 
ein anderes Thema (also irgendwie verwalten, zu was man schon eine Info 
hat und wo man ggf. nochmal nachhaken müßte etc.).

EDIT:
Das "es kommt nichts mehr, also wird gehoppt" funktioniert übrigens - es 
ist Nacht:

2901299 Send... CH61 29012990960100013785634120062.....send res 0
2906299 Send... CH75 2906299116010001378563412007A.....send res 0
2911299 Send... CH03 29112990960100013785634120062.....send res 0
2916299 Send... CH23 2916299116010001378563412007A.....send res 0
2921299 Send... CH40 29212990960100013785634120062.....send res 0
2926299 Send... CH61 2926299116010001378563412007A.....send res 0
2931299 Send... CH75 29312990960100013785634120062.....send res 0
2936299 Send... CH03 2936299116010001378563412007A.....send res 0

Bin mal gespannt, ob und wo die sich morgen finden.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> ABER: Ziel der Änderungen in dem Code war es, das channel-Gehopse für
> die Fälle auszuschalten, in denen was als Antwort zurückkommt.
> rx-Channel und tx-Channel sollten dabei immer gleich sein. Gesendet wird
> dabei (in Summe) sehr viel langsamer!
> Kann man an den millis()-Ausgaben vor den debug-Meldungen ablesen,
> besser sogar noch, wenn CRC eingeschaltet ist.

ok, ich kann deine gedanken folgen. aber wie am anfang dieses projektes 
"bewiesen" wurde, dass der dtu statistisch meistens auf kanaelen {3,23, 
40, 61, 75} sendet, darum haben wir es so gemacht.
ich habe für mich durchs sniffen heraus gefunden, dass z.B. mein MI1500 
manchmal den ganzen tag nicht auf CH3 antwortet, darum hab ich hopping 
auch beim rx eingeführt.
ich bin mir nicht sicher, ob ein ack  immer auf dem gleichen kanal kommt 
oder kommen muss.

aber wieso sendest du den timer mit?? das verstehe ich nicht, so 
bekommst du doch keine antworten, oder?
2936299 Send... CH03 [2936299]116010001378563412007A
2931299 Send... CH75 [2931299]0960100013785634120062

[Sebastian (Gast)]

Hallo,

Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne 
auslesen möchte per Ahoy DTU.

Heute kamen  alle Teile an, der  Az Esp8266
und das Az Antennenmodul.

Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich 
bekomme einfach keine Verbindung zum Wechselrichter?

Die Seriennummer geht los mit 1161xxxxx

Das Pinout hatte ich mehrfach kontrolliert.

[Steffen D. (steffen_d)]

Sebastian schrieb:
> Hallo,
>
> Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne
> auslesen möchte per Ahoy DTU.
>
> Heute kamen  alle Teile an, der  Az Esp8266
> und das Az Antennenmodul.
>
> Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich
> bekomme einfach keine Verbindung zum Wechselrichter?
>
> Die Seriennummer geht los mit 1161xxxxx
>
> Das Pinout hatte ich mehrfach kontrolliert.

Wie weit ist Ahoy vom WR entfernt?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> 2936299

Ziyat T. schrieb:
> ok, ich kann deine gedanken folgen. aber wie am anfang dieses projektes
> "bewiesen" wurde, dass der dtu statistisch meistens auf kanaelen {3,23,
> 40, 61, 75} sendet, darum haben wir es so gemacht.
Das ist ja vermutlich auch nicht kompletter Unsinn. Solange keine 
Antwort zurückkommt, oder wenn da Teilnehmer sind, die bestimmte 
Frequenzen nicht können, wäre das eine Option. Irgendwo meine ich 
gelesen zu haben, dass die originale DTU ein paar Bugs hat, und als 
solchen würde ich es bezeichnen, wenn die das grundlos macht. Bis 
jedenfalls dato habe ich noch keinen triftigen Grund gefunden für's 
hoppen, es sei denn, jeder WR hätte "seine" Frequenz...
Aber dann müßte es gewisse Zeitbudgets geben, und die Reichweite wäre 
sehr viel begrenzter wie mit der Mesh-Option, die afaik nur 
funktioniert, wenn alle beteiligten nRF auf derselben Frequenz funken.

> ich habe für mich durchs sniffen heraus gefunden, dass z.B. mein MI1500
> manchmal den ganzen tag nicht auf CH3 antwortet, darum hab ich hopping
> auch beim rx eingeführt.
> ich bin mir nicht sicher, ob ein ack  immer auf dem gleichen kanal kommt
> oder kommen muss.
Das Hardware-Ack (ganz am Anfang der loop) "kann" gar nicht anders, "des 
khert so!". Und Es macht m.E. auch keinen Sinn, die Antwort auf eine 
Anfrage auf einem anderen Kanal zu machen (es sei denn, es gäbe eine 
explizite Verabredung über Frequenz und timing (!). MAn. viel zu 
kompliziert...)
Bei meinem "guten" nRF hatte ich einige HW-Acks gesehen, beim "kleinen" 
nicht und auch nicht mehr beim ungeshieldeten. Aber wenn er da ist, ist 
es m.E. der "Jackpot" - eindeutiger geht es nicht...

> aber wieso sendest du den timer mit?? das verstehe ich nicht, so
> bekommst du doch keine antworten, oder?
> 2936299 Send... CH03 [2936299]116010001378563412007A
> 2931299 Send... CH75 [2931299]0960100013785634120062
Falsche (doppelte) Stelle für die Info erwischt, hinter if 
(DEBUG_TX_DATA){  muss man die eine Zeile auskommentieren, sorry; 
gesendet wird das nicht.

Wenn es gut gemacht ist, müßte es auch einen Code geben, mit der die DTU 
den WR (allen "zuhörenden" per broadcast?) mitteilt, dass ab demnächst 
ein anderer Kanal zu verwenden ist, wobei ich bei 5en dann eher immer 
einen überspringen würde (also Start=23, dann 61, 3, 40, 75, 23). So 
könnte man auch einen schnellen stabilen nächsten Gesamtzustand 
erhalten. (Denkt sich jedenfalls der Laie).

Bin mal gespannt auf morgen...

[Sebastian (Gast)]

Steffen D. schrieb:
> Sebastian schrieb:
>
>> Hallo,
>> Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne
>> auslesen möchte per Ahoy DTU.
>> Heute kamen  alle Teile an, der  Az Esp8266
>> und das Az Antennenmodul.
>> Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich
>> bekomme einfach keine Verbindung zum Wechselrichter?
>> Die Seriennummer geht los mit 1161xxxxx
>> Das Pinout hatte ich mehrfach kontrolliert.
>
> Wie weit ist Ahoy vom WR entfernt?

Zum testen war ich ganz nahe am Wechselrichter ca 3m entfernt.

Die Sonne war schon  weg, es lagen vielleicht noch 26 Watt an, damit 
müsste das Funkmodul doch noch arbeiten im Wechselrichter.

[Jörg R. (rejoe2)]

Nachtrag noch: Wie sähe denn die Anfrage nach den Werten aus 88/92 aus? 
Und in welchem Intervall würde man solche Infos erfragen wollen?

Sebastian schrieb:
> Die Sonne war schon  weg, es lagen vielleicht noch 26 Watt an, damit
> müsste das Funkmodul doch noch arbeiten im Wechselrichter.
Habe vorhin bei dem MI noch Nachrichten empfangen bei nahe 0 W....

[Sebastian (Gast)]

Jörg R. schrieb:
> Nachtrag noch: Wie sähe denn die Anfrage nach den Werten aus 88/92
> aus? Und in welchem Intervall würde man solche Infos erfragen wollen?
> Sebastian schrieb:
>
>> Die Sonne war schon  weg, es lagen vielleicht noch 26 Watt an, damit
>> müsste das Funkmodul doch noch arbeiten im Wechselrichter.
>
> Habe vorhin bei dem MI noch Nachrichten empfangen bei nahe 0 W....

Sehr komisch, den ESP hatte ich bestellt
https://www.amazon.de/gp/aw/d/B074Q2WM1Y?psc=1&ref=ppx_pop_mob_b_asin_title

Das Funkmodul dazu
https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title

[Jörg R. (rejoe2)]

Sebastian schrieb:
> Das Funkmodul dazu
> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title

Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise 
die falsche Ausführung, das muss eines mit "+" sein, also nicht 
"NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es 
zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise 
sollte die ganze Schrift klar sein (=früher war "verwaschen" ein 
Anzeichen für fake chips").

Wie gesagt: Es ist möglicherweise "overdone", aber ich würde immer für 
"richtige Projekte" (aus vielerlei Gründen) sicherheitshalber zu den 
"großen geshieldeten Modulen" raten (und ausreichend Power uVa. 
Kondensator-Kapazität vorschalten!). (Willkürlich gegriffen!) sehen die 
Dinger so aus: https://www.ebay.de/itm/162822272150.

Hat sich auch jetzt wieder gezeigt: So ein Teil + diese hier teilweise 
abgewerteten Adapterplatinen (ebenfalls willkürlich: 
https://www.ebay.de/itm/144491901516) haben sich als einigermaßen robust 
erwiesen, das ist die Kombi (optisch), die Hardware-ACKS ausspuckt...

[Jörg R. (rejoe2)]

...ohne weitere Worte - das log von heute morgen...

[Steffen D. (steffen_d)]

Jörg R. schrieb:
> Sebastian schrieb:
>> Das Funkmodul dazu
>> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title
>
> Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise
> die falsche Ausführung, das muss eines mit "+" sein, also nicht
> "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es
> zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise
> sollte die ganze Schrift klar sein (=früher war "verwaschen" ein
> Anzeichen für fake chips").

Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der 
Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> ...ohne weitere Worte - das log von heute morgen...

das sieht ja recht ordentlich aus:-)

> Falsche (doppelte) Stelle für die Info erwischt, hinter if
> (DEBUG_TX_DATA){  muss man die eine Zeile auskommentieren, sorry;

ja, habe auch schon gefunden

also, deine überlegungen müsste man schon verfolgen, es sieht ja so aus, 
wenn sich die beiden auf einen kanal "einigen" laeuft es schon besser.

edit:ich schaue mal nach, warum bei dir die status meldungen nicht gehen

[Ziyat T. (toe_c)]

@Jörg R.

also wir schicken 0x09/0x11, erwarten 0x91/0x89(data) UND 
0x92/0x88(status), es gibt keine sep. status abfrage

du hattest ja am anfang diese auch mal gesehen
CH3 00 1234567801 0082 10 1  92 60100013 60100013 00[03]00000000913454 1
diese [03] ist status = producing

villeicht sind die 0x92/0x88 auf anderem kanal?

[Jörg R. (rejoe2)]

Steffen D. schrieb:
> Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der
> Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".
Komisch, dass ein eher größerer Importeur wie AZDelivery bei der 
Beschreibung leicht schlampig vorgegangen ist, aber auch die Bilder sind 
teilweise eindeutig "mit +".

Wenn es nicht klappt, ggf. mal den Ping-Pong-Sketch aus der RF24-lib 
suchen (oder war der von MySensors?). Damit sollte sich feststellen 
lassen, ob die HW an sich ok ist.

Ziyat T. schrieb:
> Jörg R. schrieb:
>> ...ohne weitere Worte - das log von heute morgen...
>
> das sieht ja recht ordentlich aus:-)
grins

Ziyat T. schrieb:
> villeicht sind die 0x92/0x88 auf anderem kanal?
Habe eine andere Theorie: Man muss nur lange genug ohne Anfrage 
warten, dann kommen die automatisch!

Wenn diese Theorie richtig ist, müßte es ausreichen, nur die 
0x08-Anfrage an die MI-600 zu senden (und entsprechend die untere 
Status-Anfrage an die MI-300 bzw. MI-1xxx). Wir bräuchten also uU. gar 
keine 0x09/0x11!

Mich beschäftigen in diesem Zusammenhang ein paar Fragen:
- Warum kamen die "anderen" Messages überhaupt, wenn sie nicht angefragt 
waren?
- warum waren in dem Log mit ausgeschaltetem CRC gestern relativ viele 
an sich "gute" (gleiche) Messages?
- warum empfängt man im reinen sniffer-Modus noch recht lange Daten vom 
WR, obwohl es keine Anfrage mehr geben dürfte?

Daraus ergibt sich für mich folgendes vorläufiges Bild:
- Wir brauchen einen gemeinsamen "Nenner", was den Kanal angeht. Steht 
der mal, haben die WR ein größeres "Beharrungsvermögen" auf diesem Kanal 
- der MI-600 hat jedenfalls mit einiger Sicherheit da angefangen, wo er 
abends aufgehört hatte...
- Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem 
vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn 
es irgendwelchen signifikanten Änderungen gibt;
- als "Ping" ist möglicherweise bereits ein (Hardware-!)-ACK für eine 
beliebige Message des WR ausreichend, in jedem Fall aber eine beliebige 
Anfrage eines einzelnen Werts aus dem Gesamtpaket. Das mit dem 
Hardware-ACK deswegen, weil vermutlich das Senden der "immer gleichen 
Message" dann aufhört, wenn der Sender sein angeforderte ACK gehört 
hat...

Ergo würde ich die Zeit bis zur nächsten aktiven Anfrage mal deutlich 
verlängern (15-20 Min!), sobald wir eine Antwort vom WR haben (ACK 
genügt).

Weiß nicht, ob das so ist, aber wir sollten mAn. alle Anfragen mit 
ACK-Anforderung versenden.

Weiter könnte es eine gute Idee sein, sich das Routing jedes WR zu 
merken. Wenn wir "wissen", dass es einen Repeater braucht, müßte man 
mAn. den direkt anpingen und darum bitten, das weiterzugeben. Auch das 
müßte eigentlich mit ACK vom _End_-Empfänger gehen. Code dazu müßte 
(einmal mehr) bei MySensors zu finden sein.

Nachtrag: Das mit dem ACK ist übrigens der Grund warum ich davon 
ausgehe, dass es eine sehr gute Idee ist, dieses Projekt mindestens mit 
einem Modul mit PA+LNA auszustatten...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Wenn diese Theorie richtig ist, müßte es ausreichen, nur die
> 0x08-Anfrage an die MI-600 zu senden (und entsprechend die untere
> Status-Anfrage an die MI-300 bzw. MI-1xxx). Wir bräuchten also uU. gar
> keine 0x09/0x11!
>

du hast mich falsch verstanden, nochmals:
es gibt nur die 0x09(PV1)/0x11(PV2) zum abfragen

nach der abfrage müssten 0x91/0x89(data) danach
0x92/0x88(status)kommen
edit:oder umgekehrt, das wissen wir (noch) nicht

es gibt keine sep. status abfrage

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> - Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem
> vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn
> es irgendwelchen signifikanten Änderungen gibt;
> - als "Ping" ist möglicherweise bereits ein (Hardware-!)-ACK für eine
> beliebige Message des WR ausreichend, in jedem Fall aber eine beliebige
> Anfrage eines einzelnen Werts aus dem Gesamtpaket. Das mit dem
> Hardware-ACK deswegen, weil vermutlich das Senden der "immer gleichen
> Message" dann aufhört, wenn der Sender sein angeforderte ACK gehört
> hat...

bisher kann ich das für den MI1500 nicht bestaetigen, beim sniffen der 
DT-Pro/MI1500, tut der WR einfach mal den kanal wechseln, warum auch 
immer

man muss immer daran denken, dass der MI300/MI600 schon einiges aelter 
sind, und der MI1500 der letzte von 2.gen ist, kann durchaus sein, dass 
das verhalten auch anderes ist

>- Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem
> vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn
> es irgendwelchen signifikanten Änderungen gibt;

der MI1500 hört schnell auf, wenn nichts abgefragt wird

edit: hab gerade nachgeschaut, wr sendete etwa 10min lang auf ch61, dann 
jetzt plötzlich auf ch3

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> du hast mich falsch verstanden, nochmals:
> es gibt nur die 0x09(PV1)/0x11(PV2) zum abfragen
>
> nach der abfrage müssten 0x91/0x89(data) danach
> 0x92/0x88(status)kommen
> edit:oder umgekehrt, das wissen wir (noch) nicht
>
> es gibt keine sep. status abfrage
Habe offenbar den Mechanismus dann fehlinterpretiert, hatte das hier von 
neulich im Hinterkopf und daraus geschlossen, dass es evtl. möglich ist, 
auch die 0x08 als Anfrage zu versenden:
Stefan T. schrieb:
> Die Antworten haben i.d.R. das erste (höchstwertige) Bit gesetzt:
> * Anfrage 0x09 -> Antwort 0x09|0x80=0x89
> * Anfrage 0x11 -> Antwort 0x11|0x80=0x91
> * Anfrage 0x36 -> Antwort 0x36|0x80=0xB6

Ziyat T. schrieb:
> bisher kann ich das für den MI1500 nicht bestaetigen, beim sniffen der
> DT-Pro/MI1500, tut der WR einfach mal den kanal wechseln, warum auch
> immer
>
> man muss immer daran denken, dass der MI300/MI600 schon einiges aelter
> sind, und der MI1500 der letzte von 2.gen ist, kann durchaus sein, dass
> das verhalten auch anderes ist
>
> edit: hab gerade nachgeschaut, wr sendete etwa 10min lang auf ch61, dann
> jetzt plötzlich auf ch3
Hmm, sendest du die Anfragen weiter unter allen Channels raus? Bzw. die 
DT-Pro? Wenn ja, ist das uU. einfach ein bug der DTU. Es kann zwar sein, 
dass der MI1500 irgendwie speziell ist, aber warum sind die Gen-3-Geräte 
dann gut erreichbar, wenn man nur ch03 verwendet? (So macht das ahoy, 
oder?) Wäre nur zu erklären, wenn sich das (neue) Prinzip nicht bewärt 
hätte.
Oder kannst du zwischendurch was sniffen, was nach Aufforderung zum 
"Kanalwechsel" aussieht?

Und kannst du den aktuellen rx-Kanal sehen/sichtbar machen, über den die 
0x88/0x92-Infos reinkommen? Wie ist der Zeitstempel im Verhältnis zur 
zugehörigen "Hauptmessage"?

>der MI1500 hört schnell auf, wenn nichts abgefragt wird
Unter welchen Rahmenbedingungen hast du das getestet? Mit oder ohne 
rx-hop?
Und was ist "schnell"? (uU. können/müssen wir eben passende Timings 
konfigurieren).
EDIT: ok, das waren in dem Fall 10 Minuten, wenn ich es richtig 
interpretiert habe.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:

> Hmm, sendest du die Anfragen weiter unter allen Channels raus? Bzw. die
> DT-Pro? Wenn ja, ist das uU. einfach ein bug der DTU. Es kann zwar sein,
> dass der MI1500 irgendwie speziell ist, aber warum sind die Gen-3-Geräte
> dann gut erreichbar, wenn man nur ch03 verwendet?

weil die 2.gen und 3.gen WRs andere SW haben, in der ein völlig anderer 
mechanismus implementiert ist, sonst waere ja alles gleich und einfach

> Unter welchen Rahmenbedingungen hast du das getestet? Mit oder ohne
> rx-hop?

sniffer-mode

übrigens: wenn wir auf ack warten, dann funktioniert der sniffer nicht, 
aber das ist egal, andere baustelle

edit: ich bau mal die sw um, rxCH=txCH und hopping wenn ein SW-ack 
kommt, mal schauen

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> weil die 2.gen und 3.gen WRs andere SW haben, in der ein völlig anderer
> mechanismus implementiert ist, sonst waere ja alles gleich und einfach
Na ja, aus bestimmten Limitierungen der nRF-Hardware kann auch die 
3.Gen-firmware nur schlecht raus, das klingt (von sehr weit weg 
vermutet) irgendwie eher danach, als wäre da halt eine stricktere 
Abfolge von geringfügig weniger Messages erforderlich.
Eigentlich glaube ich, dass das auch für die 2. Gen-Geräte richtig wäre:
1. Paket anfordern, auswerten, gleich das 2. anfordern, dann warten bis 
3+4 kommen, alles zusammen auswerfen. Kommt Paket 1 oder 2 nicht: 
nochmal anfordern, erst beim 3. Mal aufgeben, diesen Teil der Daten 
nicht ausgeben.

> sniffer-mode
>
> übrigens: wenn wir auf ack warten, dann funktioniert der sniffer nicht,
> aber das ist egal, andere baustelle
Ähm, fyi: gestern morgen war ich noch der festen Überzeugung, ich hätte 
die nRF geschrottet, weil ESP1 (im sniffer-Mode!) nichts (!) von dem 
gesehen hat, was ESP2 gesendet hat, und auch nichts von dem, was der WR 
vielleicht geantwortet hat. Aber auch ESP2 hat keine Antworten 
bekommen...

> edit: ich bau mal die sw um, rxCH=txCH und hopping wenn ein SW-ack
> kommt, mal schauen
Bin gespannt.

Nachtrag noch zu den Fragen von vorhin: während du für 10 Minuten nichts 
gesendet hattest - hat da der WR irgendwas zum Status der einzelnen 
Eingänge von sich gegeben?

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Nachtrag noch zu den Fragen von vorhin: während du für 10 Minuten nichts
> gesendet hattest - hat da der WR irgendwas zum Status der einzelnen
> Eingänge von sich gegeben?

wenn ich max 1 min nichts sende, hört der auf

[Sebastian (Gast)]

Steffen D. schrieb:
> Jörg R. schrieb:
>
>> Sebastian schrieb:
>>
>>> Das Funkmodul dazu
>>> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title
>>
>> Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise
>> die falsche Ausführung, das muss eines mit "+" sein, also nicht
>> "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es
>> zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise
>> sollte die ganze Schrift klar sein (=früher war "verwaschen" ein
>> Anzeichen für fake chips").
>
> Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der
> Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".

So ein Update, soweit läuft jetzt alles mit der Hardware. Der Fehler lag 
daran ohne Kondensator läuft der NRF nicht an.

Nun hab ich das Problem das das Webinterface nach einiger Zeit nicht 
mehr erreichbar ist bzw der ESP arbeitet weiter.

[Jörg R. (rejoe2)]

Oha, das ist (gefühlt) kurz...

Wenn wir den also "sicher" auf dem aktuellen Kanal halten wollten, 
müßten wir spätestens nach unter 50 Sekunden anfangen, den anzupingen, 
soweit so schlecht. Dann sollte die "hopping-Frequenz" unseres Codes 
irgendwie so versetzt sein, dass wir entweder mind. 5 Minuten warten* 
(dann wäre er ggf. wieder da?) => 5:30 beginnen, ggf. hinterherzulaufen 
(oder entgegen?), was umso besser gelingen könnte, wenn wir dann die 
Reihenfolge wüßten, in die wir ggf. zu gehen haben oder wir müßten nach 
einem Verbindungsabbruch dann eben wieder relativ schnell durch die 
Kanäle zappen (1-3 Sekunden?).

*Warten wäre ggf. die bessere Variante, wenn wir bereits eine "Herde" 
haben, die auf Kommandos auf dem betr. Kanal warten. Macht im Moment 
für's Testen noch keinen Unterschied, aber m.E. sollte man diesen Aspekt 
im Hinterkopf behalten. Es kann ja Gründe geben, warum einer "unseren 
Kanal" nicht mehr will (Interferenzen wg. anderem Sender in der Nähe des 
WR etc.). Dann könnte man den auf dem Fuße folgen und darauf warten, 
dass der Rest nachkommt.

Oder es bekommt eben jeder WR "seine" Frequenz?

Na ja, bißchen viel auf einmal, oder? Für's erste müßte es erst mal 
genügen rauszufinden, ob man dem MI1500 einfach auf einem Kanal halten 
kann, und wie viele Anfragen es braucht, damit er "alles" sendet. Dto 
für den MI-600. Kann grade nur sporadisch schauen, aber das sieht 
plausibel aus, und es gibt bei einem der Kanäle sogar eine "3"-Info...

Werde daher vielleicht als erstes die 5 Sekunden aus meiner Fassung des 
Sketches zu 25 Sekunden ausweiten?

[Rene M. (Firma: Bitte wählen) (renmo)]

@Sebastian
versuche ein anderes stärkeres Netzteil.
Welche Version hast du genau installiert?

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Wenn wir den also "sicher" auf dem aktuellen Kanal halten wollten,
> müßten wir spätestens nach unter 50 Sekunden anfangen, den anzupingen,
> soweit so schlecht.

das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf 
allen kanaelen, bin ziemlich sicher.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf
> allen kanaelen, bin ziemlich sicher.

Es irritiert mir zwar immer noch, aber du wirst das mit deinen 
Erfahrungen besser wissen. Es erscheint mir nicht logisch, effektiv >80% 
der Zeit "blind" zu fliegen und dabei zu behaupten, dass man auch 
größere Netze überwachen könnte (so hatte ich das im Hinterkopf als 
Inhalt eines Werbefilmchens von denen mal abgespeichert).
Vielleicht ist es ähnlich wie bei manchen von diesen Temperatursensoren, 
die die Hälfte der Zeit mit der einen Methode senden und die andere mit 
einer anderen? Also: Hauptinfo auf Kanal 1, Statusinfo auf Kanal 2 (oder 
3). Bricht einer weg, wechselt der Hauptkanal auf den anderen, und es 
wird ein neuer fallback ausgehandelt?

Mir fehlt nur grade eine Idee, wie man sowas austesten könnte. Wenn die 
Theorie aufgeht, dass man auch den MI-1500 auf dem einen Hauptkanal 
halten kann, wenn man nur regelmäßig genug 0x36-0x39 abfragt (?), müßte 
es doch gehen, den Regelablauf so zu machen, dass man erst auf dem 
Hauptkanal die 4 Werte abfragt, und dann auf den übrigen scannt, wobei 
es Zufall sein mag, dass vorhin der Wechsel im Hauptkanal von 61 nach 03 
ging (relativ großer Abstand wie oben bereits theoretisiert).
Das ergäbe sowas wie: <20 Sekunden für die 4 Anfragen samt Warten auf 
Antwort, dann je 2 Durchläufe über die übrigen Kanäle à je knapp 5 
Sekunden. Hat man einen Treffer, auf diesem Kanal die restlichen 40 
Sekunden lauschen?
(Modell für einen WR, klar...).

Oder gibt es für sowas bessere, standardisierte Methoden?

[Sebastian (Gast)]

Rene M. schrieb:
> @Sebastian
> versuche ein anderes stärkeres Netzteil.
> Welche Version hast du genau installiert?

Ahoy 0.5.8 und Netzteile habe ich schon etliche versucht. Sehr komisch, 
jetzt lief der ESP mal eine Stunde durch und verschwindet.

[Rene M. (Firma: Bitte wählen) (renmo)]

gibt schon eine neuere ahoy Version.
Hast du MQTT aktiviert?

[Highlander (Gast)]

@AHOY

Über welche serielle Schnittstelle läuft die Debug Ausgabe beim ESP8266?
Über die am USB Anschluß (Darüber versorge ich ihn gerade mit einem Ipad 
Ladegerät mit 5V)?

Ist die immer aktiviert oder im Sourcecode freizuschalten?
Wenn wo?

Eine ältere Version 3.6 oder so läuft bei mir seit Monaten ohne jedes 
Problem.

Seit ein paar Tagen keine Daten mehr vom HM1500.

Ich hoffe so auf aussagekräftige Informationen.
Ich sehe das permanent angefragt wird, aber vom HM1500 kommt nichts 
zurück.
Ich hoffe der WR ist nicht nach 6 Monaten schon im "Himmel".
Er speist aber noch artig ein.

2-3 Tage vorher sah ich auf einem der 3 Panels plötzlich nur noch ein 
paar Watt Abgabe.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf
>> allen kanaelen, bin ziemlich sicher.
>
>
> Mir fehlt nur grade eine Idee, wie man sowas austesten könnte.

ich habe leider nur 1 esp+nrf aber,
wenn du 2 esp+nrf hast, könntest so testen:
-ESP1 sendet nur auf einem CH
-ESP2 empfaengt alle CH

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> wenn du 2 esp+nrf hast, könntest so testen:
> -ESP1 sendet nur auf einem CH
> -ESP2 empfaengt alle CH
Stimmt eigentlich...

Frage noch zu dem Mi-1500-Teil des Codes. Es gibt keine separate 
Auswertung der "Status"-Messages? Diese Infos sind bei diesem Typ Teil 
der "normalen" Messages aus 0x36-0x39, oder ist mir was rausgegangen?

Und wenn das so ist: wieso bist du dir sicher, dass die nicht (z.B.) per 
0x08-Anfrage gesondert abzurufen wären? Die gesendeten Daten aus einem 
MI-600 hatte ja bis zu diesem Punkt noch keiner von uns hier gesehen, 
oder?

[Ziyat T. (toe_c)]

@Jörg R.
kannst du bitte diese variante mal testen?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> wenn du 2 esp+nrf hast, könntest so testen:
>> -ESP1 sendet nur auf einem CH
>> -ESP2 empfaengt alle CH
> Stimmt eigentlich...
>
> Frage noch zu dem Mi-1500-Teil des Codes. Es gibt keine separate
> Auswertung der "Status"-Messages? Diese Infos sind bei diesem Typ Teil
> der "normalen" Messages aus 0x36-0x39, oder ist mir was rausgegangen?
ja

> Und wenn das so ist: wieso bist du dir sicher, dass die nicht (z.B.) per
> 0x08-Anfrage gesondert abzurufen wären?

ich kenne keine 0x08-anfrage für MI

> Die gesendeten Daten aus einem
> MI-600 hatte ja bis zu diesem Punkt noch keiner von uns hier gesehen,
> oder?

du hattest ja auch mal gesehen
CH3 00 1234567801 0082 10 1  92 60100013 60100013 00[03]00000000913454 1
diese [03] ist status = producing

[Marki (Gast)]

Hallo,
ich habe zwei Hm-400. Gestern habe ich mir mal die Ahoy version 0.5.4 
geflasht und das erste mal getestet. Funkverbindung über ca 25m ging auf 
anhieb. nur hatte ich vergessen das ich bei Produktion der 2 WR die 
0Watt in der Setup Seite auf 400 ändere. Seitdem produziert einer der 2 
WR nicht mehr.
Gibts irgendein reset befehlt? Das er wirklich nicht mehr produziert 
sehe ich an den SDM120, also stimmt die Anzeige in der Ahoy Software.

[Sebastian (Gast)]

Sebastian schrieb:
> Rene M. schrieb:
>
>> @Sebastian
>> versuche ein anderes stärkeres Netzteil.
>> Welche Version hast du genau installiert?
>
> Ahoy 0.5.8 und Netzteile habe ich schon etliche versucht. Sehr komisch,
> jetzt lief der ESP mal eine Stunde durch und verschwindet.

So gibt es wieder ein Update,  ein 2. Kondensator hat geholfen am 5 V 
Anschluss vom ESP,  bis jetzt läuft er stabil.

[Sigi S. (sermon)]

Hallo Leute,

das ist eine völlig neue Umgebung für mich.
Ich fühle mich verloren.

Gibt es eine etwas detailliertere Step By Step Anweisung um das Projket 
zu importieren, erfolgreich zu compilieren, als auch auch zu flashen 
(denke das geht direkt aus Visual Studio Code heraus?), als diese hier:?
Ich benötige Hilfe, Danke

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This code can be compiled using Visual Studio Code and PlatformIO Addon. 
The settings were:

    Board: Generic ESP8266 Module
    Flash-Size: 1MB (FS: none, OTA: 502kB)
    Install libraries (not included in the Arduino IDE 1.8.19):
        Time Arduino Time library (TimeLib.h)
        RF24 Optimized high speed nRF24L01+ driver class documentation
        PubSubClient A client library for MQTT messaging. By Nick 
O'Leary
        ArduinoJson Arduino Json library

[Tobi (Gast)]

Marki schrieb:
> Funkverbindung über ca 25m ging auf
> anhieb.

Bei mir geht nicht mal 50 cm stabil.

Kannst Du bitte mal schreiben welchen ESP und welchen NRF24 du genau 
verwendest (am besten mit Produktlink). Ob Du Kondensatoren verbaut 
hast. Besonderheiten. Etc.

Danke!

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> du hattest ja auch mal gesehen
> CH3 00 1234567801 0082 10 1  92 60100013 60100013 00[03]00000000913454 1
> diese [03] ist status = producing
Soweit ist es klar, der WR meldet das übrigens jetzt grade auch auf 
beiden Kanälen, die hinteren beiden Felder sind (vermutlich unverändert) 
jeweils auf 0.

Die (für mich noch nicht ganz geklärte) Frage ist ja gerade, warum die 
mit dem "Gerausche" eher häufiger zu sehen gewesen waren - dafür aber 
mit "kaputtem Beiwerk", und jetzt so selten.
Komme auf die Schnelle auf zwei Varianten: Entweder haben wir den WR 
verwirrt und er hat eben "kaputte Messages" als (undokumentierte...) 
Aufforderung akzeptiert, oder es gab zwischendurch einen Kanalwechsel, 
bei dem dann mehr oder weniger zufällig so eine "reguläre Statusmessage" 
abgefangen wurde.

Beides möglich, vielleicht knödle ich testweise mal ergänzend einen 
0x08-Anfrageversuch rein. Wenn ich den Code richtig verstanden habe, 
müßte man halt statt des "flip-flops" noch eine dritte (bzw. falls das 
wider Erwarten klappt: und 4.) Variante einbauen.

Danke vorab für Code und die Erhellung, was den MI-1500 angeht.

[Marki (Gast)]

Tobi schrieb:
> Marki schrieb:
>> Funkverbindung über ca 25m ging auf
>> anhieb.
>
> Bei mir geht nicht mal 50 cm stabil.
>
> Kannst Du bitte mal schreiben welchen ESP und welchen NRF24 du genau
> verwendest (am besten mit Produktlink). Ob Du Kondensatoren verbaut
> hast. Besonderheiten. Etc.
>
> Danke!

diese nrf24+ Module
https://www.aliexpress.com/item/32719545755.html?spm=a2g0o.order_detail.0.0.598e6368s2llpG

und dieses 5er pack
https://de.aliexpress.com/item/1005003722134215.html?spm=a2g0o.order_list.0.0.21ef5c5fU9zuSa&gatewayAdapt=glo2deu

kein Kondensator, und Netzteil war von einen alten FireTV Stick, glaub 
das macht so um die 2A. Aber auch an der USB 2 buchse von meinen 
Thinkpad T430 kommt genug Strom raus.

die Funkmodule hatte ich schon im Oktober gekauft bin aber am schlechten 
bzw dunklen Wetter gescheitert da irgendwas zu machen und als ich jetzt 
im Sommerurlaub mal schauen wollte bin ich hier über den Beitrag 
gestolpert und hab mir viel zeit gespart.

Ich werde mir auch mal das OpenDTU anschauen, da ich hier einige ESP32 
mit Ethnernet und POE habe und dann kann ich auf das WLAN verzichten.

[J. S. (jojos)]

Kann man mit den Erkenntnissen hier einen HM-1500 auf 600 Watt drosseln 
für den Betrieb als BKW? Oder habt ihr die als Festinstallation laufen?

[Dirk K. (millenniumpilot)]

hätte die gleiche Frage. Hoymiles 1500 bekommt man noch relativ gut, die 
Brot und Butter Modelle 300 und 600W sind alle ausverkauft

[Rene M. (Firma: Bitte wählen) (renmo)]

Drosseln kann man sie, aber vereinfacht anmelden kann man sie nicht.

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Beides möglich, vielleicht knödle ich testweise mal ergänzend einen
> 0x08-Anfrageversuch rein. Wenn ich den Code richtig verstanden habe,
> müßte man halt statt des "flip-flops" noch eine dritte (bzw. falls das
> wider Erwarten klappt: und 4.) Variante einbauen.

mich nimmt es wunder woher du diese 0x08 hast, die ist im 
RF_communication_protocol-V6.6.xlsx "Data collection instructions" nicht 
beschrieben, oder sehe ichs falsch?

[Günter H. (gnter_h534)]

Sigi S. schrieb:
> das ist eine völlig neue Umgebung für mich.
> Ich fühle mich verloren.
>
> Gibt es eine etwas detailliertere Step By Step Anweisung um das Projket
> zu importieren, erfolgreich zu compilieren, als auch auch zu flashen
> (denke das geht direkt aus Visual Studio Code heraus?)

Mein Vorschlag ist, hier

https://github.com/lumapu/ahoy/actions

die aktuelle (oberste) bin-Datei herunterzuladen (vorher bei GitHub 
anmelden) und mit einem (fast beliebigen) Flash-Programm zu flashen.

Die weitere Inbetriebnahme ist dann hier

https://github.com/lumapu/ahoy/tree/main/tools/esp8266#readme

beschrieben. Zukünftige Updates können dann über die Weboberfläche 
angestoßen werden.

Für eine allgemeine Einführung in PlatformIO bitte im Internet nach 
Tutorials suchen.

[Sigi S. (sermon)]

Günter H. schrieb:
> Mein Vorschlag ist, hier
>
> https://github.com/lumapu/ahoy/actions
>
> die aktuelle (oberste) bin-Datei herunterzuladen (vorher bei GitHub
> anmelden) und mit einem (fast beliebigen) Flash-Programm zu flashen.
>
> Die weitere Inbetriebnahme ist dann hier
>
> https://github.com/lumapu/ahoy/tree/main/tools/esp8266#readme
>
> beschrieben. Zukünftige Updates können dann über die Weboberfläche
> angestoßen werden.
>
> Für eine allgemeine Einführung in PlatformIO bitte im Internet nach
> Tutorials suchen.

Danke,

Compilieren in Platformio bekomme ich nun hin, nur flashen geht nicht.
Mit Nodemcu flasher geht es.
Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500.
Ist das nicht mehr nötig?

Danke

[Ziyat T. (toe_c)]

@Jörg R.

hier ist das sniffer log von DTU-Pro und MI1500, wegen der ch-hopping

[Günter H. (gnter_h534)]

Sigi S. schrieb:
> Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500.
> Ist das nicht mehr nötig?

Doch. Siehe Screenshot.

Hilfe zum Ausfüllen gibt es auch hier:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Marki (Gast)]

Marki schrieb:
> von
>
>         Marki

mit der 5.9.10

Marki schrieb:
> Hallo,
> ich habe zwei Hm-400. Gestern habe ich mir mal die Ahoy version 0.5.4
> geflasht und das erste mal getestet. Funkverbindung über ca 25m ging auf
> anhieb. nur hatte ich vergessen das ich bei Produktion der 2 WR die
> 0Watt in der Setup Seite auf 400 ändere. Seitdem produziert einer der 2
> WR nicht mehr.
> Gibts irgendein reset befehlt? Das er wirklich nicht mehr produziert
> sehe ich an den SDM120, also stimmt die Anzeige in der Ahoy Software.

0.5.10 mal getestet und als Limit 400 eingestellt, dann hat der eine WR 
wieder angefangen zu Produzieren, scheint also in der 0.5.4 ein Bug 
gewesen zu sein.

Wäre es möglich einzubauen, ob die Limitierung überhaupt an den WR 
geschickt wird? Wenn die regelmäßig da hin geschickt wird, ist das 
EEPROM bald kaputt, zumindest bin ich mit fast sicher das es keine 5 
Jahre halten wird.

Ich glaub mal irgendwo in einen Solarforum gelesen zu haben dass die DTU 
Pro zwei verschiedene Möglichkeiten hat, eine Permanente (zb für die 70% 
hier in DEU) und eine für die Nulleinspeisung, die wird aber blos ins 
RAM geschrieben.


Auch wenn die Ahoy-DTU nur einmal am Tag das schicken würde wären es 
schon 365mal in Jahr... Wäre also vielleicht nicht schlecht wenn man die 
Limitierung vielleicht mit einen Button einmal wegschicken kann oder so?

[Marki (Gast)]

Achso, wenn ich mehr als 3 WR will, muss ich irgendwo in einer .h die 
Zahl erhöhen oder?

[Ziyat T. (toe_c)]

Marki schrieb:
> Ich glaub mal irgendwo in einen Solarforum gelesen zu haben dass die DTU
> Pro zwei verschiedene Möglichkeiten hat, eine Permanente (zb für die 70%
> hier in DEU) und eine für die Nulleinspeisung, die wird aber blos ins
> RAM geschrieben.

es gibt keine permanente limit-konstante für den wr, wenn im 
smiles-cloud z.b. 70% eingestellt wird, schickt dtu diese jeden tag 1x.
bei zero-export, es wird dauernd (sie sagen es so, aber leider alle 
15min)  der smartmeter abgefragt, danach wenn nötig der wr limitiert

[Sorbit (Gast)]

Günter H. schrieb:
> Sigi S. schrieb:
>> Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500.
>> Ist das nicht mehr nötig?
>
> Doch. Siehe Screenshot.
>
> Hilfe zum Ausfüllen gibt es auch hier:
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

In dem Screenshot steht nichts vom Typ des WR.
Das war doch die Frage!
Oder erkennt er das über die Seriennummer?

[Günter H. (gnter_h534)]

Stimmt, im Screenshot steht nichts vom Typ des WR - der Typ des WR wird 
über die Seriennummer zugeordnet. Das wird über den verlinkten 
Screenshot deutlich.

[M. P. (matze7779)]

Hallo,

ich habe gerade die 0.5.5 installiert.
Nach dem Update war im Setup das Power Limit auf 0 --> Alles normal
Zum Test auf 300 gesetzt --> WR regelt auf 300 herunter.
Beim Versuch das wieder auf 0 zu stellen bleibt der Wert nach dem Reboot 
auf 300.
Ein Wert von 800 wird angenommen.

WR: HM-800

Gerade auf 0.5.10. Auch hier wird eine "0" bei "Active Power Limit (W)" 
nicht angenommen um das Limit zu deaktivieren.

Und wie bekomme ich den Power Limit Wert in iobroker?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> @Jörg R.
> kannst du bitte diese variante mal testen?

Komme ich vermutlich erst morgen dazu, aber hier noch was interessantes:

15869 Send... CH61 0960100013785634120062.....send res 0
20769 Send... CH61 116010001378563412007A.....send res 0
20985 CH40 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1
ImpExpW Watt 1660.0Watt  | All PVs received?:0
ImpExpW Watt 1440.0Watt  | All PVs received?:0
25669 Send... CH61 0960100013785634120062.....send res 0
25704 CH40 00 1234567801 0082 10 1  88 60100013 60100013 0003000000008BF5C9 1
30569 Send... CH61 116010001378563412007A.....send res 0
30601 CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
ImpExpW Watt 1600.0Watt  | All PVs received?:0
35469 Send... CH61 0960100013785634120062.....send res 0
ImpExpW Watt 1760.0Watt  | All PVs received?:0
40369 Send... CH61 116010001378563412007A.....send res 0
ImpExpW Watt 2490.0Watt  | All PVs received?:0
45269 Send... CH61 0960100013785634120062.....send res 0
ImpExpW Watt 2890.0Watt  | All PVs received?:0
ImpExpW Watt 2690.0Watt  | All PVs received?:0
50169 Send... CH61 116010001378563412007A.....send res 0
55069 Send... CH61 0960100013785634120062.....send res 0
55101 CH40 00 1234567801 0080 10 0  88 60100013 60100013 0003000000008BD40D 1
ImpExpW Watt 2840.0Watt  | All PVs received?:0
59969 Send... CH61 116010001378563412007A.....send res 0
60005 CH40 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1
ImpExpW Watt 2520.0Watt  | All PVs received?:0
ImpExpW Watt 2200.0Watt  | All PVs received?:0
64869 Send... CH61 0960100013785634120062.....send res 0
ImpExpW Watt 2020.0Watt  | All PVs received?:0
69769 Send... CH61 116010001378563412007A.....send res 0
ImpExpW Watt 1620.0Watt  | All PVs received?:0
69984 CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
ImpExpW Watt 1390.0Watt  | All PVs received?:0
74669 Send... CH61 0960100013785634120062.....send res 0
74703 CH40 00 1234567801 0082 10 1  88 60100013 60100013 0003000000008BF5C9 1
79569 Send... CH61 116010001378563412007A.....send res 0
79602 CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
84469 Send... CH61 0960100013785634120062.....send res 0
84502 CH40 00 1234567801 0086 10 3  88 60100013 60100013 0003000000008BB641 1
ImpExpW Watt 1230.0Watt  | All PVs received?:0

Sketch dazu (ziemlich wild (!) anbei. Rahmenbedingungen: der andere ESP 
tuckert munter vor sich hin (seit neulich schon). Die scheinen sich also 
auf CH61 geeinigt zu haben.
Und in der Tat kann man 0x08-Anfragen nicht als solche erfolgreich 
durchführen.

ABER: die 003-er-Antwort kommt soweit ersichtlich immer verlässlich auf 
CH40. Ergo müßte tatsächlich man einen kurzfristigen Switch 
zwischendurch einplanen, und zwar vermutlich immer auf den vorherigen 
(so ist es ja auch im "channel-hop" angelegt). Muss mal bei Gelegenheit 
die Zeitstempel ansehen, ob man erst nach Erhalt der eigentlich 
angefragten Info umschalten sollte, oder erst kurz für die 003-er. 
(falls man die überhaupt braucht. Mit dem Content habe ich mich bisher 
nicht beschäftigt...). Auf die 11-er-Anfrage sehe ich übrigens auch 
häufig die Antworten für beide (zeitlich sehr eng beeinander). Es könnte 
also reichen, nach der 11-er-Anfrage kurz rx umzuschalten (für ca. 
300ms?). Kann aber auch Zufall sein, und es sind Antworten auf die 
Anfragen vom anderen ESP.

Für ein "echtes" Durchrollieren sehe ich im Moment jedenfalls keine 
Veranlassung, und warum die 003-er hin und wieder auch so empfangen 
werden, wissen vermutlich nur die Wifi-Götter....

[Carsten B. (carstenb)]

Jörg R. schrieb:
>> hast du es in FHEM eigentlich noch hinbekommen?
>
> Es gibt einen ersten attrTemplate-Vorschlag dazu im FHEM-Forum. Bitte
> ggf. da anhängen.

Danke, das hat prima funktioniert :-)

https://forum.fhem.de/index.php/topic,121282.0.html

[Jörg R. (rejoe2)]

Carsten B. schrieb:
> Danke, das hat prima funktioniert :-)

:-) Im svn ist übrigens ein update (kommt dann morgen, wenn man es nicht 
manuell holt). Das sollte dann ein paar zwischenzeitlich erkannte 
Problemchen lösen, etwas mehr erläutern und auch für 1- bzw 4-kanalige 
passen.

Ziyat T. schrieb:
> @Jörg R.
> kannst du bitte diese variante mal testen?
läuft grade im Solo-Betrieb seit ca. 20 Minuten. Aber außer 
Sendeanweisungen und Kanalwechseln war da nichts interessantes an 
output.

Habe dann den "normal-Sketch" von vor ein paar Tagen auf dem anderen ESP 
wieder angeschaltet. Der findet den WR anscheinend direkt wieder. Dann 
bekomme ich auch mit diesem Sketch eingehende Nachrichten, aber nur je 
einmal unter CH23 und CH40, direkt nach dem Kanalwechsel, wobei CH23 
dann die 3-Info 88 geliefert hat und CH40 die 3-Info 92 (!)...

Bringt dich das irgendwie weiter?

Nachtrag: Habe mir jetzt den anderen nochmal per mincom angesehen und 
die Zeitstempel betrachtet. Danach scheint es so zu sein, dass der WR 
erst die Statusmessage auf dem unteren Kanal sendet, und dann die 
weiteren Daten. Ergo müßte man (nur!) nach dem Senden der 09/11-Anfragen 
auf den vorherigen Kanal umschalten (längstens für 200 ms?), und könnte 
dann direkt nach dem Empfang der Status-Message wieder auf den 
"default", um den Rest einzufangen.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
>> kannst du bitte diese variante mal testen?
> läuft grade im Solo-Betrieb seit ca. 20 Minuten. Aber außer
> Sendeanweisungen und Kanalwechseln war da nichts interessantes an
> output.

NRF24_SendRcvMIesp4.zip laeuft bei mir recht gut, wenn dein setting ok 
ist dann müsstest du etwas empfangen, oder ist esp+nrf sendet nicht

edit: wegen dieser ch beibehalten geschichte: das gefaellt mir nicht, 
weil  wir für solchen probleme, wie bei deinem MI600 data und status 
pakete, immer andere spez. lösungen haben müssen.
es steht für mich fest (wie wir früher auch herausgefunden haben), dass 
der wr die antworten auf allen ch's schickt, wir müssen halt dann auch 
schnell ch wechseln

[Jörg R. (rejoe2)]

Hmm, weiß nicht...

In den sniff von der DTU habe ich kurz reingeschaut, weiß aber nicht so 
richtig, wie ich das interpretieren soll. Die sendet Anfragen an den 
konkreten WR raus und nimmt dabei scheinbar keine Rücksicht darauf, 
ob/wie sie was empfängt. Ergo geht sie jedenfalls nicht davon aus, dass 
ein bestimmter Kanal besser wäre wie andere (ch09 kommt allerdings vor, 
wenn auch selten, k.A., warum). Auf was sie dann hört wissen wir nicht, 
der Code mit dem "Rücksprung" scheint aber aus dem DTU-Quellcode zu 
kommen.

Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem 
bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage 
kommt.

Du musst die firmware für die Nutzung iVm. der DTU in jedem Fall so 
auslegen, dass deren "Gefunke" dir nicht ins Gehege kommt. 
Nachvollziehbar.

Für mich stellt sich die Situation anders dar:
Ich habe keine DTU und will "einfach nur" den WR auslesen. Ich brauche 
auch nicht alle Nase lang aktualisierte Daten, mir würde es reichen, 
wenn z.B. alle Minute Daten kämen, aber dafür verläßlich.

Bedeutet ggf.: wir bilden eine Queue für alle WR, und versuchen dabei. 
möglichst alle auf einem Kanal zu halten und die Zahl der Umschaltungen 
dabei gering zu halten.
Für alle WR - mit Ausnahme des MI-600 (?) genügt dabei eine Frequenz 
-ergo bekommt der die niedrigste Prio. Ist die Queue soweit durch, dass 
der MI-600 dran ist, fangen wir erst die STS-Msg ab, dann möglichst 
direkt auch
die zugehörige Haupt-Info (1x direkt umschalten, dann zurück). Dto. für 
den 2. Kanal.
Sind wir durch, können wir für den Rest der Zeit gerne hopsen.
Nach jedem WR senden wir die "geballte Info" für diesen WR raus (Wunsch 
wäre JSON-encoded (!)), ggf. auch jeweils pro Kanal. Ggf. versuchen wir 
es ein 2. oder 3. Mal, wenn einer nicht antwortet, aber dann brechen wir 
ab und versenden, was wir haben (falls wir was haben).

Oder habe ich was grundlegend missverstanden?

PS: Die Meinungen der anderen hier, die mehr Erfahrung mit der ganzen 
Sache haben würden mich auch sehr interessieren. Es ist so still...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hmm, weiß nicht...

> Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem
> bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage
> kommt.

das wissen wir nicht, weil wir nicht gleichzeitig mehrere ch's hören 
können. wir "beharren" beim hören auf einen kanal, dann sieht es so aus 
als der wr  diesen auch "gut" findet.
so wars am anfang, wir hörten nur auf CH3, funktionierte schon, aber 
langsam, damit hatte ich ein problem und zwar:

> Ich habe keine DTU und will "einfach nur" den WR auslesen. Ich brauche
> auch nicht alle Nase lang aktualisierte Daten, mir würde es reichen,
> wenn z.B. alle Minute Daten kämen, aber dafür verläßlich.

ich brauche die zeroexport funktion:
da genügt es nicht (mit 4 PVs), irgendwann zu wissen wieviel der wr 
produziert, ich muss schnell (am besten alle 15 sek) wissen was die pv's 
bringen. darum bin ich aufs "ch hopsen beim rx" umgestiegen, so habe ich 
schneller 4 pv's erfassen können.
hier darf man nichts ins netz einspeisen, bzw. es wird als bezug v. netz 
verrechnet, es gibt nur eine art v. zaehler!!

ich habe eine DTU-pro; meine erwartung war, ich sage ihr mach die 
zeroexport mit 0W, und sie macht das. nein, sie kontrolliert eben alle 
5-15min, in der zeit, alles was du nichts konsumierst, wird schön 
eingespeist.
dann hat sie auch das problem mit MI1500, weil er nicht unter 150w 
(10%)limitert werden kann, sie schaltet ihn einfach aus, aber 
einschalten tut sie erst ab 300W konsum und zwar irgendwann!! (edit:über 
dieses problem schweigt der hersteller immer noch)

darum habe ich pi/python/modbus485, damit limitiere den wr selber, die 
DTU-pro ist "inaktiv", wird nur als ss zum wr gebraucht.

[Günter H. (gnter_h534)]

Lukas P. schrieb:
> Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link
> auch jede neuere Version bekommen (ohne Login):
> https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip

Eigentlich ein sehr schöner Service, leider erscheint inzwischen "Error 
404 – Not Found".

[Rene M. (Firma: Bitte wählen) (renmo)]

nimmt man einfach diesen link, da sind dann immer die aktuellen bins 
verfügbar
https://github.com/grindylow/ahoy/actions

[Günter H. (gnter_h534)]

Ist schon klar. Mit dem anderen Link braucht man halt keinen Login bei 
GitHub.

[Jörg R. (rejoe2)]

Ein Log sagt mehr wie viele Worte:

92388 Send... CH61 116010001378563412007A92389
.....send res 0
CH40 00 1234567801 0084 10 2  88 60100013 60100013 0003000000008B9785 1
CH61 00 1234567801 00C6 18 3  89 60100013 60100013 013F003609551382069500DC01787AFCCF 1
92536 CH:61 PV0 MI: 328W Grd:3230W Lm:   0W 168.5W 31.9V 5.4A  220Wh 238.9ACV 49.9Hz 37.6C S:3

Also bei guten Bedingungen ca. 150ms/Abfrage. Auf CH23 sind die 003-er 
auch zu finden, anzunehmen, dass der WR halt auch kurz braucht, um die 
angefragten Werte aufzubereiten.

Gehe davon aus, dass man für einen Mi-1500 bei halbwegs ordentlichen 
Bedingungen also keine Sekunde braucht, um ihn komplett auszulesen, und 
er wirklich DIREKT reagiert, wenn man eine Limitierung versendet.

Code dazu ist anbei.

Leider wird es mir nicht reichen, eine komplette statemachine für die 
Abfrage zu bauen, stelle mir sowas in der Art vor:

static bool received[4]  = {false};
static bool requestOpen  = true;

[...]
     if (MI600){         // 2 PVs
      MIDataCMD=!received[0] ? 0x09 : 0x11;

[...]
    if (MI1500){        // 4 PVs
      MIDataCMD = 0x0036
      for (int8_t i = 0; i < 4; i++) {
        if (!received[i]) {
             break;
        }
        ++MIDataCMD;
       }
     }
[...]
  if (received[0] && received[1] && received[2] && received[3]) {
    tickMillis = millis() + maxTimeForNextPing; //we got a message and will just wait....
    requestOpen  = false;
  }

[...]
  if (p->packet[2] == 0x89)  {PV= 0; TotalP[1]=P_DC; pvCnt[0]=1; received[0]=1; }//port 1
  if (p->packet[2] == 0x91)  {PV= 1; TotalP[2]=P_DC; pvCnt[1]=1; received[1]=1; }//port 2

Hoffe, es ist erkennbar, wie es gemeint ist.

[Christian E. (christian_e775)]

Hallo zusammen,

ich habe seit kurzem einen TSUN TSOL M800(de) und konnte heute relativ 
problemlos mit einem Raspberry + NRF24L01+ + ahoy Daten vom 
Wechselrichter empfangen :)
Mein Wechselrichter hat die Seriennummer 11418203xxxx

> Payload: 00 01 01 49 00 93 01 e2 01 4f 00 3c 00 c9 00 00 25 1e 00 00 18 0b 01 a9 
00 a8 09 02 13 86 02 8c 00 01 00 1c 03 e8 01 9f 00 0b 1e 64
> Decoded: temp=41.5, pf=1.0 phase0=voltage:230.6, current:2.8, power:65.2, 
frequency:49.98 string0=voltage:32.9, current:1.47, power:48.2, total:9.502, 
daily:425 sring1=voltage:33.5, current:0.6, power:20.1, total:6.155, daily:168

Wie man sieht ist der zweite Strang ungünstig positioniert aber das habe 
ich schon vermutet und wollte eigentlich nur eine Bestätigung.

Jetzt muss ich nur noch schauen wie ich das Richtung Volkszähler oder 
ähnlichen schön darstellbar hinbekomme.

Danke,
Christian

[peter (Gast)]

Hallo,

ich will demnächst zwei HM-1500 für einen Netzparallelen Akku mit 
Nulleinspeisung nutzen. Das Projekt scheint ja mittlerweile weit genug 
zu sein um das umzusetzen. Das ganze soll auf venusOS laufen und so habe 
ich als ersten Schritt erstmal ein PCB für den Raspberry PI erstellt 
(siehe Bild).
Bei Interesse kann ich gerne ein paar für euch mitbestellen :)

[Dirk M. (dirk_m695)]

Hi und Gruß in die Runde.

Ich verfolge den Thread seit ein paar Tagen, da ich mir ein 
Balkonkraftwerk installiert habe mit einem TSOL350 Wechselrichter.

Ich bin mit Arduino und AVR Mikrokontrollern vertraut und will Mal 
schauen, ob ich hier was finde, bei dem ich unterstützen kann.

Ich hab auch noch einen Webspace mit ein paar freien URLs übrig. Falls 
das von euch von Interesse wäre, könnte ich euch anbieten, dass man dort 
z.B. ein Forum einrichtet inkl. Admins von euch.

Außerdem kann ich Android Apps erstellen. Vielleicht wäre es ja 
interessant, dass man sich die Daten der Wechselrichter über einen 
NRF+ESP aufs Handy anzeigen lassen kann.

Einen 3D Drucker zum Drucken von Gehäusen hätte ich ebenfalls. Für den 
Fall, dass es Mal eine gute Idee für einen all-in-one System gibt.

Auf jeden Fall schon Mal danke dafür, dass ihr so ein Projekt aufgezogen 
habt aus einer so einfachen Frage, die im ersten Beitrag steht.

[Sigi S. (sermon)]

Dirk M. schrieb:
> Vielleicht wäre es ja
> interessant, dass man sich die Daten der Wechselrichter über einen
> NRF+ESP aufs Handy anzeigen lassen kann.

Vielleicht solltest Du dich etwas genauer mit der bestehenden Lösung 
auseinandersetzen? ;-)

[Frank L. (guilligan)]

Nach dem ich auf 0.5.12 aktualisiert habe, waren wieder alle 
Einstellungen weg. Sogar im ESP musste zunächst das Netzwerk 
eingerichtet werden.
Es ist als 3. Inverter einer fest eingetragen, der sich löschen lässt, 
aber nach reboot wieder da ist. Mqtt Intervall steht auf 0(read only.
Sonst läuft es bis jetzt besser als die 0.5.10.
Kann mir jemand sagen, was die minimalen Limitierungen für den hm-600 
und hm-1500 sind? Oder kann ich beide auf 0 setzen über Mqtt? Ich schon 
öfters von min 10% gelesen ???

[Carsten B. (carstenb)]

Frank L. schrieb:
> Kann mir jemand sagen, was die minimalen Limitierungen für den hm-600
> und hm-1500 sind?

Hallo,

in der Hoymiles-Doku finde ich dazu:

Percentage
2~100 for HM series
10~100 for MI series

Wenn ich über das Webinterface das Limit bei meinem HM600 setze, komme 
ich bei einem Wert von 10 auf etwa 60W Ausgangsleistung. Kann es sein, 
dass die Werte jetzt nicht merh absolut in W sind sondern relativ in %?

Siehe auch: https://github.com/grindylow/ahoy/issues/154

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> Jörg R. schrieb:
>> Hmm, weiß nicht...
>
>> Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem
>> bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage
>> kommt.
>
> das wissen wir nicht, weil wir nicht gleichzeitig mehrere ch's hören
> können. wir "beharren" beim hören auf einen kanal, dann sieht es so aus
> als der wr  diesen auch "gut" findet.
Hmmm, also:
Für den MI-600 (und vermutlich alle älteren) bin ich jetzt ziemlich 
sicher, dass der die STS-MSGs über Anfrage-Channel (- 1) bzw. (- 2) 
raushaut, seit der eine ESP den WR auf Kanal 61 festgenagelt hat, hat 
beides funktioniert. Scheinbar ist (- 1) etwas schneller, unklar ist 
noch,
- ob dann auch auf (- 2) (CH23) was zu sehen wäre;
- ob das wechselt (muss das nochmal kritisch beäugen und ggf. auch den 
Empfangskanal nochmal zwischendurch manipulieren?), und woran es liegt, 
dass manchmal (?) eine lange Message kommt und manchmal kein "Paar" zu 
sehen ist, sondern eine einzelne Message - im Moment gehe ich noch von 
Nebenwirkungen des weiteren ESP's aus...
Jedenfalls für den Empfang der "Hauptmessage" darf man den Kanal nicht 
auf was anderem haben als dem der Anfrage.

Damit dürfte zumindest klar sein, warum in den ersten Versionen des 
Sketches für den MI-600 nur so wenige "Treffer" dabei waren, dabei die 
003-er-Messages überwiegt haben und die Timing-Änderung vermeintlich 
eine Besserung gebracht hat - das ganze war schlicht nicht aufeinander 
abgestimmt...

> so wars am anfang, wir hörten nur auf CH3, funktionierte schon, aber
> langsam, damit hatte ich ein problem und zwar:
Das Problem kann ich nachvollziehen, wobei ich gerne verstehen würde, wo 
die Ursache für das Symptom liegt. Wenn es ein starres Verhältnis 
zwischen Sende- und Empfangskanal gibt (was ich zumindest für die alten 
WR vor MI-1500 vermute), könnte das schlicht daran gelegen haben, dass
- der Sendekanal gewechselt hatte, und/oder
- die DTU (schneller) was empfangen hat und dann der WR aufgehört hat zu 
senden (HW-ACK-Auswertung)

> da genügt es nicht (mit 4 PVs), irgendwann zu wissen wieviel der wr
> produziert, ich muss schnell (am besten alle 15 sek) wissen was die pv's
> bringen. darum bin ich aufs "ch hopsen beim rx" umgestiegen, so habe ich
> schneller 4 pv's erfassen können.
Wie gesagt: wenn der wirklich auf einem (vorhersagbaren) anderen Kanal 
zurücksendet als angefragt wird, müßten wir Zeiten deutlich noch unter 
15 Sekunden erzielen können! Wir sollten uns m.E. auch beim Rollieren 
jedenfalls merken, wo der letzte Treffer war und das irgendwie einbauen 
(zumindest in das DEBUG).

Das "Problem" der jetzigen ino ist m.E. noch, dass wir keinerlei Prüfung 
haben, ob die Daten noch aktuell sind. Einmal bei dem MI-600 alle Kanäle 
empfangen ergibt "alle PV's sind da", und zwar soweit erkennbar auch 
noch am nächsten Tag usw....

In diesem Zusammenhang bin ich dann noch über diesen Beitrag gestolpert:

Stefan T. schrieb:
> Hallo Zusammen,
>
> der RECV_CHANNEL 0x61 ist m.W. der mit dem er loslegt. Es wurde bei
> ersten Tests herausgefunden, dass bei TX auf Kanal 0x61 die nächste
> Antwort auf Kanal 0x03 relativ gut empfange wurde, d.h. zwei Kanäle
> Unterschied. Ob das am Timing zwischen Senden und Empfangsbereitschaft
> des Ahoy DTU Codes ist, oder etwas anderes weiß ich nicht.

Alles in allen wird mir nun auch klar, warum wir mit der "Hopserei" und 
deren Notwendigkeit so aneinander vorbei geredet haben und/oder es User 
gibt, die teils über sehr lange Synchronisierungszeiten klagen: Alles 
vor MI-1500 tickt an der Stelle wohl wirklich komplett anders - und ich 
sehe auch keinen großen Sinn darin, den Code-Ablauf groß anders zu 
gestalten wie "Merke dir den aktuellen Sende-Channel, hau reichtzeitig 
Anfragen drüber. Schalte nach dem Senden direkt den Empfangskanal 
'zurück' und direkt auch wieder hoch, sobald da was gekommen ist (oder 
zu lange nichts)".
Damit bekommt man ziemlich sicher punktgenau einen aktuellen und 
konsistenten Satz Infos vom WR.

Bleibt die Frage, wie man das ggf. auf den MI-1500 (und später?) 
übertragen kann, v.a. auch, um die Synchronisierungszeiten zu 
verbessern...
Auch bei den neueren Modellen würde es mAn. Sinn machen, sich den 
aktuellen "besten Empfangskanal" zu merken (und dann "erst mal" den 
anzufahren?). Die Frage wäre, ob das auch (-1) bzw. (-2) wäre, und ggf. 
nach welcher Logik was anderes auszuwählen wäre...

Wie arbeitest du denn grade sendeseitig? Ist das auch rollierend oder 
irgendwie festgezurrt?

[Ralla66 (Gast)]

Zufälliges Channel hopping eher weniger, wohl ein Algo aus bester 
Signalstärke pro Channel und gültiger CRC das die DTU auswertet.

[Jörg R. (rejoe2)]

Ralla66 schrieb:
> Zufälliges Channel hopping eher weniger, wohl ein Algo aus bester
> Signalstärke pro Channel und gültiger CRC das die DTU auswertet.
Muss darüber nochmal nachdenken, aber zum Thema "Signalstärke" eine 
kurze Rückfrage: Üblicherweise wird ja sowas als RSSI angegeben. Jetzt 
ist mir aus der MySensors-nRF-Ecke noch im Ohr, dass das die nRF-Chips 
nicht unterstützen und man bei MySensors daher auf die entsprechende 
Debug-Anfrage auch "nur" sowas bekommt wie einen Pseudo-RSSI (wie auch 
immer der gebildet wurde).

Als Indikator würde ich sehen:
- Zahl der Retry's, bis ein Hardware-Ack kommt (da muss afaik der CRC 
passen)
- ob überhaupt eines kommt
- (zuletzt)
-- Zeit, bis eine Antwort kommt (je kürzer, desto besser)
-- Verhältnis der Messages mit gültigem CRC / Gesamtzahl von einer 
Gegenstelle (kann sein, dass das die MySensors-Lösung ist).
-- das ganze ggf. unter Berücksichtigung der Frage, wie starkt ggf. der 
Anfragende (ESP) sowie die Gegenseite ausgelastet ist (Zusammenstellen 
von Daten).
Oder kennt ihr noch weitere Indikatoren?

Habe wg. des Frequenz-Wechsel-Themas nochmal das sniffer-log aus 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
angesehen. Danach sieht das so aus, als würden zumindest manche der 
Anfragen auch noch innerhalb dieses Zykluses auf derselben Frequenz 
beantwortet - warum auch immer das grade dann da so ist (mir fehlen 
irgendwie da Zeitstempel-Infos, und was z.b. (27/0/0) bedeuten soll, 
müßte ich auch erst mal nachlesen). Das sieht jedenfalls nicht unbedingt 
danach aus, als müßte man bei dem MI-1500 die Sende- und 
Empfangsfrequenz entkoppeln, und auch die "fehlenden" Antworten aus 
diesem Zyklus kommen dann in den folgenden Nachrichten auf dem nächsten 
Kanal?
Folgt das der Logik: Wenn du eine erhaltene Anfrage nicht mehr zustellen 
kannst, speichere sie und sende das dann auf dem nächsten Kanal? (Weil 
die DTU weitergezogen ist?).

[Ralla66 (Gast)]

Signalstärke wäre ja wichtig, wo wenig Signal oder gar keins da liegt ja 
nahe das die Daten falsch sind oder nicht vorhanden.Gefiltert nach den 
20 Signalstärksten wäre gut. Danach diese 20 gefilterten auf gültige CRC 
prüfen.
Die besten 8 abspeichern. Danach wieder von vorne.
Ich lese mal das Datasheet vom NRF, das muß doch gehen mit der 
Signalstärke, Krücke würde ja reichen.

[Jörg R. (rejoe2)]

Anbei eine weitere Iteration des Sketches für MI-xxx - "nicht zum 
Verzehr geeignet" (da ist noch ein größerer Bug drin, aber die ersten 
paar Ausgaben bis zum unbeabsichtigten "Dauerfeuer" sind trotzdem sehr 
aufschlussreich)...

CH40 00 1234567801 0086 10 3  88 60100013 60100013 0003000000008BB641 1
24382 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C0 18 0  89 60100013 60100013 0143000C091A1380018E057E00F645D490 1
24430 CH:61 PV0 MI:  39W Grd: 730W Lm:   0W 39.8W 32.3V 1.2A 1406Wh 233.0ACV 49.9Hz 24.6C S:3 
24433 Send... CH61 116010001378563412007A24438
.....send res 0
backchannel timed out...
24868 Send... CH61 116010001378563412007A24869
.....send res 0
25098 Send... CH61 116010001378563412007A25099
.....send res 0
backchannel timed out...
25528 Send... CH61 116010001378563412007A25529
.....send res 0
CH40 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1
25562 CH:40: MI300/MI600 status message
25758 Send... CH61 116010001378563412007A25759
.....send res 0
25988 Send... CH61 116010001378563412007A25989
.....send res 0
CH40 00 1234567801 0084 10 2  92 60100013 60100013 000300000000915618 1
26022 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C6 18 3  91 60100013 60100013 0142000C09181380018D058100F6A21C02 1
26064 CH:61 PV1 MI:  79W Grd: 730W Lm:   0W 39.7W 32.2V 1.2A 1409Wh 232.8ACV 49.9Hz 24.6C S:3 
CH61 00 1234567801 00C4 18 2  91 60100013 60100013 0142000C091C1380018F058100F7A5F2C9 1
34519 CH:61 PV1 MI:  79W Grd: 730W Lm:   0W 39.9W 32.2V 1.2A 1409Wh 233.2ACV 49.9Hz 24.7C S:3 
CH61 00 1234567801 00C6 18 3  89 60100013 60100013 0143000C091E13810190057E00F75FA982 1
39526 CH:61 PV0 MI:  79W Grd: 730W Lm:   0W 40.0W 32.3V 1.2A 1406Wh 233.4ACV 49.9Hz 24.7C S:3 
CH61 00 1234567801 00C6 18 3  91 60100013 60100013 0142000C091C137B0192058100F7432BAC 1
49616 CH:61 PV1 MI:  80W Grd: 730W Lm:   0W 40.2W 32.2V 1.2A 1409Wh 233.2ACV 49.9Hz 24.7C S:3 
50001 Send... CH61 116010001378563412007A50002

[Ralla66 (Gast)]

Zitat:
There is an RSSI register in nRF24L01+, the address is 0x09, the 0th bit 
of this register represents the current channel signal strength. When 
the received signal strength is less than -60dBm, bit 0 is 0, when it is 
greater than -60dBm it is 1.
Ch die nicht / wenig senden können so gefunden werden, die am meisten 
senden CRC prüfen.So der Gedanke.

[Jörg R. (rejoe2)]

Vielleicht gefunden, warum dann keine Pause mehr war, nachdem der erste 
"Satz" komplett war...

[Jörg R. (rejoe2)]

Jörg R. schrieb:
> Vielleicht gefunden, warum dann keine Pause mehr war, nachdem der erste
> "Satz" komplett war...
Eher nicht, das war jedenfalls nicht alles gewesen.

Hatte gestern dann noch lange vor Sonnenuntergang beide ESP abgeklemmt.

Einer der Startvorgänge von heute morgen:

SerialIn: 4 Cmd:4
33823 Send... CH23 096010001378563412006233825
.....send res 0
34054 Send... CH40 096010001378563412006234055
.....send res 0
34284 Send... CH61 096010001378563412006234285
.....send res 0
34514 Send... CH75 096010001378563412006234515
.....send res 0
backchannel timed out...
34944 Send... CH03 096010001378563412006234945
.....send res 0
35174 Send... CH23 096010001378563412006235175
.....send res 0
backchannel timed out...
35604 Send... CH40 096010001378563412006235605
.....send res 0
backchannel timed out...
36034 Send... CH61 096010001378563412006236035
.....send res 0
backchannel timed out...
36464 Send... CH75 096010001378563412006236465
.....send res 0
backchannel timed out...
36894 Send... CH03 096010001378563412006236895
.....send res 0
backchannel timed out...
37324 Send... CH23 096010001378563412006237325
.....send res 0
37554 Send... CH40 096010001378563412006237555
.....send res 0
CH40 00 1234567801 0084 10 2  88 60100013 60100013 0003000000008B9785 1
37587 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C6 18 3  89 60100013 60100013 00BA000208FD13860029000000BAC24075 1
37639 CH:61 PV0 MI:   4W Grd:  50W Lm:   0W  4.1W 18.6V 0.2A    0Wh 230.1ACV 50.0Hz 18.6C S:3 
37642 Send... CH61 116010001378563412007A37647
.....send res 0
backchannel timed out...
38076 Send... CH61 116010001378563412007A38077
.....send res 0
backchannel timed out...
38506 Send... CH61 116010001378563412007A38507
.....send res 0
38736 Send... CH61 116010001378563412007A38737
.....send res 0
38966 Send... CH61 116010001378563412007A38967
.....send res 0
CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
39000 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 00E7000208FE13860030000000BA9D66BA 1
39040 CH:61 PV1 MI:   8W Grd:  50W Lm:   0W  4.8W 23.1V 0.2A    0Wh 230.2ACV 50.0Hz 18.6C S:3

[Frank L. (guilligan)]

0.5.12. #40 super Entwicklung.
Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die 
Produktion fast immer 10watt unter der Limitierung liegt.
Hat jemand gleiches beobachtet?

[Andreas (dicc)]

Moin,
super Projekt!
Was mir hier fehlt, oder ich finde es nicht, ist eine Zusammenstellung 
aller benötigter Komponeten und Software mit welcher z.B. der ESP 
gefasht wird! ich hab in der Vergangenheit mit der Arduino Software 
gearbeitet das denke ich geht hier nicht! Bin kein kompleter Leihe aber 
ich will halt das meinen WR ans laufen bringen (überwachen)!
Eine Schritt für Schritt Anleitung für "Halbdummies" fände ich super!

Ansonsten super Arbeit!

Grüsse
Andreas

[Simon S (Gast)]

Woran kann es liegen dass sich der ESP nicht mit dem WLAN verbinden will 
und jedes Mal nach einem Neustart die Konfiguration verwirft?

Habe immer das neuste Release 
(https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini 
geflasht.

Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen 
kappt es nicht wirklich und es kommt zu einem Bootloop.

[Ha F. (harry_f)]

Simon S schrieb:
> Woran kann es liegen dass sich der ESP nicht mit dem WLAN
> verbinden will
> und jedes Mal nach einem Neustart die Konfiguration verwirft?
>
> Habe immer das neuste Release
> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini
> geflasht.
>
> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen
> kappt es nicht wirklich und es kommt zu einem Bootloop.

Wie sieht die Stromversorgung aus?
Vom PC aus über USB-Port?
Über ein Netzteil? Evlt zu schwach?

Auch mal nur den nackten D1 Mini getestet ohne Anbauteile?

[Ha F. (harry_f)]

Andreas schrieb:
> Moin,
> super Projekt!
> Was mir hier fehlt, oder ich finde es nicht, ist eine Zusammenstellung
> aller benötigter Komponeten und Software mit welcher z.B. der ESP
> gefasht wird! ich hab in der Vergangenheit mit der Arduino Software
> gearbeitet das denke ich geht hier nicht! Bin kein kompleter Leihe aber
> ich will halt das meinen WR ans laufen bringen (überwachen)!
> Eine Schritt für Schritt Anleitung für "Halbdummies" fände ich super!
>
> Ansonsten super Arbeit!
>
> Grüsse
> Andreas

- für das erste mal flashen zB mit: 
https://github.com/tasmota/tasmotizer/releases
später über OTA:  IP/update
- das bin-File von hier https://github.com/grindylow/ahoy/actions
- danach neu starten, mit dem WLAN des ESP verbinden und im WebIf 
einrichten.

[Jörg R. (rejoe2)]

Das "Gehopse" und manche Zufälligkeiten (warum scheint meiner den Kanal 
0x61 so zu mögen?!?) lassen mich nicht so richtig in Ruhe - und siehe 
da, in 
https://www.mikrocontroller.net/attachment/559626/Micro-inverse_system_related_product_ID_coding_rules-A3-20190712.docx 
steht ziemlich am Anfang was interessantes. Es gibt nicht nur Geräte, 
die explizit als Repeater eingesetzt werden können, sondern für DTU's, 
Repeater und WR gilt:
>The "8~12" bits are the pipeline coding (currently in decimal), the 
micro-inverter, repeater, and DTU share the same pipeline sequence, which is coded 
in sequence and must not be repeated, a total of 99999 bits.
Hmmm, ist etwas kryptisch, aber es klingt jedenfalls danach, als sei 
eine bestimmte Kombination der letzten 5 Ziffern der Seriennummern der 
beteiligten Geräten dafür ausschlaggebend, wann (im Sinne einer 
Zeitscheibe?) und auf welchem Kanal (?) ein Gerät Nachrichten versendet 
bzw. empfängt.

Eventuell hat hoymiles da auch irgendwann das Konzept dazu geändert?

Na ja, wie dem auch sei, in hmDefines.h gibt es z.B. hm1chAssignment[], 
und danach scheint die Zuordnung bestimmter Infos zu bestimmten Kanälen 
fest zu sein?

Das würde auf den MI-600 nur eingeschränkt passen, wie gesehen wäre es 
optimal, wenn
a) der (aktuell) richtige Sendekanal für den MI bekannt ist, und
b) der RX-Kanal noch für kurze Zeit (50-100ms?) auf dem davor liegenden 
Kanal (?) verbleibt und danach auch auf den aktuellen TX-Kanal 
umgeschaltet wird.
Wie das zeitlich in der app.cpp eingetacktet ist: noch k.A..

Zu den aktuellen Punkten auf der Roadmap:
>app.cpp aufräumen und in hmRadio / hmProtokollGen3 auslagern
In hmRadio gibt es derzeit die Funktion "sendPacket". Kommt mir aus der 
"kleinen ino" bekannt vor, stellt aber ihrerseits dann auch den Sende- 
und Empfangskanal um. Irgendwie müßten wir für den Fall der Koexistenz 
von verschiedenen Typen dafür sorgen, dass es zusammenpaßt, was da 
passiert....

Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten 
Ergebnisse dann in json zu verpacken (gerne optional).

Ich werde jetzt erst mal versuchen, eine etwas generalisierte Fassung 
der "kleinen ino" für MI zu bauen, die man dann ggf. auch als separates 
Tool anbieten kann? Vielleicht meldet sich ja doch noch jemand, der ein 
etwas abweichendes setup hat als Ziyat T und ich...
Oder bestehen da prinzipielle Einwände?

[Simon S (Gast)]

Ha F. schrieb:
> Simon S schrieb:
>
>> Woran kann es liegen dass sich der ESP nicht mit dem WLAN
>> verbinden will
>> und jedes Mal nach einem Neustart die Konfiguration verwirft?
>> Habe immer das neuste Release
>> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini
>> geflasht.
>> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen
>> kappt es nicht wirklich und es kommt zu einem Bootloop.
>
> Wie sieht die Stromversorgung aus?
> Vom PC aus über USB-Port?
> Über ein Netzteil? Evlt zu schwach?
> Auch mal nur den nackten D1 Mini getestet ohne Anbauteile?

Sowohl USB am PC, als auch mit eigenem Netzteil.
Sowie mit und ohne Anbauteile.
Werde mal das letzte Debug Build flashen und schauen ob ich so mehr 
Informationen auslesen kann.

[Simon S (Gast)]

> für das erste mal flashen zB mit:
> https://github.com/tasmota/tasmotizer/releases
> später über OTA:  IP/update
> das bin-File von hier https://github.com/grindylow/ahoy/actions
> danach neu starten, mit dem WLAN des ESP verbinden und im WebIf
> einrichten.

Genau so hab ich es auch gemacht, doch leider verwirft er bei mir immer 
die WLAN Konfiguration

[Hfhausen (Gast)]

Jörg R. schrieb:
> Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten
> Ergebnisse dann in json zu verpacken (gerne optional).

IP/json sollte schon vieles liefern.

[Carsten B. (carstenb)]

Frank L. schrieb:
> 0.5.12. #40 super Entwicklung.
> Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die
> Produktion fast immer 10watt unter der Limitierung liegt.
> Hat jemand gleiches beobachtet?

Hallo,

ich habe mir grade die 5.13 installliert. Da hat sich beim Limit noch 
ganz vie lgetan (danke an alle für die tolle Weiterentwicklung!).

Ich werde morgen (das Wetter scheint ja ok zu werden) ausgiebig mit den 
Limits testen und berichten.

Carsten

[Ralla66 (Gast)]

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.

[Andreas S. (drschiffler)]

Carsten B. schrieb:
> Frank L. schrieb:
>> 0.5.12. #40 super Entwicklung.
>> Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die
>> Produktion fast immer 10watt unter der Limitierung liegt.
>> Hat jemand gleiches beobachtet?
>
> Hallo,
>
> ich habe mir grade die 5.13 installliert. Da hat sich beim Limit noch
> ganz vie lgetan (danke an alle für die tolle Weiterentwicklung!).
>
> Ich werde morgen (das Wetter scheint ja ok zu werden) ausgiebig mit den
> Limits testen und berichten.
>
> Carsten
Hallo Carsten,

danke für die Bereitschaft zu testen.
Nimm bitte die Version von hier:
https://github.com/aschiffler/ahoy/actions/runs/2869788679

Ist auch 0.5.13 nur hier habe ich noch eine kleine Verbesserung für MQTT 
einbauen müssen. Nach den Tests -- ca. 2-3 User wollen testen -- werden 
wir auf dem main dann ein neues Release bereitstellen inklusive pot. 
fixes.
Siehe auch als Anleitung:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md

[Simon S (Gast)]

Simon S schrieb:
> Woran kann es liegen dass sich der ESP nicht mit dem WLAN
> verbinden will und jedes Mal nach einem Neustart die Konfiguration
> verwirft?
> Habe immer das neuste Release
> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini
> geflasht.
> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen
> kappt es nicht wirklich und es kommt zu einem Bootloop.

Lag wohl ab einem defekten Wemos D1 mini, hatte noch einen anderen auf 
dem es jetzt problemlos funktioniert.

[Dirk S. (fusebit)]

Moin,

ich habe gerade von 5.10 auf 5.13 ein OTA Update gemacht.
Danach hat sich der ESP wieder als AP gemeldet, aber keine 
Konfigurationsseite geöffnet.
Nachdem ich über USB wieder auf 5.10 gewechselt habe lief es sofort 
wieder im normalen Modus (hat also die WLAN Info im EEPROM gefunden).

5.13 funktioniert auch nicht, wenn ich es über USB einspiele.

[Jörg R. (rejoe2)]

Hfhausen schrieb:
> Jörg R. schrieb:
>> Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten
>> Ergebnisse dann in json zu verpacken (gerne optional).
>
> IP/json sollte schon vieles liefern.
Zum einen spiele ich grade noch mit "der kleinen ino" rum und sehe im 
Moment nur, was andere User an Topics (automatisch) abbonniert haben. Da 
war dieser Topic jedenfalls bislang gar nicht zu sehen.
Zum anderen war ich etwas unpräzise: Wünschen würde ich mit je getrennte 
Topics für
- den ESP an sich (obiger tree?)
- jeden WR (uU. noch getrennt nach AC+jedem DC-Eingang, aber in jedem 
Fall unter einem Sub-Topic, der dem WR zugeordnet ist)

Klasse wäre auch, wenn "signifikante Änderungen" (auf Bestellung?) vor 
Ablauf der normalen Periode gemeldet würden (Ausfall eines Eingangs oder 
von AC, Änderungen über z.B. 10% der Leistung oder 15/20W etc. tb. 
discussed).

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.
Eine klare Logik kann ich hinter den Zahlen (auch mit meiner WR-Nummer) 
nicht erkennen. Beim Durchflözen der Rückmeldungen hier ist nur eben 
auffällig, dass viele sehr zufrieden sind, es bei manchen "ewig" 
braucht, bis eine Synchronisation da ist und wieder andere anscheinend 
gar keine Daten bekommen - warum auch immer.

Jedenfall habe ich heute nacht mal den WR auch von AC genommen. Damit 
sollte der "resettet" sein? Dann lief er eine Weile, bevor dann einer 
meiner Versuchs-Codes "randurfte". Im Ergebnis wollten sich beide dann 
wieder auf Kanal 0x61 einigen. ABER: zwischendurch kam auch über CH40 
eine 0x91-er Message rein. Interessant dabei ist, dass der Code zu 
diesem Zeitpunkt ausschließlich auf Kanal 0x61 sendete, der WR also 
vielleicht noch versucht hat, die Status-Messages 0x88 und 0x92 
zuzustellen? Und die Daten bereits aufbereitet hatte für den Fall, dass 
der ESP empfangsbereit ist?
(oder meine ausgegebenen Infos irgendwie unsauber sind...)

Na ja, wie dem auch sei, werde jetzt auch versuchsweise wieder zu 
starren Tick-Zeiten zurückgehen und den Empfangskanal "hart" an den 
Sendekanal binden (-1). Kommt dann die 89 Antwort im Zeithorizont von 
"senden+200" bis "senden+400" (oder ein HW-Ack), ist das der "richtige 
Channel" und künftige Sendungen sollten dann (erst mal nur) über diesen 
Kanal rausgehen - also muss bei "isTime2Send()" zusätzlich noch geprüft 
werden, ob wir auf der passenden "Zeitscheibe" sind und die bei "bisher 
Fehlanzeige" dann auch gewechselt werden.
Mal schauen.

[Ralla66 (Gast)]

Die Channels werden ja im Register Map Table Adresse 05 Bit 0 - 6 
geschrieben oder gelesen.
Könnte mir vorstellen das jede Pipe einen eigenen Channel bekommt für WR 
bezogene Daten.Eben errechnet aus den Serial IDs der DTU und WR.Dann 
wäre die Channel Number in den Daten der Pipe zu suchen und zum Senden 
vermutlich am Anfang gesetzt.

[Frank L. (guilligan)]

Kennt jemand den mqqt Befehl um das aktuell gesetzte limit auszulesen 
bzw. wird das gesendet und man kann es über ein subscribe verwenden?

[Jörg R. (rejoe2)]

Ralla66 schrieb:
> Die Channels werden ja im Register Map Table Adresse 05 Bit 0 - 6
> geschrieben oder gelesen.
> Könnte mir vorstellen das jede Pipe einen eigenen Channel bekommt für WR
> bezogene Daten.Eben errechnet aus den Serial IDs der DTU und WR.Dann
> wäre die Channel Number in den Daten der Pipe zu suchen und zum Senden
> vermutlich am Anfang gesetzt.

MAn. ist aus WR-Sicht eher die Frage des "optimalen Empfangs" relevant.

Ein nRF kann nach meinem laienhaften Verständnis (zu einem bestimmten 
Zeitpunkt) immer nur
- entweder Senden oder Empfangen, und das ganze
- immer nur auf genau einem Kanal

Da der Aufwand für eine eigene (exakte) Uhr auf jedem WR vermutlich viel 
zu groß ist, fangen die bei jedem DC-Zyklus (näherungsweise) bei "0" an. 
Was sie wissen, ist
- die eigene Nr.
- (vielleicht) den letzten Kanal, auf dem sie angefunkt wurden, und
- bestenfalls (!) die ID ihrer Gegenstelle, also (Repeater oder) DTU.

Ergo müßte es eigentlich das einfachste sein, die Dinger schlicht auf 
"ihrem Kanal" auf die Lauer zu legen und auf Signale zu warten. 
Vielleicht mal Wechseln, wenn zu lange nichts kommt. Das würde dann 
bedeuten: etwas mehr wie eine Sekunde (=1 DTU-Zyklus?) auf einen anderen 
Kanal wechseln, dort lauschen, dann wieder zurück, ebenfalls für mind. 
einen Zyklus, dann wieder den nächsten.
Eine eventuelle Antwort dann "rückwärts" auf dem vorherigen Kanal 
versenden, in der Erwartung, dass die DTU genau dort lauscht, bei 
"Unzustellbarkeit" dann die Kanäle wechseln (seltsamerweise scheint mein 
MI noch einen Kanal weiter zurück zu gehen, wenn er die Status-Message 
nicht an den Mann bringt? Der WR war dann aber nach etwas weniger als 
200ms wieder auf dem Hauptkanal, um die Hauptinfo zu versenden). Wenn 
die Zustellung klappt, wird ggf. die folgende Message (in etwa) "im Takt 
mit den Kanalwechseln" dann auch versendet?
Der "eigene Kanal" bleibt bei Versandproblemen nach dem 1. Zyklus frei, 
damit der WR hier auf weitere Anweisungen lauschen kann?

"Zuzuhören" scheint (!) mein MI jedenfalls mehr oder weniger 
ausschließlich auf Kanal 0x61... (wenn ich dran denke, wird dieser Kanal 
mal aus der Liste genommen, mal sehen, ob (und ggf. wie/wo/wann) dann 
eine Kommunikation zustande kommt; aber erst muss der Code ohne solche 
Spielereien erst mal so laufen wie gedacht...).

[Marcel S. (marcel_s750)]

Hallo,

erstmal vielen Dank für das coole Projekt!

An die iobroker-User unter uns, ich würde gerne das nicht-persistente 
Powerlimit per MQTT setzen, dazu habe ich den Datenpunkt angelegt (und 
siehe Bild), nach den Kriterien, wie sieh hier hinterlegt sind: 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md

"mqtt.0.Ahoy.devcontrol.114172608859.11.0"

Leider passiert in Ahoy gar nichts :-( wie habt ihr den Datenpunkt 
angelegt?

Danke schon mal!

Marcel

[Rene M. (Firma: Bitte wählen) (renmo)]

@Marcel
du musst auch
mqtt.0.Ahoy.devcontrol.0.11
nehmen.

[Marcel S. (Gast)]

Rene M. schrieb:
> @Marcel
> du musst auch
> mqtt.0.Ahoy.devcontrol.0.11
> nehmen.

Hmm, dann ist die Anleitung falsch. Hab es gerade ausprobiert, 
funktioniert aber leider auch nicht, sondern führt genau wie die andere 
Variante direkt zu einem reboot.
Welche Version hast du denn installiert? Hab die 0.5.14

[Ralla66 (Gast)]

An Jörg R.
Sehe ich ähnlich, aus der Spec vom NRF geht ja hervor das zwischen RX 
und TX gezielt geschaltet werden kann. Eine gute Verbindung wird ja bei 
RX in RDP 09 gesetzt. Ein Register für Ch habe ich in der Spec nicht 
gefunden. Dann wäre die einfachste Variante den CH mit zu senden im 
ersten Paket bei der Kontaktaufnahme zwischen den Teilnehmern.

[Sigi S. (sermon)]

Hallo,

ich habe 2 neue AZ-Delivery NodeMCU LolinV3 probiert.
Prozessor ESP8266MOD, Modell 12-F.

Compiliert ohne Fehler mit folgenden Settings:

platform = espressif8266
framework = arduino
board = esp12f
board_build.f_cpu = 80000000L
upload_port = COM5

Upload auch ohne Probleme.


Leider spannt er kein eigenes WLAN auf.

Version ist von letzter Woche.

Hat jemand einen Hinweis für mich?
Danke
Achso auf der Seriellen Schnittstelle empfange ich nur Schmierzeichen 
mit 115200 Baud

[Sigi S. (sermon)]

Sigi S. schrieb:
> Hallo,
>
> ich habe 2 neue AZ-Delivery NodeMCU LolinV3 probiert.
> Prozessor ESP8266MOD, Modell 12-F.
>
> Compiliert ohne Fehler mit folgenden Settings:
>
> platform = espressif8266
> framework = arduino
> board = esp12f
> board_build.f_cpu = 80000000L
> upload_port = COM5
>
> Upload auch ohne Probleme.
>
> Leider spannt er kein eigenes WLAN auf.
>
> Version ist von letzter Woche.
>
> Hat jemand einen Hinweis für mich?
> Danke
> Achso auf der Seriellen Schnittstelle empfange ich nur Schmierzeichen
> mit 115200 Baud

Hallo,

mit einem NodeMCU Flasher von:

This programmer can flash esp8266 by one click.
Our website is http://www.nodemcu.com
Our Tencent QQ Group:309957875

wird eine FW geflashed und es funktioniert so weit.
(Warum tut Platformio als hätte alles geklappt?!)

In der neuen GUI sehe ich kein Feld um meinen WR Typ HM1500 einzutragen.
Die Hinweise hier im Forum klären das auch nicht eindeutig.

Wo muß der Typ eingetragen werden???

[Rene M. (Firma: Bitte wählen) (renmo)]

@Marcel
sollte schon klappen.
Sieh dir einmal meinen Screenshot an.
Klappt schon seit 0.0.8 oder so.

[Carsten (Gast)]

Andreas S. schrieb:
> Hallo Carsten,
>
> danke für die Bereitschaft zu testen.
> Nimm bitte die Version von hier:
> https://github.com/aschiffler/ahoy/actions/runs/2869788679
Hallo,

leider hat moch die Arbeit heute etwas mehr in Anspruch genommen, als 
gedacht. Ich habe nicht mehr geschafft abzudaten, habe aber mit der 5.13 
getest, die ich schon dauf hatte.

Hat sich alles plausibel verhalten. Habe jeweils über das Webinterface 
"absolute watt in non-persitant" gesetzt:

gesetzt 10W, WR:13W, shelly:9W 
gesetzt 20W, WR:24W, shelly:19W
gesetzt 50W, WR:48W, shelly:43W
gesetzt 100W, WR:103-108W, shelly:98-103W
gesetzt 150W, WR:152-157W, shelly:152-157W  
gesetzt 200W, WR:201-206W, shelly:201W 
gesetzt 300W, WR:310W max, shelly:max 305W 
gesetzt relativ in procent persistent: 100% WR: max 561W, shelly: max 553W

Angehängt noch die Graphen aus fhem dazu. Für mich ist das ein sehr 
ordentliches Ergebnis :-)

Gruß

Carsten

PS: ich hatte mehrere Reboots den Tag über. Mit 5.1 lief es mehrere Tag 
durch...

PPS: ich habe leider keine serielle Console dran, da aus Empfangsgründen 
die DTU draussen am Gartenhaus hängt. Ich versuche spätestens am 
Wochende dafür eine Lösung zu finden (2. ESP mit seriell nach ssh o.ä.)

[Christian E. (christian_e775)]

Falls jemand die Daten direkt mit einem RaspberryPi auslesen und an den 
Volkszähler schicken will: https://github.com/stefan123t/ahoy/pull/3
Ggf. an einigen Stellen noch nicht schön aber funktioniert erstmal so.

[Sigi S. (sermon)]

number of supported inverters (set to 3 by default) defines.h

Ist in defines.h nicht zu finden.

Wo dann?

[Carsten (Gast)]

config.h, Zeile 46:

// number of configurable inverters
#define MAX_NUM_INVERTERS       3

[Sigi S. (sermon)]

Sigi S. schrieb:
> number of supported inverters (set to 3 by default) defines.h
>
> Ist in defines.h nicht zu finden.
>
> Wo dann?

JA, Danke!!!

[Marcel S. (Gast)]

Ich muss noch mal nachfragen, wie genau du es machst, weil es bei mir 
einfach nicht klappen will.
Ich nutze den mqtt Adapter (nicht den mqtt-Client, könnte das ein Fehler 
sein).
Ich habe mir analog zu dir diesen Datenpunkt manuell erstellt:
mqtt.0.Ahoy.devcontrol.0.11
Die Ordner habe ich als folder deklariert.
Gesendet habe ich dann die Werte als string und number, beides ohne 
Erfolg.
Wo kann ich ansetzen?

[Dirk S. (fusebit)]

Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin keine 
höhere Version zum laufen.

Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene 
Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von 
5.10 aus, auch mit komplett gelöschten ESP getestet.
Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich 
keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht 
übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe 
funktioniert es wieder.

[Sorbit (Gast)]

Dirk S. schrieb:
> Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin
> keine
> höhere Version zum laufen.
>
> Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene
> Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von
> 5.10 aus, auch mit komplett gelöschten ESP getestet.
> Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich
> keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht
> übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe
> funktioniert es wieder.

Ich kann bestätigen, das auch die aktuellen Versionen bei mir 
einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones…

[Ha F. (harry_f)]

Marcel S. schrieb:
> Ich muss noch mal nachfragen, wie genau du es machst, weil es bei
> mir
> einfach nicht klappen will.
> Ich nutze den mqtt Adapter (nicht den mqtt-Client, könnte das ein Fehler
> sein).
> Ich habe mir analog zu dir diesen Datenpunkt manuell erstellt:
> mqtt.0.Ahoy.devcontrol.0.11
> Die Ordner habe ich als folder deklariert.
> Gesendet habe ich dann die Werte als string und number, beides ohne
> Erfolg.
> Wo kann ich ansetzen?

Im Einsatz: 0.5.14
Iobroker mit MQTT-Adapter als Server, allerdings auf Port 1881, da noch 
ein Sonoff-Adapter läuft.

ich schreibe Werte nach (als String):
mqtt.0.inverter.devcontrol.0.11

inverter  ist das MQTT-Topic aus der Configseite

[Dirk S. (fusebit)]

Sorbit schrieb:
> Ich kann bestätigen, das auch die aktuellen Versionen bei mir
> einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones…

Moin,

hast Du die bin von GitHub genommen, oder selbst kompiliert?
Wie hast Du sie aufgespielt:
- direkt auf leeren ESP geflasht?
- OTA von vorheriger Version?
- neue Version über vorherige geflasht?

Irgendetwas mache ich wohl falsch, aber was kann es bloß sein?

[Sorbit (Gast)]

Dirk S. schrieb:
> Sorbit schrieb:
>> Ich kann bestätigen, das auch die aktuellen Versionen bei mir
>> einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones…
>
> Moin,
>
> hast Du die bin von GitHub genommen, oder selbst kompiliert?
Beides
> Wie hast Du sie aufgespielt:
> - direkt auf leeren ESP geflasht?
Ja
> - OTA von vorheriger Version?
Auch das
> - neue Version über vorherige geflasht?
Ja
>
> Irgendetwas mache ich wohl falsch, aber was kann es bloß sein?
Ja, offenbar bei der Anmeldung.
Funktioniert die Anmeldung am AP?
Welche IP trägst du im Browser ein?
Firewall ausschalten, Pop up Blocker ausschalten, verschiedene Browser 
nutzen, welche Infos siehst Du auf dem COMx Port ( Putty)?

[Claus T. (Gast)]

Dirk S. schrieb:
> Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin
> keine
> höhere Version zum laufen.
>
> Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene
> Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von
> 5.10 aus, auch mit komplett gelöschten ESP getestet.
> Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich
> keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht
> übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe
> funktioniert es wieder.

Bei mir ist es mit ahoy so ähnlich.
Hatte die 0.4.20 und dann bis Gesten die 0.4.22 ohne Probleme am laufen.
Ich habe jetzt die 0.5.14 mit VisualStudio/PlatformIO auf meinen 
ESP8266EX D1 Mini V3.0.0 (4MB Flash) ohne Fehlermeldung geschrieben. In 
den Einstellungen bei den 3 Invertern stehen überall die gleichen 
sinnlosen Einträge. Diese konnte ich ändern und speichern, aber nicht 
löschen (hab ja nur einen Inverter). Nachdem ich den Knopf Erase 
Settings (ohne WLAN) gedrückt hatte, waren die Felder leer, aber man 
konnte keine neuen Daten mehr abspeichern. Ein Factory Reset bringt auch 
keine Verbesserung.
Nachdem ich mit Arduino ein anderes Programm mit Erase all flash 
geschrieben hatte, konnte ich mit PlatformIO wieder die 0.5.14 drauf 
schreiben, wlan einstellen und den ersten Inverter mit meiner 
Seriennummer abspeichern, die beiden anderen Inverter sind dann noch mit 
sinnlosen Zeichen befüllt, aber die SW funktioniert ansonsten.
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?

[H. E. (h_e)]

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.

[Marcel S. (Gast)]

Ok, danke. Jetzt geht's.
Wie oft setzt du die Begrenzung? Bin dabei einen Grundlastspeicher für 
die Nacht zu bauen.hast du da schon Erfahrungen, alle wie viele Sekunden 
man das machen kann?

[Dirk S. (fusebit)]

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.

[Sigi S. (sermon)]

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).

[Dirk S. (fusebit)]

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.

[Sigi S. (sermon)]

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;-)

[Dirk S. (fusebit)]

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.

[Sigi S. (sermon)]

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.

[Ralf B. (ralf_b210)]

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)

[Andi (Gast)]

Hallo zusammen

Ich habe heute mein Wemos D1 mini mit dem ESP8266 und dem NRL24L01+ 
bekommen. Ich habe irgendwie den richtigen Link zur Firmeware oder dem 
Archiv für Platformio noch nicht gefunden.

Ich habe einen HM600 bei mir im Einsatz und möchte die Daten am Schluss 
im Iobroker MQTT haben.

Eine weitere Frage: gibt es irgendwo eine Schrittanleitung mit der auch 
ein nicht Softwarespezialist das ganze zum laufen kriegt?

Vielen dank für eure super Arbeit
Andi

[Sorbit (Gast)]

Andi schrieb:
> Hallo zusammen
>
> Ich habe heute mein Wemos D1 mini mit dem ESP8266 und dem NRL24L01+
> bekommen. Ich habe irgendwie den richtigen Link zur Firmeware oder dem
> Archiv für Platformio noch nicht gefunden.
>
> Ich habe einen HM600 bei mir im Einsatz und möchte die Daten am Schluss
> im Iobroker MQTT haben.
>
> Eine weitere Frage: gibt es irgendwo eine Schrittanleitung mit der auch
> ein nicht Softwarespezialist das ganze zum laufen kriegt?
>
> Vielen dank für eure super Arbeit
> Andi

Ja schau mal bei GitHub nach.
Vorlesen ist nicht

[Hfhausen (Gast)]

Einfach mal eine Seite zurück blättern und lesen. Irgendwo dazwischen 
gibt es die Hinweise.

[Andi (Gast)]

Ist auch nicht notwendig mit Vorlesen, soweit bin ich noch durch die 
Primarschule gekommen. Aber es gibt da diverse verschiedene Link und 
Projekte.

Als Laie hat ist es etwas sehr schwierig, die Entwickler Infos und die 
wichtigen Anwender Info zu auseinander zu halten.

Aber ich habe schon mal was gefunden, so kann ich das ganze mal 
anschliessen und schauen.

[oxylog (Gast)]

Hallo allerseits,
Ich habe mir eine neue Version meines PCB-Layouts erstellt und diese 
Platinen fertigen lassen.
Dieses Mal für den D1-Mini (ESP8266) als auch für den ESP32-NodeMCU (38 
Pin). Somit kann beides mit einer Platine genutzt werden (natürlich 
nicht gleichzeitig ;-))
Falls Bedarf besteht gebe ich von diesen gerne welche ab.
https://www.ebay-kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoy-dtu-esp8266-und-opendtu-projekt/2187289249-168-9361

[Sigi S. (sermon)]

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.

[Andi (Gast)]

So, nun läuft ein Teil.

Ich habe mich genau an dieses hier gehalten:
https://github.com/grindylow/ahoy/tree/main/tools/esp8266

MQTT Daten bekomme ich vom ESP aber keine Hoymiles Daten, oder anderst 
ausgedrückt, dass ganze komuniziert noch nicht mit dem Wechselrichter.

Auf der http-Seite steht: "...is not available and is not producing"

Wo kann ich schauen ob da wirklich nichts geht? Ja. ich habe meine DTUL 
vom USB getrennt und der Wemos D1 steht direkt unter dem Hoymiles sind 
ca. 3m Sicht.

[Andi (Gast)]

Es ist genial, jetzt läuft es richtig.
Weil der ESP im Monitor plötzlich die Meldung gezeigt hat: "RF-Modul 
nicht mehr erreichbar", habe ich alles auf einen anderen Wemos geflasht 
und das Modul umgesteckt.

Auf dem viel älteren identischen Wemos D1 mini läuft jetzt alles korrekt 
und meine Daten erscheinen auch im Iobroker via MQTT. Absolut geniale 
Entwicklung.

Ich möchte mich bei allen Beteiligten ganz herzlich für ihren 
Entwicklungsaufwand bedanken.

Machen wir uns so doch ein weiteres Stück unabhängiger von der globalen 
Überwachung, verhindern auch das irgendjemand noch auf die Idee kommt, 
für die Sonnenstrahlung noch Steuern zu erheben.

Gruss aus der Schweiz
Andi

[M. P. (matze7779)]

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?

[Gerri (Gast)]

M. P. schrieb:
> 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?

Hast du im ioBroker unter den Instanzeinstellungen: mqtt.1 im Reiter 
MQTT EINSTELLUNGEN alles richtig eingestellt?

[Thomas Korner (Gast)]

Das Problem, dass die Adresse (das ist schon die volle Seriennummer mit 
12 Stellen, oder?) und der Name nicht gespeichert wird, habe ich jetzt 
auch.

Ich habe auch ein paar Optionen ausprobiert, dass ich
#define MAX_NUM_INVERTERS       1
gesetzt habe, macht keinen Unterschied bei dem Problem

[Ralla66 (Gast)]

Zur Info
Test der 0.5.14, #42 mit ESP / HM600
nach Reboot Limit wird gesetzt,
Keine WR Daten wenn der Mqtt Broker nicht erreichbar ist.
ESP überlast durch Mqtt anfragen ?
Falsche Mqtt Broker IP, Absturz des ESP.

[Andi (Gast)]

Hallo M.P.

> 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?

Also ich habe da gar keine Datenpunkte angelegt, die hat mir der 
Iobroker direkt selber erstellt. Im Setup "AHOY-DTU" unter "MQTT" ein 
Topic eintragen, und wenn die Konfig richtig ist, sollte im Iob 
eigentlich alle Daten dort drin erscheinen (bei mir ist der Iob auch 
MQTT-Brocker).

Kleiner Typ, im MQTT-Ordner keine eigene Datenpunkte anlegen sondern im 
nur im "0_userdata". Bedingt dann ein Skript oder Allias das die Daten 
dann dorthin kopiert.

[Guido (Gast)]

Moin, sag mal hast Du noch 1 - 2 Platinen ESP-DTU ?

[Ralla66 (Gast)]

@ Andy
Leistungsbegrenzung senden ist gemeint

[Claus T. (Gast)]

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.
Nachdem ich die Version 0.5.14 bei mir nicht so fehlerfrei installieren 
konnte, habe ich heute auf die neue ahoy-DTU ESP8266 Version 0.5.15 mit 
PlatformIO aktualisiert, WiFi eingegeben, in den Settings "Erase 
Settings" gedrückt, die Inverter Adresse und MQTT eingegeben.
Jetzt läufts wieder, super Arbeit an die Entwickler.
Ich halte für mich fest, auch wenn es Sigi S. anders sah,
:-)
Es kann doch am Code liegen,
:-)
hier die Info dazu
https://github.com/grindylow/ahoy/issues/162
Denn bei einer laufenden Entwicklung gibt es meistens Fortschritte, aber 
auch manchmal Rückschritte (neue Fehler).
Weiter so.

[tastendruecker (Gast)]

Ralla66 schrieb:
> Keine WR Daten wenn der Mqtt Broker nicht erreichbar ist.
> ESP überlast durch Mqtt anfragen ?
> Falsche Mqtt Broker IP, Absturz des ESP.

Ja, richtige Vermutung. Wenn der MQTT Broker nicht erreichbar ist 
versucht der ESP extrem oft, sich neu zu verbinden. Bei DNS Fehlern so 
um die 1000 Mal pro Sekunde. Ich habe dazu bereits eine issue auf github 
angelegt. Ich denke dass ich morgen Zeit haben werde, den Code zu 
überarbeiten.

[Jerry (Gast)]

Hi und Sorry Leute. Die Kommentare sind ao lang. Kann bitte einer 
zusammenfassen was nötig ist (Hardware und Software um die DTU zu bauen?
LG
Jerry

[tastendruecker (Gast)]

Jerry schrieb:
> Hi und Sorry Leute. Die Kommentare sind ao lang. Kann bitte einer
> zusammenfassen was nötig ist (Hardware und Software um die DTU zu bauen?

Hardware:
-ein ESP8266 Board wie z.b. Wemos D1 Mini oder NodeMCU
-ein NRF24L01+ Modul
-eine Möglichkeit beide zu verbinden (weiblich-weiblich "DuPont" Kabel, 
Breadboard oder eine entsprechende Platine).
-eventuell einen 0.1µF Kondesator oder sogar einen 3.3V Spannungsregler 
um die Spannungsversorgung des NRF Moduls zu verbessern, sollte das 
nötig sein (in den meisten Fällen ist es das nicht)

Software:
-die .bin Datei mit der aktuellen ahoy Software aus dem grindylow/ahoy 
repo bei github (links unter releases)
-ein Tool um Dateien auf den ESP zu flashen. Das geht mit NodeMCU 
Flasher, ESPTool, mit PlatformIO und vermutlich auch mit der Arduino 
IDE. Wobei die erste Option für die meisten wahrscheinlich die 
einfachste ist. Dieses Tool ist nur zur Erstinstallation nötig. Weitere 
Updates können per Web Interface installiert werden.
-Treiber für den USB-to-Serial Chip auf dem ESP8266 Board (CH340 o.ä.)

[Claus T. (Gast)]

Jerry schrieb:
> Hi und Sorry Leute. Die Kommentare sind ao lang. Kann bitte einer
> zusammenfassen was nötig ist (Hardware und Software um die DTU zu bauen?
> LG
> Jerry

Ist es in diesem Forum möglich, den allerersten Beitrag (auf Seite 1) 
jetzt noch zu Ändern, bzw. zu ergänzen?
Falls ja, wäre dort ein Hinweis auf das ahoy-git mit einer kurzen 
Beschreibung zu SW und HW nicht schlecht.

[Andi K. (fujin)]

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

[Daniel (Gast)]

Claus T. schrieb:
> Ist es in diesem Forum möglich, den allerersten Beitrag (auf Seite 1)
> jetzt noch zu Ändern, bzw. zu ergänzen?
> Falls ja, wäre dort ein Hinweis auf das ahoy-git mit einer kurzen
> Beschreibung zu SW und HW nicht schlecht.

Nein ist es nicht möglich. Beiträge können erstens nur vom verfasser 
geändert werden und zweitens ist es auch nur dann möglich, wenn nach dem 
Verfasser kein neuer Beitrag geschrieben wurde.

Wenn du Hilfe brauchst, schau doch einfach auf der Github Seite oder im 
Discord nach. :)

[Sigi S. (sermon)]

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?!

[Sigi S. (sermon)]

Entwarnung, gefunden!

[Andi (Gast)]

Bitte um Entschuldigung, irgendwann habe ich es nachträglich auch 
kapiert, dass es ums senden geht. Ist bei meinem HM600  auch gar nicht 
notwendig, weil er nicht mehr kann.

Das Problem mit dem "Download" vom git hatte ich gestern auch, bis ich 
begriffen habe, dass da im "clone" alle Varianten drin sind. Ich habe 
dann im Ordner Tool die Wemos Variante gefunden und daraus im Platformio 
ein eigenes Projekt erzeugt. Jetzt geht es wunderbar. Auch das eintragen 
der Wlan und Mqtt Daten ging im File viel besser als über die Webseite 
vom ESP. Denn dort speicherte er bei mir zwar irgendwelche Einträge, 
aber die waren kryptisch und kaum richtig. Was bei mir aber dann ging: 
Ein Eintrag machen und speichern mit reboot, danach nächste Zeile usw. 
Ich denke, dass ist ein html Problem beim Daten übernehmen in die 
verschiedenen Variablen.

Etwas was noch ganz schön wäre (oder ich habe es übersehen), wäre ein 
Datenpunkt der mir direkt angibt "HMxxx true/false".
Das hat bei mir folgenden Grund: Ich habe einen Shelly PM (mit 2poligem 
Relais) in der Netzleitung und würde gerne den Hoymiles in der Nacht 
komplett abtrennen. Da würde ein solcher Datenpunkt eben etliches an 
Programierung ersparen im Iobroker.

Gruss Andi

[Hubert (Gast)]

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?

[Herbert S. (herbert_s445)]

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

[Dirk S. (fusebit)]

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"

[Friedrich (Gast)]

Eine tolle Arbeit der Entwickler. Hut ab und besten Dank dafür!
Eine tolle Sache, wenn man die PV-Anlage damit detailliert im Blick hat.

Gestern hat es mir die Füße weggezogen. Ich hatte die Version 0.4.xx 
noch drauf. Gestern habe ich dann die Version 0.5.14 geflasht. Und 
nichts ging. Fehler wie oben beschrieben. Den Fehler habe ich einen 
halben Tag bei mir gesucht. Bis ich gesehen habe, dass es am Nachmittag 
die neue Version 0.5.15 gab. Das hat auf Anhieb wieder funktioniert. Ich 
war verblüfft, wie schnell die Entwickelter reagiert haben. Sie sind 
wirklich sehr arrangiert.

Vielen Dank!

[Hubert (Gast)]

Danke!

[Claus T. (Gast)]

Daniel schrieb:
> Nein ist es nicht möglich. Beiträge können erstens nur vom verfasser
> geändert werden und zweitens ist es auch nur dann möglich, wenn nach dem
> Verfasser kein neuer Beitrag geschrieben wurde.
>
> Wenn du Hilfe brauchst, schau doch einfach auf der Github Seite oder im
> Discord nach. :)

Hallo Daniel,
ich hatte die Hoffnung dass evtl. ein registrierter User seine Einträge 
noch ändern kann. Als Gast sollte das natürlich nicht gehen und fremde 
Einträge ändern natürlich erst recht nicht.
War als Einstiegshilfe für die neuen Anwender gedacht,
:-) ich bin schon länger dabei und hab inzwischen alle Beiträge gelesen 
:-) ,
um die vielen sich wiederholenden Frage nach wo, wie, was,… zu 
minimieren.
Grüße Claus T.

[tastendruecker (Gast)]

Herbert S. schrieb:
> was bedeuten die neuen Felder P_ACr  und die Einheit VAr bzw.
> ALARM_MES_IS ?

P_ACr, ist AC reactive power, also Scheinleistung. Wird für die meisten 
eher nebensächlich sein, aber der WR gibt es halt mit aus.

Alarm_MES_ID gibt an, wieviele Warnungen/Alarme der WR geschickt hat. 
Aber das ist in der Regel sowas wie 'PV Spannung zu niedrig' abends.

[isnoahoy (Gast)]

Hallo Andi K.

> 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 habe noch keines in der freien Wildbahn hier in DE gesehen.
Schön ist dass es ein Abschirmblech hat!
Wenn Du welche bestellen solltest hätte ich auch Interesse an einem / 
zwei Modulen.

Grüsse Stefan T

[Günter H. (gnter_h534)]

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".

[Andreas (dicc)]

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

[Reinhard (sym)]

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?

[Andreas (dicc)]

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

[Günter H. (gnter_h534)]

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.

[Boris J. (sivar2311)]

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)

[Andreas S. (drschiffler)]

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

[wr (Gast)]

@Reinhard (sym)
Ist der WR ein MI-1500 oder HM-1500? Was steht drauf?
Für MI-1500 gibt es bisher diesen git Repo:
https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles

[Reinhard (sym)]

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?

[Ralla66 (Gast)]

Boris J
suche den Algo halt, WR ID verkaspert mit DTU ID ergibt CH,
oder wird mitgesendet, dann welches cmd welche Umrechnung oder ...
doch zufällig ?

[Günter H. (gnter_h534)]

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.

[Reinhard (sym)]

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.

[tastendruecker (Gast)]

Andreas schrieb:
> Beim compilieren können 2 Datein nicht erstellt werden aber die brauche
> ich wohl nicht!
>
> AD

Ab der 5.15 gibt es auch eine Version für den ESP32, aber der ESP32 
Build scheint bei dir nicht geklappt zu haben. Wenn du allerdings einen 
ESP8266 verwendest, spielt das keine Rolle.

[Sermon (Gast)]

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

[Sermon (Gast)]

FW ist 5.15

[Andreas (dicc)]

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

[Sermon (Gast)]

Die Seriennummer ist korrekt und die Visualisierung zeigt auch 
„Produktion“, trotzdem die Fehlermeldung

[Ha F. (harry_f)]

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 (Gast)]

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.

[Andreas (dicc)]

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

[Herbert S. (herbert_s445)]

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

[Andi K. (fujin)]

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.

[Andreas S. (drschiffler)]

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

[Sorbit (Gast)]

„Danach die aktuellste *.bin - Datei flashen.„

Könnte einer der Entwickler uns erhellen?

Irgendwas stimmt nicht, aber was?

[tastendruecker (Gast)]

Sorbit schrieb:
> „Danach die aktuellste *.bin - Datei flashen.„
>
> Könnte einer der Entwickler uns erhellen?
>
> Irgendwas stimmt nicht, aber was?

Worüber denn?

[Sorbit (Gast)]

Worüber denn?


Worüber wohl, nicht im Thema?!

[tastendruecker (Gast)]

Ich verstehe nach wie vor nicht, über was du erhellt werden möchtest. 
Und der Ton ist ebenfalls befremdlich.

[Johannes (derfrickler)]

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

[Highlander (Gast)]

tastendruecker schrieb:
> Ich verstehe nach wie vor nicht, über was du erhellt werden möchtest.
> Und der Ton ist ebenfalls befremdlich.


Das steht 2 Posts früher, einen "TON" vernehme ich hier nicht.
Aber die Nachricht entsteht ja eh beim Empfänger, so Watzlawick.
Hier sind viele nicht gewillt, oder in der Lage, etwas Mühe und Zeit in 
den Verlauf zu investieren um selbst längst gegebene Antworten zu 
finden.
Ist allgemein so, work life balance steht im Vordergrund, CORONA und 
Homeoffice forcieren die Häwelmänner.
Also mal bitte nicht so schenll die (shiftlosen) Tasten drücken, Herr 
tastendrücker.

Darum verstehe ich, das keiner der Entwickler mehr direkt in diese Chaos 
hinein antwortet.
Dafür gibt es nun Github Issues.

Alles gut, bleibt freundlich.

[Normen (burn)]

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?"

[Johannes (derfrickler)]

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

[Sören S. (sren_s)]

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?

[Hans W. (hans_w801)]

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.

 
  - platform: mqtt
    state_topic: "solar/11617xxxxx/0/yieldtotal"
    name: "Gesamtproduktion HM-1500"
    device_class: energy
    unit_of_measurement: "KW/H"
    value_template: >
        {{value|round(2)}}
    state_class: total_increasing
    unique_id: "total_hm1500"
    last_reset_topic: "solar/11617xxxxx/0/yieldtotal"
    last_reset_value_template: "1970-01-01T00:00:00+00:00"

[OlaLu (Gast)]

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

Ich glaube, ich musste HA dann noch einmal neu starten, danach 
funktionierte das Autodiscovery wie gewünscht.

[Basti (Gast)]

Hallo,


vielen Dank für eure cool Arbeit... Es funktioniert nun ganz 
ausgezeichnet.

Ich habe mir ein RF-Nano bestellt und musste feststellen, dass gar kein 
echter ATMega verbaut ist, sondern ein chinesischer Clone (nulllab). Das 
hatte mich etwas zurückgeworfen. Außerdem baut man das RF-Nano ohne den 
ISR Pin rauszuführen... also nicht mal ein Testpunkt oder so... Absolut 
eintäuschend... Also den Patch noch herstellen und die Idee, des 
0-Lötaufwandes war obsolete. Aber es sieht trotzdem noch ganz okay und 
ungebastelt aus.

Fürs Protokoll: ich habe ein TSUN TSOL-M800(DE) also auf 600 VA 
begrenzt.

Seriennummer: 1141820XXXXX -> der Anfang mit 82 ist noch nicht in der 
Excelliste.

Kann ich sonst noch was tun?

Viele Grüße

Basti

[Dirk Z. (dirk007)]

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 ;-) ?

[Frank R. (Gast)]

Ihr habt super Arbeit geleistet!
Habe meine beiden HM-300 sehr schnell ans Netz bekommen.

Zur Info: Für mein NRF24+ Modul
https://www.amazon.de/NRF24L01-Wireless-Transceiver-Antenne-kompatibel/dp/B07Y4ZLPTJ
musste ich den öffter erwähnten Kondensator für die 3,3V installieren.

[Thomas B. (tbnobody)]

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.

[Andreas (andic)]

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

[Jörg R. (Gast)]

Hallo Reinhard und Johannes,

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.

[OlaLu (Gast)]

Thomas B. schrieb:
> 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.

Nun, das hatte ich zuerst auch so versucht, allerdings als Topic immer 
"solar/" eingetragen - und es funktionierte erst mit den o.g. Änderungen 
in der configuration.yaml.
Vielen Dank Thomas für die Fehlerbehebung und auch mal einen ganz dicken 
Dank an alle Entwickler für eure tolle Arbeit hier im Forum!

[Andreas (dicc)]

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

[Lukas P. (lumapu)]

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.

[Andreas (dicc)]

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!

[Günter H. (gnter_h534)]

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.

[Lukas P. (lumapu)]

> 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.

[Andreas (dicc)]

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!?

[Reinhard (sym)]

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!

[Basti (Gast)]

Hallo,

ich nochmal: 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

ich verwende den Arduino Nano Code (nicht Plattform.io) und habe noch 
unterschiedliche Aussagen bei den zwei Parametern:

E-Woche:28832.00
E-Total:26394.00

Ist da was bekannt? Ich nehme an, es ist vertauscht und die 
Wochenfunktion ist nicht wirklich korrekt. Also 28 kWh total klingt 
durchaus realistisch.

Ist für mich jetzt nicht wirklich relevant, ich lese es jetzt einfach 
bei E-Woche ab und gut ist.

Viele Grüße

Basti

[Matthias (Gast)]

Hallo coole sache die ihr geschaffen habt. Habe eine frage die ich beim 
Durchlesen so nicht gefunden habe.
Kann man über OpenDTU oder ahoy TOR Einstellungen ändern wie es über die 
DTu von hoymiles möglich wäre? Oder ist es rein zum Auslesen der Daten?
In Österreich wäre folgende Einstellungen nötig:
"Der Betrieb ist nur dann erlaubt, wenn die geltenden Richtlinien 
TOR-Erzeuger am Wechselrichter aktiviert wurden 
(AT_TOR_Erzeuger_default)."

[jnz (Gast)]

Johannes schrieb:
> Ja, seiner hat auch ne 114173307xxx Seriennummer, meiner eine mit
> 1041 startende...

Hier ebenso, TSUN M800 mit 1041 kommuniziert leider nicht (0.5.15)

[D. J. (basteldag)]

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.

[Sören S. (sren_s)]

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

[DaAlchemist (Gast)]

@ D.J, ja richtig im 2. Bild die Daten von deinem Heimnetz eingeben. Was 
dann noch fehlt ist die SN vom Inverter unter Inverter Settings.
Sollte keine Verbindung zustande kommen, die Sendeleleistung erhöhen 
und/oder näher an den WR ran.

[Steffen D. (steffen_d)]

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.

[Günther T. (brachykykloma)]

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

[Johannes (derfrickler)]

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.

[Jörg R. (Gast)]

Johannes schrieb:
> 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.
Bei den Beiträgen von Ziyat T. und mir geht es um die 2nd 
Generation-Geräte (SN 10xx), da sind auch zip-Dateien bzw. repo-Links 
dabei). Bis das in ahoy oä. drin ist, wird es etwas dauern, und man muss 
in etwa eine Vorstellung haben, was da wie anzupassen ist...

Hoffe, in ein paar Tagen was vereinfachtes zum testen anbieten zu 
können.

Mit jnz gibt es ja vermutlich noch einen user, den das betrifft...

[Johannes (derfrickler)]

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

[jnz (Gast)]

Jörg R. schrieb:
> Hoffe, in ein paar Tagen was vereinfachtes zum testen anbieten zu
> können.
> Mit jnz gibt es ja vermutlich noch einen user, den das betrifft...

Danke Jörg, das klingt vielversprechend. Teste dann gern und werde 
rückmelden.
Danke Johannes für den eindeutigen Beweis, das die 1041TSUN prinzipiell 
zur Kommunikation zu bewegen sind.
Viele Grüße

[Klaus (Gast)]

Hat eigentlich jemand mal sowas wie die oberste 
Spannungsgrenzabschaltung bei 60V gesehen? Bei mir steigt die Spannung 
morgens manchmal zu heftig an und ich steht kurz auf 65V was zu einem 
Totalausfall für betreffenden Tag führt. Ich hätte Interesse diesen Wert 
auf 70V zu kriegen. Aushalten tun es die Geräte, bloß wollen tun sies 
nicht.

[Sören S. (sren_s)]

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.

[Johannes (derfrickler)]

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

[Jörg R. (rejoe2)]

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ä.).

[jnz (Gast)]

Jörg R. schrieb:
> 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?).

Korrekt, habe 1041635xxxxx mit 2 Eingängen, TSOL M800, DE auf 600 W 
gedrosselt.

[Johannes (derfrickler)]

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

[Ziyat T. (toe_c)]

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.

[Jörg R. (rejoe2)]

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.

[Johannes (derfrickler)]

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.

[Jörg R. (rejoe2)]

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...

[Ziyat T. (toe_c)]

@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

[Jörg R. (rejoe2)]

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!

[Andreas B. (Gast)]

Hallo Sören,

ich bin recht im Thema Home Assistant und kann ggf. helfen.

Was genau fehlt dir?

P.S. Danke für dieses super Projekt und all eure Mühen!!

Mein NodeMCU mit Empfänger ist seit gestern Abend verlötet und in einem 
Case, leider werden meine Panels erst im Oktober geliefert... :( ;)

[peter (Gast)]

Klaus schrieb:
> Hat eigentlich jemand mal sowas wie die oberste
> Spannungsgrenzabschaltung bei 60V gesehen? Bei mir steigt die Spannung
> morgens manchmal zu heftig an und ich steht kurz auf 65V was zu einem
> Totalausfall für betreffenden Tag führt. Ich hätte Interesse diesen Wert
> auf 70V zu kriegen. Aushalten tun es die Geräte, bloß wollen tun sies
> nicht.

Also hier an meinem Labor Netzteil geht er bei ca 59V an wenn ich von 
60V+ komme. Mich würde der betrieb bei 61V interessieren (18S lifepo4), 
aber glaube das wird eher nichts.

[Ziyat T. (toe_c)]

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

[Jörg R. (rejoe2)]

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.

[Johannes (derfrickler)]

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

[Andi (chello)]

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:

[Ziyat T. (toe_c)]

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

[Jörg R. (rejoe2)]

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...

[Günter H. (gnter_h534)]

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".

[Ziyat T. (toe_c)]

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?

[Jörg R. (rejoe2)]

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:

#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

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.

[Jörg R. (rejoe2)]

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.

[J. S. (jojos)]

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.

[Ziyat T. (toe_c)]

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

[Andi (chello)]

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 ?

[Jörg R. (rejoe2)]

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.

[J. S. (jojos)]

Erase Settings und dann nochmal neu eintragen.

[Andi (chello)]

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 ?

[J. S. (jojos)]

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.

[Normen (burn)]

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!

[solaris (Gast)]

Hallo und schönen Sonntag.
Habe mich bis hier durchgeschlagen, Mein BKW mit 2x350W + HM800 und 
Ahoy-DTU läuft. Aber was ich nicht kapiere ist die Geschichte mit den 
Daten, die se Darstellung was der WR den Tag über so treibt. Diese 
MQTT-Sache, wer oder wo find ich mal ne Erklärung oder Beschreibung , 
die auch verständlich ist.
Jeder scheint irgend ein anderen Broker zu verwenden. Was brauch ich um 
z.B. die Daten auf meinem Handy(Android) zu sehen ? Danke schon mal.

[J. S. (jojos)]

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).

[DaAlchemist (Gast)]

Unfassbar:
https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-hardware-fuer-ahoy-projekt-hm300-hm400-hm600-hm1500/2201223140-168-5178

Da hat doch schon mal jemand eine FAQ begonnen, wäre es nicht sinnig,um 
so etwas zu vermeiden, diese in jedem Github repo zu verlinken?

Gruß

[Jens (Gast)]

Hallo alle miteinander,

Ich bin jetzt auch seit knapp einer Woche Besitzer eines BKW mit einem 
HM1500. War natürlich zu geizig mir eine DTU zu kaufen und bin nach 
etwas Suchen hier auf das Projekt gestoßen.

Habe mit auch die ca. 80 ersten Posts durchgelesen, aber irgendwann 
wurde es recht anstrengend dem ganzen zu folgen.
Gibt es den eine Gesamtanleitung zum Projekt ( ja, könnte es auf Ebay 
Kleinanzeigen kaufen, weiß nur nicht ob das sinnig ist und gewollt).

Oder kann mir jemand die Stelle/Stellen im Postverlauf nennen, die 
wichtig sind.

Habe von programmieren selbst keine Ahnung, der Elektronikpart usw. ist 
kein Problem, nur bei Codezeilen und ähnlichem bin ich raus.

Wäre super, wenn mir da jemand helfen könnte, damit ich weiß was meine 
Ablage überhaupt bringt und ich das ganze per MQTT in HomeAssistant 
einbinden kann.

Gruß Jens

[Andreas S. (drschiffler)]

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

[Ralla66 (Gast)]

Hi, teste gerade die 0.5.16
Wurde das automatische erstellen von Datenpunkten im Mqtt Broker hier 
devcontrol schon eingepflegt ?

[Jens (Gast)]

Wow, dass ging flott.

Vielen lieben Dank.

Dann wurschtel ich mich da mal durch.

[Dirk Z. (dirk007)]

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 ?

[Ralla66 (Gast)]

Devcontrol Datenpunkte wurden bei mir nicht angelegt.
Habe mit einem Mqtt Explorer die Datenpunkt per Hand angelegt und 
Powerlimit vorgegeben, lief.

[J. S. (jojos)]

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.

[Rene M. (Firma: Bitte wählen) (renmo)]

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.

[Oswald S. (obmaroszi)]

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

[Rene M. (Firma: Bitte wählen) (renmo)]

Danke dir.
Die Leistungslimitierung wird nicht mehr richtig angezeigt.

[Oswald S. (obmaroszi)]

tatsächlich
betreibe ihn ohne Leistungslimitierung  deshalb nicht afgefallen

[Andreas S. (drschiffler)]

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

[Rene M. (Firma: Bitte wählen) (renmo)]

@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?

[Christian O. (ottelo)]

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?

[Hans W. (hans_w801)]

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.

[M. P. (matze7779)]

Hallo,

was bedeuten eigentlich die Werte:
Pct
P_ACr

[Thomas B. (Gast)]

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

Ich würde vermuten, dass sich das beißt: 
https://github.com/tbnobody/OpenDTU/issues/26

[Rene M. (Firma: Bitte wählen) (renmo)]

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.

[Grisu (krisu)]

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!

[Gutmensch (Gast)]

M. P. schrieb im Beitrag #7183365:
> Sorbit schrieb:
>> Vorher mal selbst nachdenken, oder hier nach bereits gegebenen Antworten
>> suchen?
>
> Na das sagt der Richtige.
> Was muss eigentlich im Leben passieren um so ein Arschloch zu werden?

[M. P. (matze7779)]

Danke @ Grisu

[Normen (burn)]

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

[Grisu (krisu)]

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.

[misch (Gast)]

Hallo,
bin am verzweifeln da mein HM 1500 kein Strom mehr produziert
Hatte mit der Version 04.22 funktioniert :
wollte die Version 05.15 flashen, ist mir aber nicht gelungen
kann es sein das bei zugriff auf den HM1500 irgend was passiert ist und 
dieser kein Strom mehr produziert ?
Im Moment habe ich die Version 0.5.3 geflasht
Kann mir vieleicht jemand Helfen ? und mir sagen wie ich das hinbekomme 
das der Wechselrichtet wieder Strom produzirt
Vielen Dank !! Michael

[Günter H. (gnter_h534)]

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.

[Thorsten (koerly)]

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 (Gast)]

In der Tat das war der Fehler !!
Habe das Limit nun auf den richtigen Wert gesetzt und nach mehreren 
Minuten war die Einspeisung wider da !!
Vielen DANK !!!

[Grisu (krisu)]

misch schrieb:

> wollte die Version 05.15 flashen

Solltest vielleicht gleich die aktuelle 5.16 nehmen.

[Eike (eike_l)]

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?

[Grisu (krisu)]

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.

[isnoAhoy (Gast)]

@Jörg R., Ziyat T., Johannes und JNZ,
freue mich dass es nun auch für die "alte" 10er Serie der Hoymiles 
MI-Wechselrichter und TSUN geht.

In der RF Communication protocol v6.5.xls steht folgendes zu den 0x08 
und 0x11 Kommandos:

 08   Collect the status and data of channel A of the terminal device 
(upload in two packages)   88 (status), 89 (data)
 09   A-side data   89

 11   Collect the status and data of channel B of the terminal device 
(upload in two packages)   92 (status), 91 (data)
 12   B-side event

Die Antwort erscheint dann wie gehabt mit 0x80|REQ_CMD

Danke auch nochmal für die Erinnerung:

In 
https://www.mikrocontroller.net/attachment/559626/Micro-inverse_system_related_product_ID_coding_rules-A3-20190712.docx
steht ziemlich am Anfang was sehr Interessantes:
**2. ID coding rules**
**1. The first four rules**
The 1st to 4th digits are the model code, among which, the "1" digit is 
the **product category**, and "1" represents the related products of the 
**micro-inverse system**.
The "2~3" digit is the **product category**. At present, the related 
products of the micro-inversion system are:
| 2-3 digit value | Product Category | Involved product model |
| --- | --- | --- |
| 01 | One drag series (four-core bus version) | MI-250T1, MI-300T1, MI-350T1 |
| 02 | one drag series | MI-250, MI-300, MI-350, MI-250T, MI-300T, MI-350T |
| 03 | One for two series (four-core bus version) | MI-500T1, MI-600T1 |
| 04 | One for two HM, MI series | MI-500,MI-600, MI-700, MI-500T,MI-600T, 
MI-700T, HM-500,HM-600, HM-700, HM-500T,HM-600T, HM-700T |
| 06 | One for four HM, MI series | MI-1000,MI-1200, MI-1500, MI-1000T,MI-1200T, 
MI-1500T, HM-1000,HM-1200, HM-1500, HM-1000T,HM-1200T, HM-1500T |
| 16 | HM Pro one drag four series | HM-1200 Pro, HM-1500 Pro, HM-1200T Pro, 
HM-1500T Pro |
| 0C | smart meter | Chint DDSU666, DTSU666, etc. |
| 0D | Minimalist DTU | DTU-G100, DTU-W100, DTU-Lite-GPRS, DTU-Lite-WIFI |
| 0E | repeater | RP-433-ICR |
| 0F | DTU | DTU-MI, DTU-433, DTU-MI-GPRS, DTU-433-GPRS, DTU-MI-AR, DTU-MI-ARW, 
DTU-MI-GPRS-ARW, DTU-Pro-GPRS, DTU-Pro-WIFI |
| 9X | Production test fixture |  |
...
2. Last eight coding rules
For products such as micro-inverters, DTUs, repeaters, etc., the rules 
are as follows:
The 5th to 12th digits are the production serial number and are used as 
the RF communication address of the micro-inverter/DTU/repeater, among 
which:
The "5" digit is the **year of production** (time provided by the 
welder), the "1" is for **2015**, and so on
The "6~7" bits are the **production week** (the time provided by the 
welding factory), and the range is "1~52".
The "8~12" bits are the pipeline coding (currently in decimal), the 
micro-inverter, repeater, and DTU share the same pipeline sequence, 
which is coded in sequence and must not be repeated, a total of 99999 
bits.

Ich würde Euch gerne einladen, kommt doch mal in den Discord Chat, wir 
haben extra einen Kanal #mi-serie eingerichtet in dem wir gerne die 
Integration von Eurem Code in die AhoyDTU / Bibliothek diskutieren 
können.

Der Link dazu https://discord.gg/WzhxEY62mB ist in der Zwischenzeit auch 
auf https://github.com/grindylow/ahoy

Für die HMS / HMT interessierten gibt es auch einen #hms-serie Kanal und 
ein github Issue https://github.com/grindylow/ahoy/issues/233 Sub1G 
Unterstützung für 3phasige HMT-1800-6T, HMT-2250-6T und HMS #233
Dieses versucht die notwendige Hardware (NRF905 ?) und den Partner 
Thread hier im Forum zusammen zu fügen.

Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless
Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"

Wenn wir die Fragen nach einzelnen Software-Versionen hier etwas 
reduzieren und (wie ihr) stärker am Protokoll arbeiten, kehrt vielleicht 
auch beim einen oder anderen Thread Teilnehmer wieder etwas mehr 
Gelassenheit ein.

[Jörg R. (rejoe2)]

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.

[David B. (mystisch)]

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

[Jörg R. (rejoe2)]

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)

[David B. (mystisch)]

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

[Grisu (krisu)]

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.

[Jörg R. (rejoe2)]

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.

[Carsten B. (carstenb)]

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 (Gast)]

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

War das die Standardbelegung?

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...

[Carsten B. (carstenb)]

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...

[David B. (mystisch)]

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.

[Jörg R. (rejoe2)]

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.

[tiny (Gast)]

Hallo Zusammen,

danke für die Mühen.
Ich habe heute den ESP32 in Betrieb genommen mit openDTU.
Wird es hier noch ein Update geben um das Limit per mqtt einzustellen?

Die Werte sind auf Anhieb raus gefallen und das Auto discover im Home 
Assistant war sofort da. Einfach Top.

Alternativ wie bekomme ich denn Ahoy auf dem ESP32 zum laufen?

Einfach die Pins im source anpassen?

Grüße Tiny

[Rene M. (Firma: Bitte wählen) (renmo)]

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.

[David B. (mystisch)]

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

[Jörg R. (rejoe2)]

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.

[David B. (mystisch)]

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

[Ziyat T. (toe_c)]

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

[Ziyat T. (toe_c)]

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

das ist sehr aufmwerksam! super!

[co3 (Gast)]

Moin,

vielen Dank für dieses genieale Tool, habe es heute auf einem ESP32 
installiert und funktioniert sehr gut.

Eine Frage hätte ich, welches in den die Varinaten auf die mann 
zukünftig setzten sollte?
Ahoy oder OpenDTU?

habe heute OpenDTU genommen.

danke
vg

[Drazen K. (rewop)]

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

[Jörg R. (rejoe2)]

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"?

[Ziyat T. (toe_c)]

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)

[Ziyat T. (toe_c)]

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)

[Ziyat T. (toe_c)]

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

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> kann nicht bestaetigen, hier auf ubuntu22.04/minicom

Keine Ahnung, wo das herkommt, zu sehen ist es auch nur bei den 
erweiterten  RX/TX-Ausgaben:
Hier, was bei mir kommt, hoffe, die Forensoftware zerhaut es nicht:

CH 61 �0 12345678�1 �0c6 18 3 89 6010�013 6010�013 �14c�034�94e138a�5ff�35c�11f95dac7 1
2022-9-9  18:8:51  it's daytime!, SunDown at 19.48
CH 61 �0 12345678�1 �082 10 1 88 6010�013 6010�013 �0�3�0�0�0�08bf5c9 1

(tut sie doch; sind wenige verschiedene Unicode-Zeichen; hier auch ein 
recht aktuelles Kubuntu, Ausgabe mit minicom).
Hab's vorher sicherheitshalber nochmal durch den Compiler gelassen, und 
auch die aktualisierte Webserver-Datei eingebaut.

NTP habe ich jetzt auf die Fritte gesetzt, habe den Eindruck, dass hier 
in letzter Zeit das INet häufig mal wackelt...

[Thomas (Gast)]

Thorsten schrieb:
> So kann es aussehen, wenn man es per mqtt in den Home Assistant
> importiert hat.

Hallo,
genau danach hatte ich gesucht, bin totaler Anfänger mit mqtt in Home 
Assistant, habe Home Assistant auf einem Raspberry laufen, hast du eine 
Anleitung für mich am besten mit Screenshot
danke, Thomas

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> kann nicht bestaetigen, hier auf ubuntu22.04/minicom
>
> Keine Ahnung, wo das herkommt, zu sehen ist es auch nur bei den
> erweiterten  RX/TX-Ausgaben:
> Hier, was bei mir kommt, hoffe, die Forensoftware zerhaut es nicht:
>

CH 61 �0 12345678�1 �0c6 18 3 89 6010�013 6010�013 
> �14c�034�94e138a�5ff�35c�11f95dac7 1
> 2022-9-9  18:8:51  it's daytime!, SunDown at 19.48
> CH 61 �0 12345678�1 �082 10 1 88 6010�013 6010�013 �0�3�0�0�0�08bf5c9 1
>

das ist bei mir nicht der fall. was ich oben sehe, das ist nur bei den 
datadump's, ich schaue mal nach.
edit:
ich habe bei der debug ausgabe DEBUG_OUT alle print/println's auf printf 
umgestellt. der grund, ich möchte spaeter das DEBUG_OUT.printf auf 
webserial umbiegen, damit die hoylmoly-dtu ohne angeschl.compi gesteuert 
werden kann.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> kann nicht bestaetigen, hier auf ubuntu22.04/minicom
>
> Hier, was bei mir kommt, hoffe, die Forensoftware zerhaut es nicht:
>

CH 61 �0 12345678�1 �0c6 18 3 89 6010�013 6010�013 
> �14c�034�94e138a�5ff�35c�11f95dac7 1
> 2022-9-9  18:8:51  it's daytime!, SunDown at 19.48
> CH 61 �0 12345678�1 �082 10 1 88 6010�013 6010�013 �0�3�0�0�0�08bf5c9 1
>

hier: bitte aendern
    if (*p < 16)
      DEBUG_OUT.printf("%c",'0');

[Prettypat (Gast)]

Funktioniert es eigentlich auch mit den aktuelleren HMS Modellen?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> hier: bitte aendern
done.

Die firmware meinte nur, jetzt sei schon Nacht, obwohl noch 70W kamen 
(die Zeit für den Start morgen früh ist aber mAn. ok, der offset sollte 
also eigentlich nicht das Problem sein).

(Sind aber alles Kleinigkeiten!)

[FAQ (Gast)]

Prettypat schrieb:
> Funktioniert es eigentlich auch mit den aktuelleren HMS Modellen?

Nein. Siehe https://github.com/grindylow/ahoy/tree/main/tools/esp8266

[Jürgen E. (joe73)]

Hallo,

habe heute mein BKW zum Testen mal in Betrieb genommen.
Die DTU wollte ich zuerst mit einem ESP-WROOM-32 aufbauen.
Leider klappte das nicht. Habe es einfach nicht hinbekommen.
Ich konnte problemlos und fehlerfrei das Teil programmieren aber es
erschien kein AP. Die rote LED blinkte nur in kurzen Abständen.
Mit einem D1 mini klappte es dann sofort.
Der AP erschien und es lies sich alles einrichten.
Ich nutze einen HM-800 als WR.

Was mich noch interessieren würde,
die Einrichtung in Home Assistant.
Vielleicht kann da jemand mal etwas näher darauf eingehen.

Ganz großen Dank an die Entwickler der Software und an alle Beteiligten!
Finde ich ganz toll was ihr da geschaffen habt.

mfg

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> hier: bitte aendern
> done.
>
> Die firmware meinte nur, jetzt sei schon Nacht, obwohl noch 70W kamen
> (die Zeit für den Start morgen früh ist aber mAn. ok, der offset sollte
> also eigentlich nicht das Problem sein).

sind die geo daten im secrets.h richtig?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> sind die geo daten im secrets.h richtig?
Denke schon. Wie gesagt, die Berechnung für morgen früh passt.

[Jörg R. (rejoe2)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> sind die geo daten im secrets.h richtig?
> Denke schon. Wie gesagt, die Berechnung für morgen früh passt.
Hmmm, evtl. habe ich die Angabe auch falsch interpretiert und es muss 
doch der offset eingestellt werden? Der ESP tickt ja insgesamt um eine 
Stunde versetzt...?!?

Na ja, jedenfalls vielleicht noch interessant: grade gab es 2 mal einen 
"2"-er Status bei Leistungen von um 1W herum. Auf einem Ausgang 
wechselte das kurz auf "3", dann wieder zurück auf "2", und jetzt 
scheint die "3" auf beiden Ports stabil zu sein.

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Na ja, jedenfalls vielleicht noch interessant: grade gab es 2 mal einen
> "2"-er Status bei Leistungen von um 1W herum. Auf einem Ausgang
> wechselte das kurz auf "3", dann wieder zurück auf "2", und jetzt
> scheint die "3" auf beiden Ports stabil zu sein.
das muss so etwas sein wie du gesagt hast, soll ichm schon oder soll ich 
doch noch nicht produzieren :-)
es ist schwierig diese meldungen fest zu nageln, zu mal ich z.b. die 2 
nicht sehe, auch beim sniffen nicht

[Ziyat T. (toe_c)]

Hoylmoly DTU für MI / TSUN

ich habe folgendes "problem" fest gestellt:

mein MI1500 scheint nicht linear zu produzieren, so etwa ab 500W,
d.h. wenn ich z.B. auf 650W limitiere, bekomme ich den wr nicht dorthin, 
bzw. weit weg davon. bis etwa 500W scheint es ok zu sein.

ich bin mir nicht sicher ob es nur bei mir ist oder nicht.

kann jemand von den MI/TSUN leute das mal testen bitte?

in der version von https://github.com/Ziyatoe/DTUsimMI-Hoymiles, hab ich 
einen FACTOR, der versucht diese unlinaearitaet ab 500W auszugleichen.

so testen:
- ZEROEXP        = false;  setzen
- console eingabe(serial command): 2, siehe FACTOR ist default 3
- console eingabe:  100-2000 (limitieren watt)
- der wr sollte innert ca. 40sek dort sein
- wenn nicht, ev. mit FACTOR  spielen, console eingabe: 22-29 (FACTOR 
2-9)
- besten FACTOR notieren
danke!

[David B. (mystisch)]

ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR 
bekomme.
wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich 
dann sehen, welche packete vom WR kommen und welche vom sim-DTU?

[Ziyat T. (toe_c)]

David B. schrieb:
> ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR
> bekomme.

ich gehe davon aus , dass du die pin's (CE/CS ev. IRQ) richtig 
konfiguriert hast.

verwendest du meine letzte version vom git?
https://github.com/Ziyatoe/DTUsimMI-Hoymiles
wenn ja:
in der console 1 geben, du siehst alle befehle,
zeigen was du sendest: eingabe 9 (show tx), wieder mit 9 stoppen.

dann z.B. PA_LEVEL höher stellen: eingabe 3-5

dann ohne CRC ausprobieren: eingabe 11


> wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich
> dann sehen, welche packete vom WR kommen und welche vom sim-DTU?

ich würde zum sniffen unbedingt diesen verwenden:
https://github.com/Ziyatoe/DTUsimMI-Hoymiles/tree/main/sniffer

da solltest du deine dtu/wr adressen sehen können, bzw. mit grep 
filtern:
CH 40 P 1 DTUADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|WRADRESSE) xx xx 
[03 82]
oder
CH 40 P 1 WRADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|DTUADRESSE) xx xx 
[03 82]

[Jörg R. (rejoe2)]

David B. schrieb:
> ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR
> bekomme.
Bei mir wird das mit dem diesbezüglichen Tests auch erst wieder am WE 
passen, zumal das kleine ggf. nicht direkt vergleichbar ist.

> wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich
> dann sehen, welche packete vom WR kommen und welche vom sim-DTU?
Die Messages folgen einem bestimmten Muster, was die Adressen angeht:
"An" (andere Kopfdaten) "von" "über" (wobei "über" hier in der Regel 
"von" entspricht).

[David B. (mystisch)]

Ziyat T. schrieb:
> David B. schrieb:
>> ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR
>> bekomme.
>
> ich gehe davon aus , dass du die pin's (CE/CS ev. IRQ) richtig
> konfiguriert hast.
>
 #define RF1_CE_PIN  2//(D4) //(D2)
 #define RF1_CS_PIN  15//(D8) //(D8)
 #define RF1_IRQ_PIN 0//(D3)
ja, sonst würde der sniffer auch keine daten bekommen.

> verwendest du meine letzte version vom git?
ich habe dir ein mit mitschnitt der Sniffer ausgabe per PN geschickt.

ich habe die Version von stand gestern Abend genutzt. die letzte Version 
von heute Morgen noch nicht.

> https://github.com/Ziyatoe/DTUsimMI-Hoymiles
> wenn ja:
> in der console 1 geben, du siehst alle befehle,
> zeigen was du sendest: eingabe 9 (show tx), wieder mit 9 stoppen.
>
> dann z.B. PA_LEVEL höher stellen: eingabe 3-5
>
> dann ohne CRC ausprobieren: eingabe 11
>
>
>> wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich
>> dann sehen, welche packete vom WR kommen und welche vom sim-DTU?
>
> ich würde zum sniffen unbedingt diesen verwenden:
> https://github.com/Ziyatoe/DTUsimMI-Hoymiles/tree/main/sniffer
>
> da solltest du deine dtu/wr adressen sehen können, bzw. mit grep
> filtern:
> CH 40 P 1 DTUADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|WRADRESSE) xx xx
> [03 82]
> oder
> CH 40 P 1 WRADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|DTUADRESSE) xx xx
> [03 82]
okay cool, dann hole ich mir den Sniffer gleich von 
https://github.com/Ziyatoe/DTUsimMI-Hoymiles/tree/main/sniffer

[David B. (mystisch)]

ich hornochse..... sorry. naja wenn man die seriennummber WR in MY_MI_WR 
und MY_DTU_PRO kopiert, dann gehört man ...
Danke, mit dem neuen sniffer isses mir gleich aufgefallen....

Und plötzlich macht man es richtig, kommen schon Daten vom WR....

[Ziyat T. (toe_c)]

David B. schrieb:
> ich hornochse..... sorry. naja wenn man die seriennummber WR in MY_MI_WR
> und MY_DTU_PRO kopiert, dann gehört man ...
> Danke, mit dem neuen sniffer isses mir gleich aufgefallen....
>
> Und plötzlich macht man es richtig, kommen schon Daten vom WR....

ja super, gratuliere!!!

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ja super, gratuliere!!!
Schließe mich an!

[David B. (mystisch)]

mein WR limitiert nicht, gut oder schlecht ;)
über den debug den Wert 100 übergeben
RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100
RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100
RFisTime2Send: CMD:051 CH:61 Sts:1 Setting limit:100
MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:23
CH:23 0377W [PV1 188.7W 30.5V  6.4A 1037Wh][238.3V 50.0Hz 47.3C S:3] 
Grid:0000W Lmt:0100W PVok:0  00:00:03:27:738

WR quittiert, aber fördert dann unbeindruckt weiter(nicht dass es mich 
stört), aber fürs Testen der Linearität nix gut.

CH:23 0332W [PV1 166.8W 30.7V  5.6A 1048Wh][238.4V 50.0Hz 46.8C S:3] 
Grid:0000W Lmt:0100W PVok:2  00:00:07:10:254
CH:23 0333W [PV0 167.1W 30.6V  5.6A 1030Wh][238.7V 50.0Hz 46.8C S:3] 
Grid:0000W Lmt:0100W PVok:2  00:00:07:14:507

[Ziyat T. (toe_c)]

David B. schrieb:
> mein WR limitiert nicht, gut oder schlecht ;)
> über den debug den Wert 100 übergeben
> RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100
> RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100
> RFisTime2Send: CMD:051 CH:61 Sts:1 Setting limit:100
> MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:23
> CH:23 0377W [PV1 188.7W 30.5V  6.4A 1037Wh][238.3V 50.0Hz 47.3C S:3]
> Grid:0000W Lmt:0100W PVok:0  00:00:03:27:738
>
> WR quittiert, aber fördert dann unbeindruckt weiter(nicht dass es mich
> stört), aber fürs Testen der Linearität nix gut.
>
> CH:23 0332W [PV1 166.8W 30.7V  5.6A 1048Wh][238.4V 50.0Hz 46.8C S:3]
> Grid:0000W Lmt:0100W PVok:2  00:00:07:10:254
> CH:23 0333W [PV0 167.1W 30.6V  5.6A 1030Wh][238.7V 50.0Hz 46.8C S:3]
> Grid:0000W Lmt:0100W PVok:2  00:00:07:14:507

ja, tatsaechlich eine ack da für 0x51/0x5a5a, hmmmm
das ist sehr eigenartig, aber bei denen glaube ich bald alles...
ah ja, ist dein MI600 ein normaler oder irgend was spez. für D?

[David B. (mystisch)]

Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar 
gekauft, leider auf der Rechnung nicht weiter deklariert.

[Ziyat T. (toe_c)]

könnte mir bitte jemand neuen discord link bekannt geben? danke

[Ziyat T. (toe_c)]

David B. schrieb:
> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar
> gekauft, leider auf der Rechnung nicht weiter deklariert.

es waere interresant, die etikette zu sehen

[S. (Gast)]

Ziyat T. schrieb:
> wer zu wissen möchte,
> reaktionszeit eines MI1550 auf cmd=0x51 (0x5A5A, limit)  etwa 20sek

https://discord.gg/WzhxEY62mB

[S. (Gast)]

Ziyat T. schrieb:
> könnte mir bitte jemand neuen discord link bekannt geben? danke

https://discord.gg/WzhxEY62mB

[Ziyat T. (toe_c)]

S. schrieb:
> Ziyat T. schrieb:
>> könnte mir bitte jemand neuen discord link bekannt geben? danke
>
> https://discord.gg/WzhxEY62mB

danke, aber beide links sind ungültig

[Günter H. (gnter_h534)]

Ich könnte auch nur den gleichen Link noch einmal versenden. Ich habe 
beide Links oben getestet - bei mir funktionieren sie.

[Ziyat T. (toe_c)]

Günter H. schrieb:
> Ich könnte auch nur den gleichen Link noch einmal versenden. Ich habe
> beide Links oben getestet - bei mir funktionieren sie.

danke, kenn mich mit discord nicht aus, schauen die echt auf die 
location, woher man kommt? wenn es nur für D oder EU ist, dann würde es 
für mich nicht funzen...

[David B. (mystisch)]

Ziyat T. schrieb:
> David B. schrieb:
>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar
>> gekauft, leider auf der Rechnung nicht weiter deklariert.
>
> es waere interresant, die etikette zu sehen

Hier :-) 600D EU HM
By the way, kann der MI-600 Max 760W und nicht nur 600W

[Daniel (Gast)]

Ziyat T. schrieb:
> danke, kenn mich mit discord nicht aus, schauen die echt auf die
> location, woher man kommt? wenn es nur für D oder EU ist, dann würde es
> für mich nicht funzen...

Moin, du warst doch schonmal in der Gruppe wenn ich mich richtig 
entsinne?
Oder hast du ein neuen Account?

[Ziyat T. (toe_c)]

Daniel schrieb:
> Ziyat T. schrieb:
>> danke, kenn mich mit discord nicht aus, schauen die echt auf die
>> location, woher man kommt? wenn es nur für D oder EU ist, dann würde es
>> für mich nicht funzen...
>
> Moin, du warst doch schonmal in der Gruppe wenn ich mich richtig
> entsinne?
> Oder hast du ein neuen Account?

guten morgen, nein war noch nie in der gruppe, hab aber einen account

[Ziyat T. (toe_c)]

David B. schrieb:
> Ziyat T. schrieb:
>> David B. schrieb:
>>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar
>>> gekauft, leider auf der Rechnung nicht weiter deklariert.
>>
>> es waere interresant, die etikette zu sehen
>
> Hier :-) 600D EU HM
> By the way, kann der MI-600 Max 760W und nicht nur 600W
an der etikette ist nichts besonders vermerkt.
der will einfach mehr produzieren und nicht limitiert werden:-))

[Jörg R. (rejoe2)]

David B. schrieb:
> Hier :-) 600D EU HM
> By the way, kann der MI-600 Max 760W und nicht nur 600W
Interessant... Mein Etikett sieht etwas anders aus, da ist der 
2*380W-Panel-Hinweis nicht drauf, dafür aber die genauere 
Modell-Bezeichnung rechts incl. Strichcode direkt auf dem Etikett 
aufgedruckt.
600D.NL.HM

Fertigungsdatum war wohl Jan. 2000 (sn-Bestandteil 601).

[Dirk S. (fusebit)]

David B. schrieb:
> Ziyat T. schrieb:
>> David B. schrieb:
>>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar
>>> gekauft, leider auf der Rechnung nicht weiter deklariert.
>>
>> es waere interresant, die etikette zu sehen
>
> Hier :-) 600D EU HM
> By the way, kann der MI-600 Max 760W und nicht nur 600W

Ich denke nicht das es so gemeint ist.
Die empfohlene Modulleistung ist maximal 760W um auch bei suboptimalen 
Bedingungen 600W Strom zu erhalten. Der WR macht trotzdem nur maximal 
600W Ausgangsleistung (dafür braucht er etwa 632 W DC).

[David B. (mystisch)]

Dirk S. schrieb:
> David B. schrieb:
>> Ziyat T. schrieb:
>>> David B. schrieb:
>>>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar
>>>> gekauft, leider auf der Rechnung nicht weiter deklariert.
>>>
>>> es waere interresant, die etikette zu sehen
>>
>> Hier :-) 600D EU HM
>> By the way, kann der MI-600 Max 760W und nicht nur 600W
>
> Ich denke nicht das es so gemeint ist.
> Die empfohlene Modulleistung ist maximal 760W um auch bei suboptimalen
> Bedingungen 600W Strom zu erhalten. Der WR macht trotzdem nur maximal
> 600W Ausgangsleistung (dafür braucht er etwa 632 W DC).

Kann ich so nicht bestätigen, kommen unter guten Bedingungen auch mal 
deutlich mehr als 600W raus.

[Grisu (krisu)]

Ja und, deshalb ist der WR -600 auch auf 600W am Ausgang limitiert. Die 
Panele können bzw. sollen auch ruhig mehr Peak haben, hier werden eben 
bis zu 380W/Panel empfohlen. Wenn es kalt ist bei perfekter Einstrahlung 
bzw. günstigen Wolken können die Panele schon mal 350W liefern 
kurzzeitig. Ist aber auch egal da diese Peaks nichts ausmachen im 
Betrieb.

[David B. (mystisch)]

Grisu schrieb:
> Ja und, deshalb ist der WR -600 auch auf 600W am Ausgang limitiert. Die
> Panele können bzw. sollen auch ruhig mehr Peak haben, hier werden eben
> bis zu 380W/Panel empfohlen. Wenn es kalt ist bei perfekter Einstrahlung
> bzw. günstigen Wolken können die Panele schon mal 350W liefern
> kurzzeitig. Ist aber auch egal da diese Peaks nichts ausmachen im
> Betrieb.

Ich verstehe das schon, kann’s aber bei mir nicht nachvollziehen, am 
Ausgang WR kommen auch mal mehr als 600W bei perfekten Konditionen, 
Rekord waren 679W über einen Zeitraum von knapp 20 Minuten Anfang April.
Aber darum gehts auch nicht, Problem war ja, das ich bei mir den Test 
von Ziyat bezüglich der Limitierung und linearität machen wollte, was 
bei mir nicht klappte.

[Grisu (krisu)]

Echt wahr?
Das finde ich dann wirklich spannend, ist wohl keine so harte Grenze in 
den WRn, sondern eher abhängig von Temp. usw. was er grad wirklich 
zusammenbringt und 600W ist der Max-Wert unter ihren 
"Standard"-Bedingungen, welche auch immer das sein mögen.
Versteh dann nur nicht ganz wie sie dann eine EU-Zulassung bekommen 
können, die ja sicher keine Überschreitung der Werte (welche auch immer 
national dann gelten mögen) tolerieren. Wenn der -800 über 800W geht ist 
das ja als Balkonkraftwerk ein Ausschlußgrund (bzw. der -600 über 600W 
Limit nach der deutschen Bestimmung soviel ich weiß).

[David B. (mystisch)]

Grisu schrieb:
> Echt wahr?
> Das finde ich dann wirklich spannend, ist wohl keine so harte Grenze in
> den WRn, sondern eher abhängig von Temp. usw. was er grad wirklich
> zusammenbringt und 600W ist der Max-Wert unter ihren
> "Standard"-Bedingungen, welche auch immer das sein mögen.
> Versteh dann nur nicht ganz wie sie dann eine EU-Zulassung bekommen
> können, die ja sicher keine Überschreitung der Werte (welche auch immer
> national dann gelten mögen) tolerieren. Wenn der Mann

Verstehe ich nicht, was die Leistungsgrenzen mit EU-Zulassungen zu tun 
hat. Geht doch eher um die Genehmigungspflichten, welche je nach 
Bundesland bis 600W entfallen.
Desweitern macht der WR auch 3A auf dauer, was bei 230V auch mehr als 
600W ergibt.
Wie gesagt, wir kommen vom Thema ab.

[Sven K. (svenk)]

@David:
Hast Du schon versucht Deinen Wechselrichter als Hm einzugeben?
Also statt 1041xxxxxxxx 1141xxxxxxxx
in Ahoy Software als Wechselrichter Seriennummer einzugeben?

Vg
Sven

[David B. (mystisch)]

Sven K. schrieb:
> @David:
> Hast Du schon versucht Deinen Wechselrichter als Hm einzugeben?
> Also statt 1041xxxxxxxx 1141xxxxxxxx
> in Ahoy Software als Wechselrichter Seriennummer einzugeben?
>
> Vg
> Sven

Nein hab ich nicht. Du meinst wegen der Limitierung oder warum sollte 
ich das Probieren?

[Grisu (krisu)]

Die Engpaßleistung brauchst doch für jede Bewilligung, oder?
Und die wird durchschnittlich nunmal vom WR ausgangsseitig vorgegeben. 
Wenn man sich nicht darauf verlassen kann wird man doch irgendwo 
Probleme bekommen können - denk ich.
Obendrein ist gerade die Ausgangsleistung sehr wichtig für die 
Dimensionierung der Leitungen und Sicherungen, insbes. wenn man diese in 
Serie hängt wie es ja u.a. auch vorgesehen ist.

[M. P. (matze7779)]

Ziyat T. schrieb:
> mein MI1500 scheint nicht linear zu produzieren, so etwa ab 500W,
> d.h. wenn ich z.B. auf 650W limitiere, bekomme ich den wr nicht dorthin,
> bzw. weit weg davon. bis etwa 500W scheint es ok zu sein.

Du hast bedacht das die Limitierung nicht für die Gesamtleistung ist?

Wenn Du auf 650 limitierst wird MPPT 1 auf 325W und MPPT 2 auch auf 325 
limitiert.

Wenn die Solarzellen bei MPPT 1 momentan 600W könnten und die an MPPT 2 
nur 100W (wegen der Sonneneinstrahlung) kommen nur 325+100= 425W bei 
raus und nicht 650W.

Zumindest kommt es mir am HM-800 und HM-1200 so vor.

[Johannes (derfrickler)]

Läßt sich eigentlich bei den für DE ab Werk 600W limitierten die max 
Leistung auch höher als 600w setzten? Naturlich nur sofern die Hardware 
ohne die Limitierung mehr könnte.
Ich habe 2 Panels ost-west die jeweils über 300w könnten, aber der TSUN 
is halt auf 600 Limitiert und macht so scheinbar auch max 300 pro Strang 
womit ich nie die 600 erreichen werde.

[M. P. (matze7779)]

M. P. schrieb:
> Zumindest kommt es mir am HM-800 und HM-1200 so vor.

Gerade nochmal getestet: Ist so.

[Ziyat T. (toe_c)]

M. P. schrieb:
> Ziyat T. schrieb:
>> mein MI1500 scheint nicht linear zu produzieren, so etwa ab 500W,
>> d.h. wenn ich z.B. auf 650W limitiere, bekomme ich den wr nicht dorthin,
>> bzw. weit weg davon. bis etwa 500W scheint es ok zu sein.
>
> Du hast bedacht das die Limitierung nicht für die Gesamtleistung ist?
>
der wr versteht es so, gem. hoymiles:
- P_Limit is the power limit, the percentage of the rated power, the 
range is 0~100,
- P_Limit1 is the absolute value of the power limit, the unit is W, with 
1 decimal place

ich gehe davon aus, dass P_Limit1 auch das "power limit of the rated 
power" ist, so hab ich es programmiert, ich glaube bei ahoy-dtu ists 
auch so.

hebe nen MI1500 mit 3 pv's, wenn ich um 12-13uhr teste, habe voll die 
sonne, 2 mmpt's sollten ja voll aufmachen, bekomme ich dann auch 850W 
bei 57C!

aber die linearitaet ist nicht vorhanden, siehe dateianhang
edit:im log, MPPT1:PV1/PV2 MPPT2:PV2/PV3

[Ziyat T. (toe_c)]

David B. schrieb:
> mein WR limitiert nicht, gut oder schlecht ;)

das hat mich beschaeftigt!

ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen 
könntest?
kannst du auch ev. in der console, eingabe 15, auf % wechseln und so mal 
testen

[M. P. (matze7779)]

Dein Log zeigt doch genau das Verhalten was ich sage.

Auszug aus Log.

CH:23 0593W [PV0 185.4W 41.2V  4.7A 0287Wh][237.6V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3  00:03:03:42:51
CH:23 0593W [PV1 223.1W 41.2V  5.6A 0525Wh][237.5V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3  00:03:03:42:302
CH:23 0593W [PV2 184.6W 38.4V  5.0A 0576Wh][237.5V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3  00:03:03:42:552
CH:23 0593W [PV3   0.5W 38.4V  0.0A 0003Wh][237.5V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3  00:03:03:42:803

Limit 800W (also 400W pro MPPT)
PV0 plus PV1 = ca. 408W (also am Limit)
Dazu kommt dann PV2 was die 593W Gesamt ergibt.

Dein 1500er sind einfach zwei 750. Das Limit teilt sich 1zu1 auf beide 
auf.
Ist meiner Meinung nach extrem blöd von Hoymiles das so zu machen.

[Ziyat T. (toe_c)]

M. P. schrieb:
> Dein Log zeigt doch genau das Verhalten was ich sage.
>
> Auszug aus Log.
>
>

> CH:23 0593W [PV0 185.4W 41.2V  4.7A 0287Wh][237.6V 50.0Hz 55.9C S:3] 
> Grid:0239W Lmt:0800W PVok:3  00:03:03:42:51
> CH:23 0593W [PV1 223.1W 41.2V  5.6A 0525Wh][237.5V 50.0Hz 55.9C S:3] 
> Grid:0239W Lmt:0800W PVok:3  00:03:03:42:302
> CH:23 0593W [PV2 184.6W 38.4V  5.0A 0576Wh][237.5V 50.0Hz 55.9C S:3] 
> Grid:0239W Lmt:0800W PVok:3  00:03:03:42:552
> CH:23 0593W [PV3   0.5W 38.4V  0.0A 0003Wh][237.5V 50.0Hz 55.9C S:3] 
> Grid:0239W Lmt:0800W PVok:3  00:03:03:42:803
>

>
> Limit 800W (also 400W pro MPPT)
> PV0 plus PV1 = ca. 408W (also am Limit)
> Dazu kommt dann PV2 was die 593W Gesamt ergibt.
>
> Dein 1500er sind einfach zwei 750. Das Limit teilt sich 1zu1 auf beide
> auf.
> Ist meiner Meinung nach extrem blöd von Hoymiles das so zu machen.

du hast recht mit deiner rechnung, was sie geschrieben haben ist nicht 
ganz verstaendlich,oder ich habs nicht kapiert.
jedenfalls ist es natürlich blöd von hoymiles es so zu machen, darum 
gibts bei der DTU-Pro/modbus register ja nur die prozentuale 
limitierung.

edit: das wirkt ja auch auf die feste limitierung aus, wenn jemand nicht 
alle ports des wr's angeschlossen hat, stimmt die limitierung nicht, hmm 
echt sch...
jetzt muss ich mir überlegen wie ich das lösen könnte,
unsere limit_P = WR_P, any thoughts?

[Jörg R. (rejoe2)]

Hmmm, im Prinzip wissen wir doch anhand der sn, wieviele Ports da sind, 
und in dem "3-er Fall" (wie in deiner Konfiguration) müßte man dann halt 
hergehen und die Limitierung passend verteilen, also im "zulässigen 
Bereich" durch 3 mal 4 rechnen (15%=>20%, 75%=>100%), und erst dann 
diese neue Effektivbegrenzung wieder auf beide MPPT verteilen.
Oder ist das zu einfach gedacht?

[Grisu (krisu)]

Ist doch technisch logisch und auch nachvollziehbar, da auch die (intern 
doppelt ausgelegte) Ausgangselektronik eben pro MPPT auf eine gewisse 
Leistung dimensioniert ist, die nicht überschritten werden darf, um 
nichts abzuglühen.

[Ziyat T. (toe_c)]

Grisu schrieb:
> Ist doch technisch logisch und auch nachvollziehbar, da auch die (intern
> doppelt ausgelegte) Ausgangselektronik eben pro MPPT auf eine gewisse
> Leistung dimensioniert ist, die nicht überschritten werden darf, um
> nichts abzuglühen.

für mich ist das nicht sauber gelöst, ich hab praktisch die leistung da, 
aber kann so nicht abrufen.
z.B. mittag voll aufgedreht hab 850W, wenn ich auf 600W limitiere, macht 
der
mppt1=300W, mppt2=300W, wenn ich nur 3pv's habe bekomme ich 
300+ca150=450W, obwohl ich nur über mppt1 (850/2)425W ziehen könnte

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hmmm, im Prinzip wissen wir doch anhand der sn, wieviele Ports da sind,
> und in dem "3-er Fall" (wie in deiner Konfiguration) müßte man dann halt
> hergehen und die Limitierung passend verteilen, also im "zulässigen
> Bereich" durch 3 mal 4 rechnen (15%=>20%, 75%=>100%), und erst dann
> diese neue Effektivbegrenzung wieder auf beide MPPT verteilen.
> Oder ist das zu einfach gedacht?

ja, wenn ich die einzelne mppt's direkt ansteuern könnte waere es so ok, 
aber wir haben nur eine absolute limitpower zahl zu versenden, oder habe 
dich falsch verstanden? mach mir bitte eine rechnung, mit MI maxpower 
1500w 2 mppt, 3 pv

[Jörg R. (rejoe2)]

Du willst z.B. 600W haben:
600/3*4 => 800W effektiv. Ist zulässig (da weniger wie 1500) => kann man 
direkt angeben.

"Komisch" ist dann nur, dass der WR vermutlich dann zurückmeldet, dass 
er auf 800 limitiert sei. Vermutlich ist es einfacher, das auf der Seite 
der Automatisierungslösung zu machen, also dem WR gleich die 800 zu 
senden und eben zu wissen, dass das dann effektiv 600 sind...

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> edit: das wirkt ja auch auf die feste limitierung aus, wenn jemand nicht
> alle ports des wr's angeschlossen hat, stimmt die limitierung nicht, hmm
> echt sch...
> jetzt muss ich mir überlegen wie ich das lösen könnte,
> unsere limit_P = WR_P, any thoughts?

Moin Ziyat, ich habe es schon in Diskord geantwortet.
Jedoch auch für die anderen hier nochmal zum lesen:

> Hierzu würde ich Vorschlagen eine kleine Funktion zu bauen.
> Jedesmal wenn man ein neuen Wert zum WR schickt, wird vorher abgefragt ob an 
beiden MPPT eine Leistung erzeugt wird.
> Ist dies der Fall, dann soll der Wert ganz normal an den WR geschickt werden.
>
> Ist nur ein MPPT "vorhanden", oder durch Schatten abgedeckt (beide Leistungen 
von MPPT sind ungleich):
> Soll die Leistung mal zwei Multipliziert werden.
>
> ----------
>
> Man kann es auch so weit treiben das die DTU, denn Wert beider MPPT Tracker 
überwacht.
> Denn sobald die Verschattung wieder weg ist.
> Hat man ja doppelte Leistung, dann soll er wieder runter regeln.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Du willst z.B. 600W haben:
> 600/3*4 => 800W effektiv. Ist zulässig (da weniger wie 1500) => kann man
> direkt angeben.
>
> "Komisch" ist dann nur, dass der WR vermutlich dann zurückmeldet, dass
> er auf 800 limitiert sei. Vermutlich ist es einfacher, das auf der Seite
> der Automatisierungslösung zu machen, also dem WR gleich die 800 zu
> senden und eben zu wissen, dass das dann effektiv 600 sind...

ja soweit war ich auch, und gefaellt mir nicht so..
aber was macht er wenn die mppt's mit verschiedene pv's-leistungen 
bestückt sind? zB mppt1=200W/350W, mppt2=400W

[Daniel R. (daniel92)]

Das müsste man testen. :)

[Ziyat T. (toe_c)]

(esp8266/holymolydtu MI-1500)
vergleich mit oder ohne interrupt,in etwa gleicher zeit:

mit:
TX statistic:15192
RX statistic:2846

ohne(looping):
TX statistic:16335
RX statistic:8273

@Jörg R. (rejoe2)
der erlös von 2zu1 beim looping trotz des "dauer feuers" ist doch nicht 
schlecht oder? ;-)

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ja soweit war ich auch, und gefaellt mir nicht so..
> aber was macht er wenn die mppt's mit verschiedene pv's-leistungen
> bestückt sind? zB mppt1=200W/350W, mppt2=400W
MAn. braucht man nicht jeden Sonderfall in der firmware abdecken. Man 
kann das ja noch weiter verkomplizieren, indem man die aktuelle 
Beschattung von 350W berücksichtigt...

Sowas kann man wohl nur auf der Seite des 
Heimautomatisierungs-Controllers lösen.

Ziyat T. schrieb:
> @Jörg R. (rejoe2)
> der erlös von 2zu1 beim looping trotz des "dauer feuers" ist doch nicht
> schlecht oder? ;-)
Hmmm, irgendwo hatte ich einen Log-Auszug mit gefühlt 5:4 Rückmeldungen 
gepostet...
Aber ja, die Quote ist recht ordentlich, die Frage bleibt, ob man das 
Dauerfeuer wirklich braucht, um brauchbare Quoten zu erreichen? Aber 
lassen wir das, die DTU macht so ein Dauerfeuer, warum auch immer, und 
es funktioniert wohl, und ich habe auch keinen besseren (dauerhaft 
funktionierenden) Vorschlag anzubieten...

[M. P. (matze7779)]

Naja so ein Sonderfall ist das gar nicht.
Kommt z.B. bei unterschiedlicher Ausrichtung der Module sehr schnell zum 
tragen.

Im ioBroker hatte ich es mal ein "Soll-Limit" als Datenpunkt und dann 
per Skript das Limit in der DTU hoch (bzw. runter) gesetzt bis die 
Ausgangsleistung real beim Soll-Limit war.
Aber dadurch wird das ganze natürlich langsamer.

[Jörg R. (rejoe2)]

Mit "Sonderfall" war eher gemeint, dass die Bestückung gleich so 
ungleichgewichtig ist, und man das direkt in der firmware vercodet.
Auf den aktuellen Sonnenstand, jahreszeitliche Verschattungen usw. kann 
man m.E. sowieso nur im laufenden Betrieb reagieren, und da sind die 
Reaktionszeiten halt wie sie sind.
Wir können ggf. nur dafür sorgen, dass die Trefferquote gut ist, mit der 
Anweisungen auch tatsächlich (schnell) beim Inverter landen...

[David B. (mystisch)]

Ziyat T. schrieb:
> David B. schrieb:
>> mein WR limitiert nicht, gut oder schlecht ;)
>
> das hat mich beschaeftigt!
>
> ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen
> könntest?
> kannst du auch ev. in der console, eingabe 15, auf % wechseln und so mal
> testen

Hey ich wollte nur kurz sagen, dass ich dabei bin, aber im Moment 
dauerbewölkt … daher kann ich nicht testen.
Wird noch dauern.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen
> könntest?

Hab's versucht, aber im Moment kommen mit der aktuellen 1.9 gar keine 
Daten rein; nicht mal mit ausgeschaltetem CRC...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen
>> könntest?
>
> Hab's versucht, aber im Moment kommen mit der aktuellen 1.9 gar keine
> Daten rein; nicht mal mit ausgeschaltetem CRC...

bei mir kein problem, siehe anhang(und datum), hab ja im verlauf nichts 
angepasst, nur bei der limitierung

[David B. (mystisch)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen
>> könntest?
>
> Hab's versucht, aber im Moment kommen mit der aktuellen 1.9 gar keine
> Daten rein; nicht mal mit ausgeschaltetem CRC...

Kann ich nicht bestätigen, läuft ganz gut
Kann nur nicht limitieren, da unter 100W

[Jörg R. (rejoe2)]

...60cm-Problem.
Hatte übersehen, dass mit dem update auch wieder meine PIN-Konfiguration 
geändert worden war...

Limitierung sieht irgendwie komisch aus. Es wird ein Ack behauptet, aber 
effektiv passiert nicht viel. Vielleicht sollte ich die Info über das 
Grid wegschalten?

[Ziyat T. (toe_c)]

@David B. (mystisch)
@Jörg R. (rejoe2)
wenn ihr über die console limitiert (befehl 100-1999):
zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war,
dann spielt das grid keine rolle mehr.

probiert ev. in der console, eingabe 15, auf % wechseln und so mal
testen

bei mir laeuft beides, mit abs-watt und %

[David B. (mystisch)]

Ziyat T. schrieb:
> @David B. (mystisch)
> @Jörg R. (rejoe2)
> wenn ihr über die console limitiert (befehl 100-1999):
> zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war,
> dann spielt das grid keine rolle mehr.
>
> probiert ev. in der console, eingabe 15, auf % wechseln und so mal
> testen
>
> bei mir laeuft beides, mit abs-watt und %

Ab Mittwoch soll das Wetter in München wieder sonniger werden, dann kann 
ich testen

[Qmaxx85 (Gast)]

Hallo zusammen,

alles funzt super solange ich das Teil am PC inkl. Konsole habe.
Sobald ich dieses aber per USB Netzteil versorge bekomme ich keine 
Verbindung mehr.
Könnt Ihr mir sagen warum nicht?

Danke und Gruß

Qmaxx

[M. P. (matze7779)]

Qmaxx85 schrieb:
> Sobald ich dieses aber per USB Netzteil versorge bekomme ich keine
> Verbindung mehr.

Mach mal einen 100uF Elko in die Versorgung vom nRF Funkmodul.

[Jürgen E. (joe73)]

Hallo,
mal eine Frage zur AHOY-DTU.
Es geht um die Zeitdauer zwischen 2 Abfragen.
Diese ist ja auf 30s vor eingestellt.
Gibt es irgendwelche negativen Auswirkungen
wenn ich diese z.B. auf 5s stelle?
Es geht mir darum, dass z.B. bei der Berechnung
der Leistungsdaten über Homeassistant im Vergleich
mit dem Drehstromzähler es zu größeren Ungenauigkeiten kommt.
Bei vorbei fliegenden Wolken z.B. werden
Maxima z.B. über 30s beibehalten obwohl die
hohe Leistung vielleicht nur 5s anlag.

mfg Jürgen

[Qmaxx85 (Gast)]

Hallo M.P,

habe jetzt 100uF mehrere ausprobiert leider ohne Erfolg das Modul wird 
nicht mehr erkannt. Welchen Elko empfelst du? Habe 16v als kleinsten da 
gehabt.

Danke für die Hilfe.

[Grisu (krisu)]

Die Spannung ist völlig egal (weniger=kleiner), da du wohl kaum einen 
unter 6,3V findest (der bereits ausreicht). 100µF sollten mehr als 
ausreichend sein. Und fix verlötet anstatt gesteckt macht auch einen 
Unterschied.
Hast schon ein anderes Netzteil versucht? Leicht möglich, daß deines 
HF-Störungen verursacht, welche bei anderen Anwendungen nicht so ins 
Gewicht fallen.

[Peter Hansen (Gast)]

Moin,
ich lese dort auf dem screenshot, das man hier eine geänderte GPIO's 
verwenden soll oder muss, ist jemand so nett und packt mir eine bin 
Datei von ahoy online damit ich es flashen kann ?

Danke Peter

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> @David B. (mystisch)
> @Jörg R. (rejoe2)
> wenn ihr über die console limitiert (befehl 100-1999):
> zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war,
> dann spielt das grid keine rolle mehr.
>
> probiert ev. in der console, eingabe 15, auf % wechseln und so mal
> testen
>
> bei mir laeuft beides, mit abs-watt und %

Das scheint jeweils beim WR nicht angekommen zu sein, jedenfalls hat es 
auch nach einer Wartezeit von mehr als einer Minute keine Auswirkungen.

Absolut:

CH:40 0140W [PV0  70.2W 33.9V  2.1A 0047Wh][232.9V 50.0Hz 17.1C S:3] Grid:0124W Lmt:0100W PVok:2  00:00:03:34:861
CH:40 0141W [PV1  71.0W 34.1V  2.1A 0048Wh][232.9V 50.0Hz 17.1C S:3] Grid:0124W Lmt:0100W PVok:2  00:00:03:35:614

Relativ:

CH:75 0208W [PV1 104.5W 34.5V  3.1A 0058Wh][234.0V 50.0Hz 17.9C S:3] Grid:0202W Lmt:0016% PVok:2  00:00:10:04:130
CH:75 0208W [PV0 103.5W 34.3V  3.1A 0056Wh][234.2V 50.0Hz 17.9C S:3] Grid:0202W Lmt:0016% PVok:2  00:00:10:07:364

[Qmaxx85 (Gast)]

Hallo,

ich habe alle Netzteile ausprobiert die ich im Haus habe. So ca.7 
verschiedene aber alle verbinden sich nicht. Sobald ich das Kabel in den 
Notebook stecke findet er sofort Wechselrichter und läuft einwandfrei.

Gruß Qmaxx85

[Grisu (krisu)]

Dann versuch es einmal mit einem anderen Kabel.

[Qmaxx85 (Gast)]

Hallo,

ja die Kabel habe ich jetzt auch durchprobiert leider immer ohne erfolg.
Geht das bei dir denn alles so?

[Grisu (krisu)]

Ja, sowohl direkt an der Fritzbox als auch mit eigenem Netzdadapter.
Verwende ein kurzes Ladekabel (ohne Datenleitungen) geht aber mit dem 
anderen langen vollbelegten ebenso.

[Qmaxx85 (Gast)]

Hallo,

habe es auch Grade an der Fritzbox getestet leider auch da ohne Erfolg.

[Hans W. (hans_w801)]

Peter Hansen schrieb:
> Moin,
> ich lese dort auf dem screenshot, das man hier eine geänderte GPIO's
> verwenden soll oder muss, ist jemand so nett und packt mir eine bin
> Datei von ahoy online damit ich es flashen kann ?
>
> Danke Peter

https://github.com/lumapu/ahoy/releases/tag/ahoy_v0.5.17

[Peter Hansen (Gast)]

und genau diese Version geht nicht weil sie nicht angepasst ist

[Jürgen E. (joe73)]

Hallo Peter,
Geht denn bei Dir der ESP-WROOM-32 ohne den NRF24?
Ich habe den ESP einige male geflasht, lt. nodemcu-pyflasher mit
Erfolg, der ESP blinkt dann nur in schneller Folge aber ich
kann keinen AP finden!
Geflasht habe ich die fertige 220906_ahoy_0.5.17_esp32_5402e9b.bin

Was mache ich falsch?
Oder geht es nicht ohne dem NRF24?

Ich bin dann auf den ESP8266 umgestiegen, der funktionierte
sofort. Auch ohne den NRF24

Gruß Jürgen

[Grisu (krisu)]

Peter Hansen schrieb:
> und genau diese Version geht nicht weil sie nicht angepasst ist
Du sollst laut Screenshot ja nur die 3 im UI anpaßbaren ändern.

[Peter Hansen (Gast)]

moin zusammen,
bei mir sagt er auch immer alles okay, aber ich finde auch keinen ap.
ich kann ja nichts ändern, da ich eben nur den flasher habe und dann die 
bins flashe.
da kann man nix ändern.

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Absolut:
>

> CH:40 0140W [PV0  70.2W 33.9V  2.1A 0047Wh][232.9V 50.0Hz 17.1C S:3] 
> Grid:0124W Lmt:0100W PVok:2  00:00:03:34:861
> CH:40 0141W [PV1  71.0W 34.1V  2.1A 0048Wh][232.9V 50.0Hz 17.1C S:3] 
> Grid:0124W Lmt:0100W PVok:2  00:00:03:35:614
>

> Relativ:
>

> CH:75 0208W [PV1 104.5W 34.5V  3.1A 0058Wh][234.0V 50.0Hz 17.9C S:3] 
> Grid:0202W Lmt:0016% PVok:2  00:00:10:04:130
> CH:75 0208W [PV0 103.5W 34.3V  3.1A 0056Wh][234.2V 50.0Hz 17.9C S:3] 
> Grid:0202W Lmt:0016% PVok:2  00:00:10:07:364
>

du hattest gesagt, dass die ACK für die 0x51 kommen, oder nicht?

[Jörg R. (Gast)]

Ja, zumindest gestern hatte ich das gesehen. Heute hatte ich nicht 
explizit aufgelöst, jetzt kann ich gerade nicht schauen.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> du hattest gesagt, dass die ACK für die 0x51 kommen, oder nicht?

Hier auch noch die zugehörige Info aus der Konsole.

zu 100W:

SerialIn: 100 int:100 SerCmd:100
SerialIn: 100 SerCmd:100 Limit:100
RFisTime2Send: CMD 0x0 CH:40 set limiting over serial command
2022-9-17  11:9:31  it's daytime!, SunDown at 19.30
MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:40

zu den 16%:

SerialIn: 100 SerCmd:100 Limit:16
RFisTime2Send: CMD 0x0 CH:61 set limiting over serial command
MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:75

[Hans W. (hans_w801)]

Peter Hansen schrieb:
> moin zusammen,
> bei mir sagt er auch immer alles okay, aber ich finde auch keinen ap.
> ich kann ja nichts ändern, da ich eben nur den flasher habe und dann die
> bins flashe.
> da kann man nix ändern.

schau mal mit der seriellen Konsole, ob du evtl. einen Bootloop nach dem 
flashen der .bin hast

[DaAlchemist (Gast)]

Peter Hansen schrieb:
> moin zusammen,
> bei mir sagt er auch immer alles okay, aber ich finde auch keinen ap.
> ich kann ja nichts ändern, da ich eben nur den flasher habe und dann die
> bins flashe.
> da kann man nix ändern

Eventuell liegt es am Flashen. Sofern du unter Windows flashst, 
überprüfe die Baudrate des virtuellen Com-Ports,die steht meistens auf 
9600. Dann die Rate mal im Flash Programm anpassen.

[Peter Hansen (Gast)]

nein liegt es nicht

[Peter Hansen (Gast)]

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 
(DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download





das steht da mehr nicht

[Hans W. (hans_w801)]

Peter Hansen schrieb:
> ets Jun  8 2016 00:22:57
>
> rst:0x1 (POWERON_RESET),boot:0x3
> (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
> waiting for download

Flash mal mit dem ESP Download Tool

Speed auf 80. Nich wie im Bild auf 40

https://www.espressif.com/sites/default/files/tools/flash_download_tool_3.9.3.zip

Sollte das nicht gehen, flashe einfach mal online

https://install.wled.me/

hatte ich auch schon, das ich einen Bootloop hatte nach dem flashen.
Dann hab ich WLED drauf gemacht und dann Ahoy und dann ging es.
Warum auch immer ....

[Peter Hansen (Gast)]

hat er gemacht....selbes Ergebnis :(

[Hans W. (hans_w801)]

Peter Hansen schrieb:
> hat er gemacht....selbes Ergebnis :(

Beim einstecken des USB Kabels boot Knopf gedrückt gehalten ?

WLED ging auch nicht ?

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> RFisTime2Send: CMD 0x0 CH:61 set limiting over serial command
> MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:75
> [/code]
ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun 
waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für 
gründen auch immer tut er nicht limitieren. in der doku sehe ich auch 
nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade

[Jürgen E. (joe73)]

Hallo,

ich habe gerade mal auf den ESP-WROOM-32 open DTU geflasht.
Das funktionierte sofort.
Ohne NRF24!
Konnte den AP connecten!

Hat allerdings etwas gedauert bis ich Visual Studio usw.
installiert hatte und das alles kapiert habe.

Wo bleiben eigentlich die Daten gespeichert bei Ahoy?
Auf dem 8266 Board oder im jeweiligen Wechselrichter?

Gruß Jürgen

[DaAlchemist (Gast)]

Peter Hansen schrieb:
> nein liegt es nicht

Im flash Programm steht 115000 als Baudrate im Gerätemanger auch?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun
> waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für
> gründen auch immer tut er nicht limitieren. in der doku sehe ich auch
> nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade
So habe ich das auch interpretiert, aber wie gezeigt passiert halt 
effektiv nichts. Kann es sein, dass die älteren/kleineren MI-Modelle die 
Limitierung halt einfach noch nicht konnten?

Bei der Suche nach Infos dazu bin ich über das hier gestolpert:
https://www.fotowoltaika.belos.com.pl/pl/p/file/81017a576a9b3227b6558863e7332e50/manual-mi600-mi700-mi800.pdf
Ist evtl. interessant wegen der Interpretation von Statusmeldungen?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun
>> waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für
>> gründen auch immer tut er nicht limitieren. in der doku sehe ich auch
>> nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade
> So habe ich das auch interpretiert, aber wie gezeigt passiert halt
> effektiv nichts. Kann es sein, dass die älteren/kleineren MI-Modelle die
> Limitierung halt einfach noch nicht konnten?
oder alle die für balkonien in D zugelassen sind?


> Bei der Suche nach Infos dazu bin ich über das hier gestolpert:
> 
https://www.fotowoltaika.belos.com.pl/pl/p/file/81017a576a9b3227b6558863e7332e50/manual-mi600-mi700-mi800.pdf
> Ist evtl. interessant wegen der Interpretation von Statusmeldungen?
diese status meldungen sind nicht vom inverter direkt, die sind imho vom 
smiles cloud bzw. von DTU

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> oder alle die für balkonien in D zugelassen sind?
Kann ich nicht beurteilen, aber wenn ich das richtig interpretiere, gibt 
es die Möglichkeit bei den HM-600 etc..

> diese status meldungen sind nicht vom inverter direkt, die sind imho vom
> smiles cloud bzw. von DTU
Na ja, irgendwoher wird die DTU ihre Weisheit ja beziehen, und das kann 
eigentlich nur die Interpretation der Daten sein, die der WR ihr 
zukommen läßt. Oder?

[Dunky (Gast)]

Gerade bei #eBayKleinanzeigen gefunden. Wie findest du das?

https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-hardware-fuer-ahoy-projekt-hm300-hm400-hm600-hm1500/2201223140-168-5178?utm_source=sharesheet&utm_medium=social&utm_campaign=socialbuttons&utm_content=app_android

Da vertickt jemand eure Erkenntnisse. Nur zur Info

[Dunky (Gast)]

Oder ist das offiziell?

[Dunky (Gast)]

Ok, ich sehe das wurde im Verlauf des threads schon gemeldet. Sorry

[Peter Hansen (Gast)]

....und was genau kann ich nun tun wenn alles okay ist ?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun
> waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für
> gründen auch immer tut er nicht limitieren. in der doku sehe ich auch
> nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade

Vielleicht ist es bei den alten aber auch schlicht ein anderes Kommando? 
Bin wegen eines Posts im FHEM-Forum bei Zeile
https://github.com/atc1441/NETSGPClient/blob/main/src/NETSGPClient.h#L282 
gelandet, nach der es sehr vielleicht auch 0xC3 sein könnte (für 
prozentuale Vorgaben). Werde aber aus den Gesamtzusammenhängen nicht 
ganz schlau, diese Bitschubserei ist irgendwie nicht so meins...

Full story:
Das scheint der überarbeitete Code aus dem "Urvideo" zu sein. Von dem 
hat jemand eine bisher nicht veröffentlichte Kopie gemacht 
(https://forum.fhem.de/index.php/topic,129305.0.html), um damit 
Wechselrichter einer bisher hier nicht aufgeführten Marke (New Energy 
Technology Co., Ltd.) abzuhören bzw. anzusteuern. Deren Produkte (aus 
2019, http://newenergytek.com/index.php/content-51) sehen ziemlich 
identisch aus zu den neueren HM-Modellen (mit externer Antenne). 
Vielleicht ist das eine Art "missing link"...

[Joh (Gast)]

die MI600 lassen sich auch mit der DTU-Pro nicht limitieren, das geht 
nur mit den HM Invertern

[Alfons (alwa)]

Nach Lesen vieler Beiträge fiel mir auf, dass einige ja Probleme haben, 
die Hardware in Betrieb zu nehmen. Dazu kurz meine Erfahrungen:

Flashen mit dem NodeMCU-PyFlasher funktionierte an meinem Notebook 
(TB-Usb-A-Adapter) nur mit einem älteren ESP8266, während das Flashen 
mit zwei ESP32 und zwei D1-Minis fehlerhaft war. Über PlatformIo traten 
die Fehler nicht auf. Ebenso ließen sich die Binärdateien problemlos mit 
dem ESPHome-Flasher 1.4.0-Windows flashen. Entweder es liegt an meinem 
Notebook (i7/Windows11) oder am PyFlasher, keine Ahnung.

Viele D1-Mini-Clones sind mit zu einem schwachen 3,3V-Spannungregler 
bestückt, der gerne nach dem Anschluss des NRF24 durchknallt. Wer also 
nicht weiß, wie er an die besseren D1-Minis rankommt, dem empfehle ich, 
die größeren ESP-Boards zu kaufen, da dort die Regler meist 
leistungsfähiger sind.

Nachdem ich das Ganze über eine Powerbank mit Strom versorge (läuft mit 
einer Ladung fast einen Monat) habe ich keine Receive Fails mehr. Das 
bringt mehr Stabilität als ein kleiner Elko am NRF24, zumindest war es 
bei mir so.

Ansonsten läuft das Ganze bei mir absolut fehlerfrei. Ich bin 
begeistert.

[Jörg R. (rejoe2)]

Joh schrieb:
> die MI600 lassen sich auch mit der DTU-Pro nicht limitieren, das geht
> nur mit den HM Invertern
Danke für die Info!

[David B. (mystisch)]

David B. schrieb:
> Ziyat T. schrieb:
>> @David B. (mystisch)
>> @Jörg R. (rejoe2)
>> wenn ihr über die console limitiert (befehl 100-1999):
>> zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war,
>> dann spielt das grid keine rolle mehr.
>>
>> probiert ev. in der console, eingabe 15, auf % wechseln und so mal
>> testen
>>
>> bei mir laeuft beides, mit abs-watt und %
>
> Ab Mittwoch soll das Wetter in München wieder sonniger werden, dann kann
> ich testen

Hallo zusammen, So endlich Sonne in München, aber die viele Sonne hat 
sich auch wieder nicht limitieren lassen, weder direkt noch prozentual. 
Die Änderungen werden zwar acknowledged, aber mehr auch nicht. WR 
limitiert auch nicht nach 40s

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Joh schrieb:
>> die MI600 lassen sich auch mit der DTU-Pro nicht limitieren, das geht
>> nur mit den HM Invertern
> Danke für die Info!

stimmt nicht ganz, mein MI1500 wird mit meiner DTU-Pro über modbus sehr 
wohl limitiert
auch mit https://github.com/Ziyatoe/DTUsimMI-Hoymiles

[Ziyat T. (toe_c)]

David B. schrieb:

> Hallo zusammen, So endlich Sonne in München, aber die viele Sonne hat
> sich auch wieder nicht limitieren lassen, weder direkt noch prozentual.
> Die Änderungen werden zwar acknowledged, aber mehr auch nicht. WR
> limitiert auch nicht nach 40s

schade, ich werde das verfolgen

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun
>> waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für
>> gründen auch immer tut er nicht limitieren. in der doku sehe ich auch
>> nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade
>
> Vielleicht ist es bei den alten aber auch schlicht ein anderes Kommando?
> Bin wegen eines Posts im FHEM-Forum bei Zeile
> https://github.com/atc1441/NETSGPClient/blob/main/src/NETSGPClient.h#L282
> gelandet, nach der es sehr vielleicht auch 0xC3 sein könnte (für
> prozentuale Vorgaben). Werde aber aus den Gesamtzusammenhängen nicht
> ganz schlau, diese Bitschubserei ist irgendwie nicht so meins...

bei dem geht es ums NETSGP protocol, das haben wir leider nicht. viele 
chinesische alibaba-wr benützen diese
https://de.aliexpress.com/i/4000444523624.html

eine 0xC3 sehe ich auch nicht in der hoymiles-doku

[Tobias (Gast)]

Alfons schrieb:
> Flashen mit dem NodeMCU-PyFlasher funktionierte an meinem Notebook
> (TB-Usb-A-Adapter) nur mit einem älteren ESP8266, während das Flashen
> mit zwei ESP32 und zwei D1-Minis fehlerhaft war. Über PlatformIo traten
> die Fehler nicht auf. Ebenso ließen sich die Binärdateien problemlos mit
> dem ESPHome-Flasher 1.4.0-Windows flashen. Entweder es liegt an meinem
> Notebook (i7/Windows11) oder am PyFlasher, keine Ahnung.

Bei mir das gleiche. Dachte schon die Binaries sind corrupt, ich konnte 
die Firmware auch nur durch PlatformIO auf den ESP32 bekommen. Danke an 
alle Beteiligten für das Projekt, mein HM 1500 mit FW 10018 funktioniert 
damit absolut problemlos. Auch das Drosseln auf 600W funktioniert 
einwandfrei.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> eine 0xC3 sehe ich auch nicht in der hoymiles-doku
...ich auch nicht... Aber wie wir ja an der 0x91/0x92-Frage gesehen 
haben, ist die nicht zwingend 100% akkurat bzw. eindeutig.

Da auch dieses Projekt hier mal mit dem LCirgendwas angefangen hatte, 
könnte es ja ggf. eine gewisse Verwandtschaft geben. Aber klar: sehr 
spekulativ...

[Joh (Gast)]

Jörg R. schrieb:

< stimmt nicht ganz, mein MI1500 wird mit meiner DTU-Pro über modbus 
sehr
< wohl limitiert
< auch mit https://github.com/Ziyatoe/DTUsimMI-Hoymiles

Das kann gut sein, meine Angabe bezieht sich auf die Ausstattung DTU-Pro 
und Hoymiles WR MI-600 und HM-1500 und Leistungsanpassung in der S-Cloud 
jedoch ohne Chint Energiemeter oder direkte Modbus Steuerung.
Danke für den Hinweis dann sind meine MI-600 weiter nützlich.

[Stefan B. (stefan_b278)]

Meinen HM-1500 lese ich zur Zeit mit einem Raspberry Pi 4 und dem NRF 
Modul aus (MQTT). Vielen Dank an alle die das ermöglicht haben.

Hab leider keine Erfahrung mit den ESP aber würde nun gerne einen kaufen 
um den Raspi woanders hinzubauen (Funk reicht dort nicht bis zum WR). 
Gibt es für dieses Projekt schon ein Gehäuse und Netzteil bzw. kann man 
eins empfehlen?

[Grisu (krisu)]

Kannst doch jedes 5V USB Netzteil nehmen von alten Handys etwa.
Und Gehäuse wirds da nix fertiges geben können, da es jeder etwas anders 
aufbaut und zusammenlötet oder steckt.
Da nimmt man doch ein 0815-Gehäuse von irgendwoher und paßt es irgendwie 
ein, reicht doch vollkommen, daß es reinpaßt, und mit Heißklebepistole 
anpicken.

[Stefan B. (stefan_b278)]

Grisu schrieb:
> Kannst doch jedes 5V USB Netzteil nehmen von alten Handys etwa.
Gleich ein 3.3 V Netzteil wird schwierig? Ist wohl auch nicht nötig.

Auf der Github Seite steht:
"Any other ESP8266 Board with at least 4MBytes of ROM could work as 
well, depending on your skills."

Wenn ich einen "D1 Mini Pro" habe was gibt es zu beachten?
C und Python ist kein Problem für mich.

[Peter Hansen (Gast)]

Peter Hansen schrieb:
> ....und was genau kann ich nun tun wenn alles okay ist ?

Hallo ?

[hoytest (Gast)]

Günter H. schrieb:
> Die .bin-Files sind jetzt schon unter
> https://github.com/grindylow/ahoy bzw.
> https://github.com/tbnobody/OpenDTU
> jeweils unter dem Menüpunkt "Actions" chronologisch aufgelistet.
Was ist zum OTA Update zu verwenden? Einfach das opendtu-generic.bin?
Oder muss man ein firmware.bin mit anderem Inhalt erzeugen/laden?
Wenn ja, wie, bzw. wo?

[Giuseppe M. (drdigital)]

Einfach die passende aktuelle .bin laden und über das Webinterface 
upgraden.
Danach startet der ESP Neu und die neueste Firmware sollt laufen.

[Giuseppe M. (drdigital)]

Ich würde gerne einen ESP32-POE von Olimex mit Ahoy nutzen.
https://github.com/OLIMEX/ESP32-POE
Dazu müsste aber die LAN Unterstützung noch in den Code mit rein.
Leider kenne ich mich damit nicht aus.
Kann mir hier jemand weiter helfen?

[hoytest (Gast)]

Giuseppe M. schrieb:
> Einfach die passende aktuelle .bin laden und über das Webinterface
> upgraden.
Soll das eine Antfort auf meine Frage sein?
Falls ja: Ich frage ja gerade, welches die "passende" bin ist.

[Giuseppe M. (drdigital)]

Dann habe ich wohl Deine Frage falsch verstanden.
Wenn Du nicht selber mit z.B. VSCode deine .bin erstellst,
dann nimmst die neueste aus dem Bereich Actions in Github (Achtung man 
kann nur die bin herunterladen, wenn man in github angemeldet ist).
Wenn Du einen ESP32 verwendest kannst entweder die Ahoy für ESP32 bin 
verwenden oder die opendtu-generic.bin.

[Verdreher (Gast)]

Er meint:
„ ….man kann die bin nur herunterladen, wenn man in github angemeldet 
ist“.

[Daniel (da_ba)]

Hallo,

mal kurze Frage:
Wie schnell werden die Daten über die OpenDTU aktualisiert?

Im Hoymiles Webportal ist die Auflösung ja nur 15 Minuten und die Daten 
meistens über eine Stunde alt.

[Grisu (krisu)]

Also ich sehe die Daten meist innerhalb von 5-10 Minuten mit der DTU 
aktualisiert und die sind dann auch aktuell für die letzte 1/4 Stunde.

Die Daten werden hier alle 30s abegefragt, nur bekommst oft keine 
Antwort.

[hoytest (Gast)]

Daniel schrieb:
> Wie schnell werden die Daten über die OpenDTU aktualisiert?
Ich erhalte die Daten alle 5 Sekunden. Man kann aber auch noch kürzere 
Zeiträume einstellen.

[hoytest (Gast)]

Giuseppe M. schrieb:
> Dann habe ich wohl Deine Frage falsch verstanden.
Ja. :-)
Aber auch diese Antwort ist nicht Eindeutig.

Nochmal:
Ist die opendtu-generic.bin aus dem git .zip Identisch mit der selbst 
erzeugten firmware.bin?
Kann ich also einfach die opendtu-generic.bin übers OTA Update 
hochladen?

[Günter H. (Gast)]

Ja.

Ich hoffe, dass dies eine eindeutige Antwort ist.

[nikolaus (Gast)]

Hallo zusammen,
Ich bin kein Progrogrammierer und wäre für Hilfe Dankbar.
Ich habe meinen Hm-600 erfolgreich mit dem esp8266 mit opendtu 
verbunden. Beim Homeassistant  Mqtt installiert.mqtt-user Benutzer 
angelegt.
bei der Konfiguration
Broker:core-mosquitto
Port 1883
Benutzername mqtt-user
das gleiche im Opendtu eingetragen.
wie muss ich nun weiter machen
würde mich freunen wenn ich die Daten schön im Homeassistant anzeigen 
kann

grüße der nikolaus

[hoytest (Gast)]

Günter H. schrieb:
> Ja.
>
> Ich hoffe, dass dies eine eindeutige Antwort ist.

Ist sie. :-)
Danke.

[hoytest (Gast)]

nikolaus schrieb:
> Ich habe meinen Hm-600 erfolgreich mit dem esp8266 mit opendtu
> verbunden.

Läuft opendtu nicht nur auf nem esp32?

[Björn S. (Firma: 1983) (bjoerns1983)]

Jürgen E. schrieb:
> Hallo,
>
> habe heute mein BKW zum Testen mal in Betrieb genommen.
> Die DTU wollte ich zuerst mit einem ESP-WROOM-32 aufbauen.
> Leider klappte das nicht. Habe es einfach nicht hinbekommen.
> Ich konnte problemlos und fehlerfrei das Teil programmieren aber es
> erschien kein AP. Die rote LED blinkte nur in kurzen Abständen.
> Mit einem D1 mini klappte es dann sofort.

Guten Morgen,
ich habe genau das gleiche Problem. Egal ob vorkompilierte Version oder 
selbst mit Plattform IO kompiliert.
Flashe ich das Programm auf mein ESP32 Devkit C Board (eigentlich nichts 
besonderes) blinkt nur schnell die LED und nichts weiter passiert.

das Board ist in Ordnung, andere Projekte lassen sich Problemlos darauf 
flashen etc.

Hat hier jemand die Firmware erfolgreich auf ESP32 Hardware zum laufen 
gebracht?

[nikolaus (Gast)]

Sorry ja ist ein ESP32

[Björn S. (Firma: 1983) (bjoerns1983)]

Okay mit der integrierten Flashfunktion in Visual Studio Code scheint es 
doch zu funktionieren.

[was-soll-so-was (Gast)]

Was soll so was ?
Das ist ein Schlag ins Gesicht von Allen, die hier aktiv mitarbeiten.

https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-inverter-/2224890964-168-6820

https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=58131475

[Helmut H. (der_andere)]

Ob das das zuständige Finanzamt weiß?
Wenn jemand mir die Bauteile schickt, ein Rücksendeschein dabei legt, 
flashe ich sowas umsonst, vorzugsweise ESP32, weil stabiler.

[David B. (mystisch)]

was-soll-so-was schrieb:
> Was soll so was ?
> Das ist ein Schlag ins Gesicht von Allen, die hier aktiv mitarbeiten.
>
> 
https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-inverter-/2224890964-168-6820
>
> https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=58131475

Wow rechtlich aber recht schwammig, unter welcher Lizenz läuft denn die 
AHOY DTU?

Auf der anderen Seite, weder Gehäuse und Netzteil. Dafür noch 86Euro 
abdrücken. Jemand der noch Gehäuse und Netzteil spendieren muss, der 
sollte auch so weit bewandert sein auf ein Wemos die DTU installieren zu 
können…

[Jörg R. (rejoe2)]

David B. schrieb:
> Auf der anderen Seite, weder Gehäuse und Netzteil. Dafür noch 86Euro
> abdrücken. Jemand der noch Gehäuse und Netzteil spendieren muss, der
> sollte auch so weit bewandert sein auf ein Wemos die DTU installieren zu
> können…
...nicht mal einen Kondensator drauf...

Na ja, mal abgesehen von den Steuer- und Lizensierungsfragen hat mal an 
anderer Stelle jemand gemeint: "Jedes Angebot ist ein gutes Angebot! Man 
muss es ja nicht annehmen..."
Indirekt macht dieser Anbieter ja "Werbung" für das Projekt. Ärgerlich 
wird es nur, wenn jemand, der dafür derart viel Moos liegen läßt, dann 
hier aufschlagen würde und sich beschweren, weil irgendwas nicht so 
läuft, wie er das als "Verbraucher" erwarten darf, der schließlich sein 
sauer verdientes Geld dafür ausgegeben hat. Soweit ist es ja (zum 
Glück!) bisher nicht gekommen.

Aber an sich sollte es in diesem Thread ja v.a. um Entwicklungsthemen 
gehen, und nicht um allgemeinen Stress beim Flashen von ESP's oder der 
Frage, wie man bestimmte Automatisierungslösungen dafür konfiguriert...

[Helmut H. (der_andere)]

Jörg R. schrieb:
> Aber an sich sollte es in diesem Thread ja v.a. um Entwicklungsthemen
> gehen, und nicht um allgemeinen Stress beim Flashen von ESP's

Richtig, nur treibt es nicht so fitte Leute in die EBAY Arme.

Ev. sind es durchaus Wechselrichter Insider, die aber so'n Flash Kram 
nicht hinbekommen, bzw dessen Anbindung in die Smarthome-Welt gerne 
hätten.

Zusätzlich könnten Diese dann dem Entwickler eine Spende generieren, was 
sonst sicher nicht passiert und DAS würde ich gut finden.

[Torsten (nefilim)]

Hallo,

ich würde zur allgemeinen Erheiterung gerne mal eine totale 
Anfängerfrage stellen: Habe heute Post bekommen und Wemos D1 Mini sowie 
NRF24L01+ Modul aus https://github.com/lumapu/ahoy/issues/230 erhalten. 
Das Wemos zu verkabeln bekomme ich hin. Das NRF24L01+ hat aber ein 
engeres Rastermaß (1.27?). Buchsenleisten finde ich dafür, aber wie 
bekomme ich dann die Leitungen vom Wemos da dran?

Das besagte NRF24L01+ benötigt keine weitere Antenne, so wie hier auf 
diversen Fotos zu sehen?

[Grisu (krisu)]

Löten statt stecken, ist sowieso viel besser?

[Torsten (nefilim)]

OK, dann mach ich das so. Merci!

[Giuseppe M. (drdigital)]

Zwischenzeitlich habe ich herausgefunden, dass OpenDTU den Olimex 
ESP32-POE unterstützt.
Ich würde aber gerne Ahoy nutzen.
Reicht es aus in der platformio.ini den Olimex einzufügen?
z.B. so:

[env:esp32-poe]
platform = espressif32
board = esp32-poe
build_flags = -D RELEASE
monitor_filters =
  ;default   ; Remove typical terminal control codes from input
  time      ; Add timestamp with milliseconds for each new line
    ;log2file  ; Log data to a file “platformio-device-monitor-*.log” 
located in the current working directory

Oder muss da noch mehr geändert werden?

[Mistljo (Gast)]

Hallo zusammen, vielleicht schon bekannt: Für das Hoymiles DTU Pro steht 
der Sourcecode (stand 06.2020) auf gitee -> 
https://gitee.com/iotloves/hoymiles-DTU-PRO/

Viel Spass noch an alle
Mistljo

[Christian O. (ottelo)]

Hi. Ich habe den HM-800 und wollte OpenDTU ohne angeschlossene Module 
testen. Aber mein Wechselrichter tut absolut nichts (LED leuchtet 
nicht). Ist das so korrekt oder ist mein WR tot?

[Tesla (Gast)]

Woher denkst Du bezieht der WR seine Energie?

[Christian O. (ottelo)]

Achso, also rein aus den Modulen? Dann funktioniert die Funkeinheit nur 
wenn Sonne da ist oder wie?

[Grisu (krisu)]

Na in der Nacht sendet er jedenfalls nix. Sonne brauchts dazu nicht.
Außerdem solltest du wissen, daß die Netzseite abgeschaltet ist wenn er 
nicht in Betrieb oder abgesteckt ist.

Was sollte er dir außerdem senden, daß keine Produktion stattfindet???
Sehr informativ .... daß merkt die DTU auch so wenn sie ihn nicht 
erreicht.
Oder wär dir lieber er säuft sogar noch Strom nur um dir zu melden 
wieviel du grad sinnlos verbrauchst?

[Volker (Gast)]

Helmut H. schrieb:
> Wenn jemand mir die Bauteile schickt, ein Rücksendeschein dabei legt,
> flashe ich sowas umsonst, vorzugsweise ESP32, weil stabiler.

Dann schick mir mal deine Adresse bitte


Volker

[Helmut H. (der_andere)]

Melde Dich hier an, dann auf "der_andere" klicken und mir dann eine PN 
schicken ob Du Ahoy oder OpenDTU geflasht haben willst.

[Daniel (da_ba)]

Was ist denn der Unterschied zwischen OpenDTU und Ahoy?

Ich lese zwar schon eine Zeit lang mit aber hab dazu den Faden verloren.

[Helmut H. (der_andere)]

https://github.com/tbnobody/OpenDTU
https://github.com/lumapu/ahoy
Ist Geschmacksache, Web-Ansicht, MQTT Ausgabe usw.

[Giuseppe M. (drdigital)]

Daniel schrieb:
> Was ist denn der Unterschied zwischen OpenDTU und Ahoy?
Der wesentliche Unterschied ist,
dass OpenDTU nur auf dem ESP32 läuft.
Ahoy gibt es Version für ESP8266 und ESP32.
Zudem kann Ahoy Limit im Wechselrichter setzen.
OpenDTU kann das noch nicht.

[Daniel (da_ba)]

Ah ok, danke!

[Helmut H. (der_andere)]

Hier die MQTT Topic zum Steuern des ESP32 mit OpenDTU, das liest sich 
so, dass steuern möglich ist:
https://github.com/tbnobody/OpenDTU/blob/master/docs/MQTT_Topics.md

[Giuseppe M. (drdigital)]

Helmut H. schrieb:
> Hier die MQTT Topic zum Steuern des ESP32 mit OpenDTU, das liest sich
> so, dass steuern möglich ist:
Hallo Helmut,
ja, sieht wirklich so aus, als ob nun Limit setzen mit OpenDTU 
funktioniert.
Vor einigen Wochen, war das Limit setzen für mich der Grund von OpenDTU 
auf Ahoy zu wechseln.
Ich werde OpenDTU nun mal wieder testen, weil es lief immer sehr Stabil.
Wenn es wirklich funktioniert, dann kann ich nun endlich den Olimex 
ESP32-POE verwenden.
Mit Ahoy hatte ich anfangs Probleme mit einem Wemos D1 mini.
Als dann endlich ESP32 support für Ahoy kam, bin ich auf ESP32 
gewechselt und seither läuft Ahoy stabil bei mir.

Gruß
Giuseppe

[SolMate (Gast)]

Hallo zusammen,

sehe ich das eigentlich richtig, dass es keinerlei Authentifizierung 
zwischen DTU und WR gibt?
Das heißt jeder der die Kommunikation zwischen DTU und WR mithören kann, 
kann sich auch selbst als DTU ausgeben und zum Beispiel den WR 
ausschalten?!

Gruß,
solmate

[Rene M. (Firma: Bitte wählen) (renmo)]

Dazu muss dieser jemand die Seriennummer des Wechselrichters wissen.

Und was hätte dieser jemand von dem Ganzen?

[Giuseppe M. (drdigital)]

Die Funk Reichweite der Wechselrichter ist relativ begrenzt,
also müsste ein potentieller Angreifer auch in der Nähe sein und wie 
schon geschrieben die Seriennummer des Wechselrichters kennen.

Meine persönliche Meinung dazu ist, dass sich Angreifer nur mühe machen, 
wo es sich lohnt. Bei einem kleinen Balkonkraftwerk, sehe ich keinen 
finanziellen Anreiz sich damit in boshafter Absicht zu beschäftigen.

[Christoph (Gast)]

N'abend zusammen,
bessteht Hoffnung auf einen Support der HMS Serie?

[Grisu (krisu)]

Warum nicht dort fragen wo's hingehört?
Beitrag "Re: Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"

[Isnoahoy (Gast)]

Wir suchen noch Nutzer eines HM-350 oder HM-1000 die mal ihre PN / Part 
Number auslesen und zur Verfügung stellen.

Die Informationen bitte ins OpenDTU Github oder im Discord Chat 
#opendtu-esp32:
https://github.com/tbnobody/OpenDTU/issues/35

Laut der Serial Number Liste und Wortmeldungen hier im Forum sind dies

HM-350:
Martin P. (mpolak77) 1121 72xxxxxx
Herbert K. (avr-herbi)
franz (Gast)
Kev (Gast) TSUN TSOL-M350

Für den HM-1000 habe ich hier keine Wortmeldungen / Besitzer gefunden. 
Also wer ein noch unbekanntes HM- oder TSUN-Modell hat und die 
Information aus OpenDTU auslesen kann wären wir dankbar.

[Herbert K. (avr-herbi)]

Isnoahoy schrieb:
> Wir suchen noch Nutzer eines HM-350 oder HM-1000 die mal ihre PN / Part
> Number auslesen und zur Verfügung stellen.
>
> Die Informationen bitte ins OpenDTU Github oder im Discord Chat
> #opendtu-esp32:
> https://github.com/tbnobody/OpenDTU/issues/35
>
> Laut der Serial Number Liste und Wortmeldungen hier im Forum sind dies
>
> HM-350:
> Herbert K. (avr-herbi)
Hallo, HM-350 hab ich.
Ich hatte die Uralte SW am laufen auf ESP-8266 bis ich irgendwann kaum 
noch Antworten bekommen habe. Hab seit dem in der Richtung nix mehr 
unternommen, da der Code ja auch von der Arduino Umgebung auf platformio 
umgestellt wurde und ich auch kein "C" kann.
Habe auch schon eine ganze Zeit nicht mehr mitgelesen und kenne die 
aktuellen Fortschritte nicht.
ESP-32 hätte ich. HM-350 könnte ich im Prinzip testen. HM-400 könnte ich 
gegenchecken, falls nötig.
Müsste mir nur mal jemand kurz schreiben, was ich tun soll. Dann könnte 
ich das evt. am Wochenende mal versuchen.

[John P. (brushlesspower)]

vielleicht etwas offtopic

hat jemand einen Hoymiles als Batterie Wechselrichter in Benutzung mit 
Limit?

Meine Idee ist es einen HM-WR zu nehmen, auf 50W limitieren und an der 
Batterie laufen zu lassen für Nachteinspeisung.

[Palatinum (Gast)]

Dir fehlt das Grundverständnis der Funktion des WR

[John P. (brushlesspower)]

Palatinum schrieb:
> Dir fehlt das Grundverständnis der Funktion des WR

Danke für die Erklärung

[Helmut H. (der_andere)]

@NichtKohlebürstenpower
Schätze er meint, dass das nicht geht, weil die Dinger Netz als Führung 
brauchen, bzw mit nur 'ner Batterie nicht starten werden.

[John P. (brushlesspower)]

Helmut H. schrieb:
> Schätze er meint, dass das nicht geht, weil die Dinger Netz als Führung
> brauchen, bzw mit nur 'ner Batterie nicht starten werden.

Wenn er das meint, hat er nicht korrekt gelesen.

Das Problem mit "normalen einspeise WR" ist der MPPT. Mit Batterie läuft 
dieser an das Maximum da die Batterie sehr niederohmig ist.

Die Frage ist, ob der HM dies entsprechend sauber begrenzt auf das 
eingestellte Limit? Bzw. ob das schon jemand versucht hat oder so 
betreibt.

[Herbert K. (avr-herbi)]

> Die Frage ist, ob der HM dies entsprechend sauber begrenzt auf das
> eingestellte Limit? Bzw. ob das schon jemand versucht hat oder so
> betreibt.
Im Photovoltaik Forum mal lesen/suchen.
Bei youtube gibt es auch einige Videos dazu.
Die Batt./Akku muss halt im MPPT Bereich vom Inverter liegen. Mit 12V 
dürfte das so einfach nicht klappen. Eher ein vielfaches von 12V.

Alternative: 12V Batt und preisgünstigen WR der 50 W kann und dann die 
Geräte da reinstecken, wenn möglich. Macht nicht immer Sinn, manchmal 
aber schon. Ich kenne die Randbedingungen ja nicht. Ich hoffe, das hilft 
ein wenig weiter.

[Hinz (Gast)]

Mit Batterie läuft dieser an das Maximum da die Batterie sehr 
niederohmig ist.


Völliger Stuss!

[VFR-Reiter (Gast)]

John P. schrieb:
> vielleicht etwas offtopic
>
> hat jemand einen Hoymiles als Batterie Wechselrichter in Benutzung mit
> Limit?
>
> Meine Idee ist es einen HM-WR zu nehmen, auf 50W limitieren und an der
> Batterie laufen zu lassen für Nachteinspeisung.

Hallo zusammen,

zuerst einmal möchte ich meinen Hut vor dem ziehen, was Ihr hier auf die 
Beine gestellt habt.

Um mal auf das Thema Nachteinspeisung einzugehen, muss ich etwas weiter 
ausholen. Hoffentlich nicht zu weit, ansonsten bitte durch die 
Moderation verschieben.
Momentan betreibe ich einen HM-400, um unter der 600W-Grenze zu bleiben, 
aber eine Erweiterung auf 3 HM-1500 ist schon im Gange. Daher hatte ich 
mit einem Kollegen auch schon darüber diskutiert, den HM-400 dann als 
Batteriewechselrichter zu 'missbrauchen'. Dies vor dem Hintergrund, dass 
die Batteriekompatibilität der Hybridwechselrichter doch seeeehhr 
eingeschränkt ist und wir über eine AC-gekoppelte Lösung sinniert haben, 
um beliebige 48V-Akkus nutzen zu können.
Da eine Leistungsregelung mit den HMs mittlerweile möglich ist, könnte 
man das Ganze mit einer Leistungsmessung am Hausanschluss (eigenes 
Smartmeter mit MQTT oder MQTT-Rüssel am Stromzähler) kombinieren, um 
eine Nulleinspeisung bei Akkubetrieb zu erzielen, schließlich möchte man 
mit dem Akku nicht das Stromnetz füttern.

Bevor jetzt geantwortet wird, dass das ja so nicht gehen würde, folgende 
Gedanken:
- der HM-400 hat momentan ca. 770W installiert PV-Generatorleistung zur 
Verfügung (2x JAMS60S20-385 parallel). Leistungsmessung erfolgt mit AVM 
DECT 210, dort sieht man dann sehr gut, dass der HM400 auch sauber bei 
400W abregelt.
- dass der Betrieb mit einer anderen DC-Quelle als PV-Modulen an den 
PV-Anschlüssen möglich ist, haben einige Mitforisten erfolgreich 
demonstriert, in dem sie ihre HMs nachts mit einem Labornetzteil 
betrieben haben, daher sehe ich wenig Gründe, weshalb ein Akku nicht 
auch als DC-Quelle dienen könnte

Viele Grüße

[Martin P. (mpolak77)]

Was ihr diskutiert beschrieben schon ein paar Leute in ihren YouTube 
Kanälen.

ZB https://youtu.be/yOcoux9IbzM

Und das scheint auch brauchbar zu funktionieren.

[Joe G. (feinmechaniker)]

Ein wunderbares Projekt – klasse Leistung!
Nach meinem Steckbrettaufbau habe ich mir das Layout von Ahoy! 
vorgenommen und etwas geändert. Die Gundschaltung ist natürlich 
unverändert! Ich würde in der nächsten Woche (wenn es keine Änderungen 
mehr gibt) bei Aisler Platinen bestellen (3.18€ Stück). Wenn noch jemand 
Ideen hat oder sich ranhängen will kurze PM an mich.

[Thomas K. (mikroc_baer)]

Ich habe vermutlich erst 50% des Threads 'geschafft', eventuell ist 
meine Frage/Anmerkung schon beantwortet – ich bitte dies zu 
entschuldigen…

Ist das Channel-Hopping 'Problem' gelöst? Mein Eindruck ist, das die 
verwendeten nRF-Module eben keine 'P' Versionen sind. Und nur die 
nRF24L01P scheinen das automatische Frequency-Hopping zu unterstützen 
und bei der Verwendung dieser Module ist dann auch kein entsprechender 
programmatischer Aufwand notwendig.

Oder liege ich völlig falsch?

[Thomas K. (mikroc_baer)]

VFR-Reiter schrieb:

> - dass der Betrieb mit einer anderen DC-Quelle als PV-Modulen an den
> PV-Anschlüssen möglich ist, haben einige Mitforisten erfolgreich
> demonstriert, in dem sie ihre HMs nachts mit einem Labornetzteil
> betrieben haben, daher sehe ich wenig Gründe, weshalb ein Akku nicht
> auch als DC-Quelle dienen könnte

Gibt es Links zu diesem Thema auf entsprechende Threads? Ich wollte an 
einem 16S LiFePO4 Akku ein DPM8624 als eine einstellbare Stromquelle 
(via  RS-485 Interface) nutzen um 3 parallele HM-400 anzusteuern. Gibt 
es zu so einem Ansatz eine Diskussion hier im Forum oder Link-Tips 
außerhalb?

Vielen Dank
thomas

[Richard K. (laserrichi)]

excel bitte noch Ergänzen
MI-600 mit 104161609005

[Pavel (pali)]

VFR-Reiter schrieb:
> ... könnte man das Ganze mit einer Leistungsmessung am Hausanschluss
> (eigenes Smartmeter mit MQTT oder MQTT-Rüssel am Stromzähler)
> kombinieren, um eine Nulleinspeisung bei Akkubetrieb zu erzielen ...

Genau das ist auch mein Ziel.
Nulleinspeisung realisieren mit einem HM300 (oder auch 2 parallel) , der 
an einen 48V Akku angeschlossen wird und durch DTU die benötigte 
Leistung reguliert wird.
Die Einspeisung funktioniert definitiv. Auch das manuelle Limitierung 
der Leistung durch AhoyDTU.
 Frage ist, ob die automatische Leistung-Regulierung auch möglich ist.
Wenn jemand das schafft, stabile Nulleinspeisung mit DTU zu realisieren, 
dann wäre das wahrscheinlich die einfachste Lösung dafür (für mich auf 
jeden Fall).
Schon mal vielen Dank im Voraus dafür, weil ich fest daran glaube, dass 
es möglich ist 😀
Meine Programmierkentnisse sind dafür leider zu schwach.

[Tobias (Gast)]

Ich habe für meine Familie und einen Freund auch insgesamt vier Module 
aufgebaut und heute noch ein Gehäuse dafür gelasert. Danke für das 
Projekt, es funktioniert bei allen Invertern bestens (1x HM 600, 2x HM 
800, 1x HM 1500).

[Herbert K. (avr-herbi)]

Tobias schrieb:
...und heute noch ein Gehäuse dafür gelasert. Danke für das

Cool das Gehäuse !  Sehr schön gemacht !

[Grisu (krisu)]

Ich hab eine alte Streichholzschachtel genommen, der ESP8266 mit 
Nordic-Modul paßt fast exakt hinein. Natürlich ohne externe Antenne, nur 
auf einer Seite den Einlaß fürs Kabel ausgeschnitten und das ganze 
einfach mit Isolierband umwickelt.
Vollkommen ausreichend für den (meinen) Zweck.

[IngoEF (Gast)]

Moin aus dem momentan sonnigen Hamburg.

klasse, hier werden richtig spannende Dinge veranstaltet und auch ich 
zähle mich zu den Leuten, die nicht gerne wild rumfunkende Geräte im 
Haus haben ohne zu wissen, was die denn tatsächlich tun.
Seit ein paar Tagen steht mein Balkonkraftwerk am Wohnzimmerfenster und 
läuft im Testbetrieb; leider ohne dass ich -außer einer grün blinkenden 
Leuchtdiode- auch nur die geringste weitere Information über 
Zustand/Arbeit der Anlage erhalte.
Als WR wurde ein TSOL-M800(DE) von TSUN ohne DTU mitgeliefert. Rein 
äußerlich sieht der den ungefähr gleich dimensionierten Hoymiles sehr 
ähnlich und die entsprechende Suche zeigte diesen Beitrag.
Den Seriennummernbeginn 1141 kann ich bestätigen.
RaspiPi habe ich, Linux kann ich, aus Programmieren bin ich als 
inzwischen "nur noch Administrator" -von Shellssripten abgesehen- 
absolut raus, denke aber wieder reinkommen zu können.

Ist denn inzwischen raus, dass mit der hier erarbeiteten Lösung auch die 
TSOLs befragt werden können (und auch antworten?

LG - Ingo

[Heinz R. (heijz)]

Pavel schrieb:
> Frage ist, ob die automatische Leistung-Regulierung auch möglich ist.
> Wenn jemand das schafft, stabile Nulleinspeisung mit DTU zu realisieren,
> dann wäre das wahrscheinlich die einfachste Lösung dafür (für mich auf
> jeden Fall).

Das funktioniert generell nicht, bzw machen auch die Profi-Systeme wie 
Victron nicht so

Alle Systeme eiern immer um den Nullpunkt rum, da wird nichts im 
ms-Bereich geregelt

In der Regel stelt man das dann so ein das immer ein bsichen Strom aus 
dem Netz gezogen wird, z.B. 30W
Man gibt ihm alle 1-3 Sekunden einen neuen Wert
Der Inverter eiert dann in dem Beispiel zwischen ca. 50W Bezug und 10W 
verschenkt rum, das spielt aber finanziell fast keine Rolle

Große Lasten wie Herd müssen eh aus dem Netz kommen

Anbei ein Screenshot eines Victron

[Heinz R. (heijz)]

--> an die Mods und OT:

Würde es nicht mal Sinn machen hier eine 2. Seite zu eröffnen?
Immer den ganzen Mega-Thread zu laden ist nervig

[Günter H. (gnter_h534)]

... mit eingeschalteter Seitenaufteilung läuft das auch bei diesem 
Thread ganz entspannt.

Zum Suchen im gesamten Thread - dann natürlich die Seitenaufteilung 
abgeschaltet - ist ein Thread günstiger.

[Heinz R. (heijz)]

Günter H. schrieb:
> ... mit eingeschalteter Seitenaufteilung läuft das auch bei diesem
> Thread ganz entspannt.
>
> Zum Suchen im gesamten Thread - dann natürlich die Seitenaufteilung
> abgeschaltet - ist ein Thread günstiger.

Danke, das Feature kannte ich noch nicht

[Pavel (pali)]

Heinz R. schrieb:
> In der Regel stelt man das dann so ein das immer ein bsichen Strom aus
> dem Netz gezogen wird, z.B. 30W
> Man gibt ihm alle 1-3 Sekunden einen neuen Wert
> Der Inverter eiert dann in dem Beispiel zwischen ca. 50W Bezug und 10W
> verschenkt rum

... so habe ich mir das auch ungefähr vorgestellt. Dass es nicht genau 
Null hält, ist klar.
Das reicht vollkommen.
Nur bräuchte ich am besten ein Beispiel-Regelungprogramm im Raspberry, 
was ich dann "analysieren " könnte um das ganze auch verstehen. Und auf 
meine Situation anpassen.

[Heinz R. (heijz)]

Hast DU denn überhaupt die aktuellen Zählerwerte zur Verfügung?  Wie 
liegen diese vor?

[Pavel (pali)]

Ich bin momentan gaaanz am Anfang der Planung. PV Anlage läuft seit fast 
einem Jahr. Jetzt möchte ich Akku nachrüsten.
Leistungsmeter habe ich noch nicht, werde aber Shelly EM einbauen.
Von meinem 2R-Zähler weiss ich aber jetzt schon, dass ich nur ca. 50% 
der erzeugten Energie ausnutze. Deswegen suche ich eine, für mich 
machbare Lösung für "Nulleinspeisung ".
Und Hoymiles DTU sieht als sehr gut geeignet aus.
Meine Vorstellung:
  Raspberry liest die auktuellen Zählerwerte regelmäßig aus und sendet 
and DTU die gewünschte Maximalleistung, die man im Moment braucht .... 
sollte mMn. funktionieren.

[Grisu (krisu)]

Wenn du eine sehr gute und stabile Verbindung zum WR hinbekommst könnte 
es hinlänglich gut funktionieren.
Die Begrenzung selbst in Watt funktioniert bei mir sehr gut.
Problem sind halt schnelle und sehr hohe Lastwechsel, schaltest den 
E-Herd aus sind gleich mal 1-3kW plötzlich zuviel Einspeisung, bis du 
die wieder runtergeregelt bekommst vergehen Minuten.

[Heinz R. (heijz)]

Pavel schrieb:
> Leistungsmeter habe ich noch nicht, werde aber Shelly EM einbauen.

warum nicht einfach den vorhandenen Zähler per SML auslesen?

Grisu schrieb:
> Problem sind halt schnelle und sehr hohe Lastwechsel, schaltest den
> E-Herd aus sind gleich mal 1-3kW plötzlich zuviel Einspeisung

Das ist sehr einfach zu lösen -  die generelle maximale Einspeisung z.B. 
auf 500W begrenzen

Es geht ja nicht darum jede Spitze abzufangen, viel interessanter ist 
das der AKku die ganze Nacht durch hält

[Sorbit (Gast)]

Tobias schrieb:
...und heute noch ein Gehäuse dafür gelasert. Danke für das



Welche Hardware nutzt Du dazu?

[Tobias K. (reserve)]

Sorbit schrieb:
> Welche Hardware nutzt Du dazu?

Einen Sculpfun S10 und eine 3mm HDF Platte.
Gruß Tobias

[Christian F. (christian_f744)]

Hallo zusammen!

Ich hab mir gerade das Bundle fertiggestellt und über PlatformIO 
geflasht. Dort meine WLAN-Daten eingetragen, die maximale Anzahl an 
Invertern auf 10 geändert und ich komm auch auf die Startseite.

Aber sobald ich den Punkt "Setup" aufrufen möchte, verliert der ESP8266 
die Verbindung zu meinem WLAN und öffnet den eigenen Access Point. Wenn 
ich über den AccessPoint vom ESP8266 verbunden bin, verliert er auch 
hier wieder die verbindung, sobald ich auf Setup in der Weboberfläche 
klicke.

Ist das Verhalten jemandem bekannt und hat eine Lösungß

Danke, LG
Christian

[Joe G. (feinmechaniker)]

Da es mehrere Fragen zur Schaltung und zur Leiterplatte des 
Hardwareinterface zum Hoymiles gibt hier kurz eine Antwort:

Im Angang der Schaltplan für das WeMos D1 mini  Modul und das Wireless 
2.4GHz Funk Modul (nRF24L01+).
Alle ESP8266 I/Os werden mit 3,3V betrieben und sind nicht 5V-tolerant! 
D.h. die rausgeführten Schnittstellen I2C und UART dürfen auch nur mit 
3.3V betrieben werden.
An der Klemme K3 können extern 5V eingespeist werden.

Wenn ein Satz erfolgreich bestückt ist (nächste Woche) stelle ich die 
CAD-Daten hier zur Verfügung. Da ich mit dem System EAGLE arbeite, nur 
als *.BRD und *.SCH. Die Board-Daten kann ich auch als Gerber-Daten 
exportieren. Weiterhin stelle ich die Fertigungsdaten (derzeit Version 
1.0) frei bei AISLER [1] rein, damit jeder bei Bedarf Platinen selbst 
ordern kann.
Die erste Charge an Leiterplatten hatte ich schon letzten Sonntag 
bestellt, so dass derzeit keine LP’s mehr vorhanden sind. Diejenigen die 
LP’s erhalten, habe ich über E-Mail informiert.

[1] https://aisler.net/p/EAYHGSED

[planlos (Gast)]

wenn die 3v und die 5v reingehen, dann sollte der Pfeil im Schaltplan 
auch nach innen zeigen?

[Weihnachtsmann (Gast)]

Auf Seite 12 hat der Nikolaus eine Frage zum MQTT gestellt.

Ich stehe vor dem selben Problem mit Ahoy.

Ich bekomme per MQTT einfach keine Verbindung zu Homeassistant soweit 
habe ich alles installiert (Mosquitto broker) für Ahoy habe ich es 
einmal mit der normalen Homeassistant IP versucht und einmal einen 
mqtt-user angelegt aber es taucht einfach nicht auf.

Hat jemand eine Idee warum? Hab da wirklich mehr als 5 Stunden intensiv 
versucht....
Versucht habe ich es mit 0.5.15 und jetzt 0.5.17...

[Grisu (krisu)]

planlos schrieb:
> wenn die 3v und die 5v reingehen, dann sollte der Pfeil im Schaltplan
> auch nach innen zeigen?

Dazu fällt mir wirklich nur dein Nickname ein ... - nomen es omen?!?

[Grisu (krisu)]

planlos schrieb:
> wenn die 3v und die 5v reingehen, dann sollte der Pfeil im Schaltplan
> auch nach innen zeigen?

Dazu fällt mir wirklich nur dein Nickname ein ... - nomen es omen?!?
Elektronik und deren Schaltpläne sind dir offensichtlich ein spanisches 
Dorf.

[sehe ich auch so (Gast)]

Grisu schrieb:
> Dazu fällt mir wirklich nur dein Nickname ein ... - nomen es omen?!?

das mit den Pfeilrichtungen sehe ich genau so...

Erklär mal welche DIN/ISO oder was auch immer das beschreibt.

Und wenn da Spannung raus kommt geht der Pfeil in die Quelle?

Sehr logisch

[Grisu (krisu)]

So wie man bei der Masse einen dicken Querstrich macht ist es der Pfeil 
bei den Versorgungsspannungen. Hab ich nie anders gemacht und auch nie 
anders gelernt (ok ist schon einige Jahre her).

Bei der Masse oder Erdung (3 Striche) ist dir die Richtung in die der 
Strom fließt oder wo diese schaltungs- und aufbautechnisch realisiert 
ist auch egal.
Es heißt nicht mehr und nicht weniger als dort geht's zu einer Spannung 
und alle "Pfeile" mit dem selben Wert kann man sich als miteinander 
verbunden vorstellen, um sie nicht einzeln mit vielen Strichen 
einzeichnen zu müssen.

[Christian F. (christian_f744)]

Christian F. schrieb:
> Hallo zusammen!
>
> Ich hab mir gerade das Bundle fertiggestellt und über PlatformIO
> geflasht. Dort meine WLAN-Daten eingetragen, die maximale Anzahl an
> Invertern auf 10 geändert und ich komm auch auf die Startseite.
>
> Aber sobald ich den Punkt "Setup" aufrufen möchte, verliert der ESP8266
> die Verbindung zu meinem WLAN und öffnet den eigenen Access Point. Wenn
> ich über den AccessPoint vom ESP8266 verbunden bin, verliert er auch
> hier wieder die verbindung, sobald ich auf Setup in der Weboberfläche
> klicke.
>
> Ist das Verhalten jemandem bekannt und hat eine Lösungß
> r
> Danke, LG
> Christian

Guten Morgen.

Ich bin jetzt mal draufgekommen, woran es liegt -> ich hab die max. 
Inverteranzahl auf 5 erhöht. Senk ich sie wieder auf 3, lädt das Setup. 
Andernfalls restartet der ESP8266.

Ist das ein Bug, oder mach ich was falsch dabei?

Danke, LG
Christian

[rolf (Gast)]

Hallo zusammen,
kurze Rückmeldung:
D1-Mini aus Vorrat      =>check
4pcs NRF24L01+ bestellt =>check
(https://www.amazon.de/gp/product/B07XYYXVFF)

Das ganze auf Experimentierplatine zusammengelötet, checcken
                         =>check
flashen mit Tasmonizer   =>check
Hoymile Modul ab/anbauen
für Seriennummer :-(     =>check
Eingabe der Infos auf Webseite
                         =>check
2 Minuten warten...      =>endlos

LÄUFT!!!
Einbinden in FHEM        =>check

Der SONOFF SP111 ist schon in der Kramkiste verschwunden, den Hoymiles 
Werten vertraue ich eher!

Grandiose Arbeit! Vielen Dank!
Rolf

[fx2 (Gast)]

/setup anwählen .... Es wird der AP geöffnet.
...das ist ein Absturz (sieht man im aerial log). Er lädt sich Werte aus 
dem eeprom, die Müll sind. Wenn du den Flash mal komplett löschst sollte 
es auch gehen. Ich schätze mal mit der geplanten Umstellung auf 
Filesystem hat sich der bug erledigt.
PS: Der bug kommt auch zu Tage, wenn der geflashte Code (viel) größer 
wird. Das hatte ich, durch eine Erweiterung um das Nokia5110 Display 
auch.

[rolf (Gast)]

also:
Nur zur Klarstellung, da ich nicht sicher bin, ob ich verständlich war!

Wollte nicht MEINE Leistung in den Vordergrund stellen, sondern 
darstellen, dass die Installation problemlos und straight forward 
einfach nur einwandfrei funktioniert hat! Das bin ich von anderen (oder 
eigenen) Projekten wahrlich nicht gewohnt!

Also noch einmal:
Grandiose Arbeit von allen die hier einfach nur super gemeinsam einen 
Aspekt nach dem anderen identifiziert und enträtselt haben!!!

[fx2 (Gast)]

@rolf: da musst du keine Angst haben. Ich schliesse mich dem Dank an und 
finde es auch ne echt gute Leistung.

Das mit dem bug bezog sich auf den Beitrag von Christian. Ich wollte nur 
n tip geben, wie man da rauskommt. (1malig an die URL ein /erase 
anhängen). Die Änderung auf 5 Inverter war ein Zufallstreffer von ihm. 
.... Obwohl - Hauptsache es geht jetzt.

Nochmal @rolf: Ich finde die Idee mit dem Solardach über dem Aufgang 
cool.

[Christian F. (christian_f744)]

fx2 schrieb:
> /setup anwählen .... Es wird der AP geöffnet.
> ...das ist ein Absturz (sieht man im aerial log). Er lädt sich Werte aus
> dem eeprom, die Müll sind. Wenn du den Flash mal komplett löschst sollte
> es auch gehen. Ich schätze mal mit der geplanten Umstellung auf
> Filesystem hat sich der bug erledigt.
> PS: Der bug kommt auch zu Tage, wenn der geflashte Code (viel) größer
> wird. Das hatte ich, durch eine Erweiterung um das Nokia5110 Display
> auch.

Danke für den Tipp. Jetzt habe ich keinen Absturz mehr. Dafür hab ich 
aber keine Möglichkeit mehr, die Wechselrichter einzutragen. Mit 3 
möglichen Invertern sind die Eingabefelder hier. Wenn ich auf höher als 
3 stelle, sind die Eingabefelder weg :(.

Danke, LG
Christian

[Ingo (blueskying)]

Well, fuer diejenigen, die an einer Loesung mit 'Nulleinspeisung' 
interessiert sind, ich kann sagen, dass sich so ein System sehr gut mit 
Modul-WR realisieren laesst. Ich habe das letztes Jahr mit einem 
kleineren, aelteren WR umgesetzt und es laeuft seither stabil und 
zuverlaessig.

Vorab aber ein grosses Dankeschoen an all die Entwickler dieses 
Projektes, alle Achtung was da entstanden ist. Von Anfang an habe ich 
gehofft, dass mit der Analyse der Hoymiles-WR ein 'Nulleinspeisesystem' 
moeglich werden wird, und als vor ca. 3 Monaten die Leistungsregelung 
erstmals funktionierte, da habe ich mir dann auch ein ESP und NRF+ Modul 
zugelegt. Ging erstaunlich schnell, bis ich meine  Daten vom HM350 
einlesen, in FHEM darstellen und die Leistung des WR variieren konnte.

Zurueck zu dem 'Nulleinspeisesystem'. Ich habe mir zuerst so ein 
sogenanntes Solar-BKW mit zwei Solarpanels und einem Modul-WR zugelegt 
und angemeldet. Als zweiten Schritt habe ich dann einen elektronischen 
Energiezaehler hinter dem Hauptzaehler meines E-Anschlusses ergaenzt. 
Der Energiezaehler basiert und auf folgendem Projekt:
weberblog.net/stromzahler-mit-s0-schnittstelle-vom-raspberry-pi-auswerte 
n.
Allerdings habe ich den Zaehler mit S0-Schnittstelle durch einen Eastron 
SDM230 ersetzt. Damit bekomme ich ueber Modbus schnell alle moeglichen 
Daten zum aktuellen Stromverbrauch und die Software erstellt mir 
Diagramme mit dem Lastprofil der gesamten Hausanschluss. Gerade diese 
Lastprofile sind wesentlich, um ein sinnvolles System fuer die 
Optimierung des Eigenverbrauchs zu konzipieren.

Zur gleichen Zeit hatte ich schon mit Li-Akku's, die ich gebraucht von 
alten E-Autos bekommen habe, experimentiert. Die Akku's habe ich 
umkonfiguriert (7S) und  fuer die Sicherheit mit jeweils eigenen BMS 
ausgestattet. Damit haben die Akkus aehnliche Spannungs-Level wie ein 
traditioneller 24V-Akku und ich kann sie ueber einen 
Victron-BlueSolarCharger laden (natuerlich muss auch die Konfiguration 
des Victron angepasst werden).

Zu der eigentlichen Steuerung fuer die Optimierung des Eigenverbrauchs: 
mit meinen zwei Solarpanelen kann ich sowieso nicht meinen gesamten 
Stromverbrauch abdecken. Also braucht auch meine Steuerung erst einmal 
nicht allzu exakt sein. Vielmehr geht es darum, die tagsueber 
ueberschuessig produzierte Solarenergie in die Akkus zu laden und dann 
abends/ueber Nacht von einem gesteuerten Modul-WR den Stromverbrauch 
abhaengig vom Wert des Energiezaehlers und dem Akku-Ladezustand so weit 
als moeglich zu kompensieren.

Um dies zu erreichen, habe ich von meiner Solaranlage eines der Panele 
abgeklemmt und lade damit tagsueber die Akkus. Lediglich das andere 
Solarpanel speist tagsueber via den WR direkt ein.
Auf einem Raspi laeuft eine kleine Steuerungssoftware, die erkennt, wenn 
abends nichts mehr von meiner Solaranlage geliefert wird. Dann schaltet 
sie abhaengig vom Ladezustand der Akkus den gesteuerten WR ein und 
erhoeht/reduziert die Leistung des WR im 5-Minutentakt je nach aktuellem 
Verbrauch des Energiezaehlers. Das Nachregeln erfolgt grob in 
50W-Schritten, so dass ich moeglichst um einen 0-Verbrauch an meinem 
Hauszaehler herumpendele. Das ganze System ist zwar in kontinuierlicher 
Weiterentwicklung, funktioniert aber mittlerweile stabil. In der 
Zwischenzeit hat das System bewiesen, dass ich damit einen Grossteil der 
sonst fuer mich nutzlos eingespeisten Energie in Eigenverbrauch 
'umlenken' kann. Und da alles modular gestaltet ist, laesst es sich in 
vielerlei Weise variieren bzw. skalieren.

Die naechsten Schritte sind nun, das Konzept/Software auf den 
Hoymiles-WR  umzustellen. Dazu muessen vor allem die 
Kommunikations-Routinen zum WR programmiert werden, ich nutze dazu die 
mqqt-Kommandos. Der Rest duerfte weitgehend gleich bleiben, hoffe in den 
naechsten Wochen eine erste experimentelle Version zum Laufen zu 
bringen.

[Thomas (Gast)]

hast du es mit dem Mqtt Explorer mal überprüft, ich hatte es über 
Homeassistant stabil am laufen mit der 0.5.15 bevor mein Raspi 4 
abgestürzt war SD Card defekt, es geht nur mit einem angelegten 
mqtt-user

[Thomas (Gast)]

Weihnachtsmann schrieb:
> Auf Seite 12 hat der Nikolaus eine Frage zum MQTT gestellt.
>
> Ich stehe vor dem selben Problem mit Ahoy.
>
> Ich bekomme per MQTT einfach keine Verbindung zu Homeassistant soweit
> habe ich alles installiert (Mosquitto broker) für Ahoy habe ich es
> einmal mit der normalen Homeassistant IP versucht und einmal einen
> mqtt-user angelegt aber es taucht einfach nicht auf.
>
> Hat jemand eine Idee warum? Hab da wirklich mehr als 5 Stunden intensiv
> versucht....
> Versucht habe ich es mit 0.5.15 und jetzt 0.5.17...

hast du es mit dem Mqtt Explorer mal überprüft, ich hatte es über
Homeassistant stabil am laufen mit der 0.5.15 bevor mein Raspi 4
abgestürzt war SD Card defekt, es geht nur mit einem angelegten
mqtt-Benutzer

[Grisu (krisu)]

Vielleicht mal mit anderem User ohne Leerzeichen versuchen und auch 
sonst keine Besonderheiten veranstalten.

[Ha F. (harry_f)]

So hier mal mein bescheidener Beitrag zu diesem geilen Projekt DTU AHOY.

Für alle die ein VENUS OS auf einem Raspi laufen haben, hier ein 
Python-Script
dass die Daten vom DTU-AHOY per JSON ausliest und an den DBUS 
weitergibt.

Alles nach \data\dbus-dtu-ahoy\ kopieren, die config.ini bearbeiten und 
./install.sh ausführen.

Das soll hier alles als Vorlage dienen!

Im Moment nur für einen WR etc pp...
Bei mir im Einsatz ein HM-600.

PS: darf jemand dem GIT hinzufügen.

[Dirk (pip3000)]

Danke. Klingt toll. Genau sowas such ich gerade. Werde ich baldmöglichst 
mal ausprobieren.
Hast du das auch in einem git-Repo? Wäre vielleicht hilfreich.

[hans (Gast)]

Hallo zusammen,

vielen Dank für das tolle Projekt. Ich hab eine kurze Frage.

Ich habe alles nach dieser Anleitung gemacht:
https://github.com/lumapu/ahoy/blob/main/tools/esp8266/README.md#things-needed

Using a ready-to-flash binary using nodemcu-pyflasher
Diese Datei geflashed: 220906_ahoy_0.5.17_esp8266_5402e9b.bin

Das Setup hat super funktioniert, nun wird aber diese Meldung angezeigt, 
dass die Verbindung zum Nordic nicht geht:

WARNING! your NRF24 module can't be reached, check the wiring and pinout (setup)

Ich habe ein Wemos D1 mini mit dem Nordic verdrahtet. Auf dem Nordic 
Chip sehe ich auch das "+": 24L01+

Habe ich die richtige Datei geflashed für diese Verdrahtung?

[Alexander H. (agentsmith1612)]

Das ist ein mega tolles Projekt und ich habe natürlich die DTU schon 
gebaut.

Ich habe zu meiner Frage keine direkte Antwort gefunden, deswegen frag 
ich nochmal.
Kann man mehr als 3 Wechselrichter anbinden?
Ich plane nämlich 6x 1500 zu nutzen.


Falls nicht ist nicht schlimm dann installier ich noch eine, ist nicht 
perfekt aber ein einfacher Workaround.

Besten Dank

hans schrieb:
> Das Setup hat super funktioniert, nun wird aber diese Meldung angezeigt,
> dass die Verbindung zum Nordic nicht geht:
>

WARNING! your NRF24 module can't be reached, check the wiring and 
> pinout (setup)

>
> Ich habe ein Wemos D1 mini mit dem Nordic verdrahtet. Auf dem Nordic
> Chip sehe ich auch das "+": 24L01+
>
> Habe ich die richtige Datei geflashed für diese Verdrahtung?

Ich habe davon gelesen das teilweise NF24L01+ Fälschungen verkauft 
werden. Da werden NF24L01 Chips genommen die dann umgelabelt werden als 
NF24L01+ und verkauft, kann das eine Ursache sein?

[hans (Gast)]

Danke für die Antwort. Auf der Setup Page müssen folgende Pins noch 
angegeben werden, jetzt ist die Fehlermeldung weg

    CS (Chip Select),
    CE (Chip Enable) and
    IRQ (Interrupt)

Jetzt versuche ich die Verbindung zum Inverter zu bekommen. Bei Adresse 
die 12 stellige Seriennummer eingetragen und als Name HM600. Noch 
bekomme ich keine Antwort. Ich setz das Modul mal direkt neben den 
Inverter...

[hans (Gast)]

Weiß jemand die Einstellungen der Serial Console? Das müßte ja auf der 
Seriellen Schnittstelle des VCP vom Wemos funktionieren, oder wurde das 
auf andere Pins gelegt?
Was ist die Baudrete, etc?

Danke euch

[De T. (detobsen)]

Hi zusammen,
Ich versuche auch gerade mein Glück. Hoffe ich bin mit meinem Problem 
hier richtig. :)

Hardware: ESP32 WROOM32, NRF24L01+
OS: Win10

Habe das Ahoy vom Repository in VS Code geladen. Habe Cmake und MinGw64 
installiert und die Pfade in die Systemvariablen eingetragen.

Im Projekt habe ich in der platformio.ini das src_dir eingetragen und in 
der config.ini die Anpassungen gemacht.

Weiter komme ich nicht. Habe vorher noch nicht mit pio gearbeitet.
Ich bekomme immer die Meldung "Unable to determine what CMake generator 
to use.", aber der GCC ist ausgewählt.
Beim starten des Projekts steht in der Ausgabe "The command: ninja 
--version failed with error: Error: spawn ninja ENOENT". Ninja ist aber 
durch CMake mit installiert :(

Kann mir bitte jemand einen Tipp geben.

[Günter H. (gnter_h534)]

Bei platformIO bin ich auch "auf dünnen Eis" - deshalb keine direkte 
Antwort auf die Frage.

Ein "Umweg" könnte aber sein:

https://github.com/lumapu/ahoy/actions/runs/3265026568
aufrufen, ganz unter "Artifacts" "ahoy_v0.5.20_dev_build.zip" 
herunterlabden und entpacken. Die ESP32 bin.Datei mit einem Tool deiner 
Wahl flashen.

Zum Herunterladen der zip-Datei musst Du bei GitHub angemeldet sein.

[De T. (detobsen)]

Danke für die Antwort.

Habe das Repo gelöscht und nochmals herunter geladen und im PIO Home als 
Projekt geladen. Danach hat es sich übersetzen lassen.

Dazu habe ich noch den "esp32-wroom32-release" als default_envs in der 
platformio.ini eingetragen.

[Detmar (Gast)]

Hallo
ich wurschtle mich nun schon seit Tagen durch dieses Thema hier und 
komme nich wirklich weiter. Ahoy-DTu mit ESP8266 und NRF-Modul mit 
Antenne habe ich soweit in Betrieb bekommen.
Aber leider lässt sich nur sporadisch der WR, HM-800 +2x 395W PV, auf 
eine Limitierung ein. Meist macht er immer 100%. Hatte mal Anfangs das 
OpenDTU probiert, da hat es gklappt. Leider war das ESP-Modul nur 
geliehen.
Ich wollte jetzt nich schon wieder neues Material kaufen, da der 8266 
noch vorrätig war. Wo kann ich jetzt noch suchen ?
Anbei ein Bild der Homeseite, wo ich mal eine Erklärung bräucht, wie die 
Daten nach dem Punkt Statistics zu interpretieren sind.

[Tobias K. (reserve)]

Blöde Frage: wieso sehe ich bei meiner Oberfläche nicht die RSSI 
Signalstärke? Gibts das nur in der Debug Variante?

[Hans (Gast)]

hans schrieb:
> Weiß jemand die Einstellungen der Serial Console? Das müßte ja auf
> der Seriellen Schnittstelle des VCP vom Wemos funktionieren, oder wurde
> das auf andere Pins gelegt?
> Was ist die Baudrete, etc?
> Danke euch

Leider geht es immernoch nicht, auch nicht wenn ich direkt nebenan bin. 
Hin und wieder kommt ein Packet durch...

Hat jemand eine Idee? Hat mir jemand die Debugeinstellungen?

[Tobias K. (reserve)]

welche Sendeleistung hast du eingestellt? Hast du damit mal gespielt?

[Detmar (Gast)]

Tobias K. schrieb:
> Blöde Frage: wieso sehe ich bei meiner Oberfläche nicht die RSSI
> Signalstärke? Gibts das nur in der Debug Variante?

Schau mal nach der FW-Version, meine ist 0.5.18.

[Grisu (krisu)]

Zu nah dürfte auch nicht gut sein, dann Leistung runterregeln.
@Detmar und @Hans:
Habt ihr einen Elko 100µ beim NRF an die Spannungsversorgung gehängt?

[Dirk S. (fusebit)]

Detmar schrieb:
> Tobias K. schrieb:
>> Blöde Frage: wieso sehe ich bei meiner Oberfläche nicht die RSSI
>> Signalstärke? Gibts das nur in der Debug Variante?
>
> Schau mal nach der FW-Version, meine ist 0.5.18.

Wo ist die denn her?
Wenn ich das aktuelle Verzeichnis bei GitHub kompiliere, dann ergibt das 
nur 0.5.17?

https://github.com/lumapu/ahoy

[M. P. (matze7779)]

0.5.17 ist die aktuelle stable.
Im Entwickler-Pfad ist man momentan bei 0.5.20
Das sind aber Beta Versionen!
Schau bei Github unter Actions
https://github.com/lumapu/ahoy/actions

[Joe G. (feinmechaniker)]

Eine Platine ist erfolgreich bestückt. Die Daten [1] sind somit 
freigegeben. Alle die eine Zusage zu einer Platine von mir haben, 
erhalten nun in den nächsten Tagen Post.

[1] https://aisler.net/p/EAYHGSED

[Detmar (Gast)]

Grisu schrieb:
> Zu nah dürfte auch nicht gut sein, dann Leistung runterregeln.
> @Detmar und @Hans:
> Habt ihr einen Elko 100µ beim NRF an die Spannungsversorgung gehängt?

Natürlich , direkt auf die Platine, auch bei dem NRF mit Antenne.

[Hans (Gast)]

Grisu schrieb:
> Zu nah dürfte auch nicht gut sein, dann Leistung runterregeln.
> @Detmar und @Hans:
> Habt ihr einen Elko 100µ beim NRF an die Spannungsversorgung gehängt?

Oh ne, ich nicht. Das wird es bei mir sein. Vielen Dank

[Wo bitte (Gast)]

wo finde ich die aktuellen Binary’s zum flashen?
Für esp 32 und 8226??

[Wo bitte (Gast)]

Wie wird zwischen Developement und Stabil unterschieden?

[Stefan (Gast)]

Hallo Zusammen,

ich steige jetzt auch in das Energieerzeugungsgeschäft ein, geiles 
Projekt :-)

Mit der Version 0.5.17 und ESP8266 habe ich immer Abstürze nach ~30min. 
Schon alles probiert, Spannungsversorgung, etc. Liegt vermutlich am 
billigen China Teil. Da die ESP32 Version laut Rückmeldung stabiler 
läuft, wollte ich wechseln. Aber nach dem flashen des BIN Files bekomme 
ich einen Dauerreset, probiert mit 2st. ESP32:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

Habe auch zwei verschiedene Flasher probiert und am USB eine externe 
Versorgung dran. Kennt einer einen Trick? Als Fallback habe ich einen 
ESP8266 und NRF24L01+ von einem deutschen Händler bestellt.

[Tobias K. (reserve)]

Ja, war bei mir auch so. Direkt aus MS Code compilieren und flashen 
klappt aber problemlos!

[Oswald S. (obmaroszi)]

Ich hab bevor ich mit VS begonnen habe den ESP 32 mit
ESPHome-Flasher-1.4.0-Windows-x64
geflasht

[Rudi (Gast)]

Hallo,
Erstmal ein großes Kompliment an die Macher hier für dieses Projekt.
Ich habe mir eine kleine Solaranlage mit dem Hoymiles HM-1200 aufgebaut.
Ich hangel mich jetzt schon seid stunden hier durch komme irgendwie 
nicht weiter!
Ich habe die AHOY-DTU nachgebaut und habe noch so einige Probleme :-( .
Ich habe die Aktuelle AHOY Version und das ESP-8266 Modul mit dem 
NRF24L01+ Funkmodul mit der langen Antenne.
Der Zusammenbau und das Flashen hat ( fast) problemlos funktioniert. Die 
Einstellungen habe ich soweit ich hier herausfinden konnte durchgeführt. 
Als Name habe ich HM1200 und die Seriennummer ( ich denke das ist die 
Nummer auf dem weißen Aufkleber) eingetragen.
Wenn ich mein Hauseigenes W-LAN eingeschaltet habe dann meldet sich der 
AHOY DTU nicht als verfügbares W-LAN in der W-LAN Liste an. Ich nehme an 
das heißt das die Verbindung zu meinem Haus- W-LAN steht. Ich kann aber 
nicht auf den AHOY DTU zugreifen. Wenn ich jetzt mein Haus-W-LAN 
ausschalte dann erscheint der AHOY DTU nach einigen Sekunden als 
verfügbares W-LAN in meiner Liste und ich kann darauf zugreifen. Der WR 
erscheint und ich kann die Daten vom WR sehen, alles so wie es sein 
soll. Schalte ich den AHOY DTU kurz aus und wieder ein dann kann ich 
sofort darauf zugreifen aber vom WR werden auch nach längerer warte zeit 
keine Daten empfangen. Es erscheint die Meldung Inverter #0: HM1200 (v0) 
is available and is not producing obwohl Strom produziert wird. Schalte 
ich mein Haus-W-LAN wieder ein und den AHOY DTU kurz aus und wieder ein 
dann geht das Spiel wieder von vorne los. D.d. ich kann nicht auf den 
AHOY zugreifen und er erscheint auch nicht in der W-LAN Liste. Erst wenn 
ich mein Haus-W-LAN ausschalte kann ich wieder darauf zugreifen und auch 
die Daten vom WR sind wieder da! Ich habe das ganze mit einem W10 PC 
einem Linux UBUNTU PC und meinem SMART PHONE ausprobiert immer mit dem 
gleichen Ergebnis. Nach einigem rumspielen geht nichts mehr und  jetzt 
kommt diese Meldung: WARNING! your NRF24 module can't be reached, check 
the wiring and pinout. Ich habe natürlich alle Verbindungen nochmal 
überprüft, alles O.K. kann es sein das ich mit meiner Spielerei 
irgendwas verstellt habe oder ist die Antenne schon für die Tonne ? 
Bewusst habe ich keine Einstellungen verändert!!
VG Rudi.

[Grisu (krisu)]

Flashe ihn nochmals. Wenn die Verbindung nicht gut war (hatte ich auch 
wenn er sich am letzten Repeater verband) dreht er durch, verbiegt die 
Settings (Pin-Zuordnung) und nix geht mehr.
Als erstes wenn du dich mit seiner SSID verbindest änderst die 
WLAN-Settings auf dein Heimnetz, damit du ihn übers Heimnetz erreichen 
kannst.

[Maik R. (bastelbarney)]

locke987 schrieb:
> Maik R. schrieb:
>> Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein
>> einfaches Tutorium empfehlen, wie ich in ioBroker ein
>> Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin
>> MQTT-Neuling, aber sehr interessiert.
>
> Ich mache das mit dem influxdb adapter der die Objekte bzw. geloggten
> Daten in eine influxdb schreibt und mittels Grafana mache ich dann die
> Auswertung. Tutorial habe ich leider keines. Beides habe ich als
> container in unraid laufen, hat keine halbe Stunde gedauert bis ich die
> ersten Graphen zusammen hatte.

Klar, für die reine Visualisierung natürlich auch ein Weg! Aber für 
direkte Aktionen wie "Habe Überschuss, schalte mal den Heizstab dazu" 
wäre ioBroker/FHEM & Co wohl reaktionsschneller, oder?
Also wenn mir noch mal jemand einen Tipp geben kann wie man den 
MQTT-Ausgang vom AHOY als Aktor in ioBroker einbinden kann, oder wo es 
gute Tutorien dazu gibt, das wäre schon super! (schade, keine 
Bettel-Smilies hier)

Zur Visualisierung:
Ich war 'ne Weile Offline, inzwischen lese ich eine DTU-Pro per 
Modbus/TCP aus. Über Telegraf-> InfluxDB-> Grafana. Wer Interesse hat, 
mit mir gemeinsam im Telegraf einen passenden AHOY-MQTT Block anzulegen 
... Dann schiebe ich das auf GitHub.

Ich schraube gerade daran, auch einen DTSU666 per Modbus/RTU auszulesen. 
Das geht nicht wirklich gut mit Telegraf, weil Telegraf einen vollen 
Client erzeugt und der DTU-pro schon Client ist, daher als Sniffer. Wenn 
der Code hübsch genug für die Welt ist, kommt er auf GitHub. Aber das 
wäre hier OT, worum es mir hier geht: hat schon jemand im Rahmen der 
Leistungsbegrenzung via AHOY einen DTSU666 -> ModbusRTU -> 
InfluxDB-/MQTT-Adapter in C oder C++ fertig?

Letztlich ist meine DTU-pro nur Übergangsweise, auf Dauer soll eine 
ESP/nRF24 Lösung das Ganze übernehmen und die DTU-Pro eine eBay-Reise 
machen. ;-)

[Mc S. (mcsplanish)]

Hallo zusammen,

zuerst einmal vielen Dank für eure tolle Arbeit. Ich habe versucht die 
letzten Wochen hier etwas quer zu lesen.

Ich habe seit 2 Wochen meinen HM-300 am laufen.
Aktuell lese ich die Daten des Stromzählers mit einem ESP32. Auf einem 
raspberry 4 habe ich dazu influxdb und Grafana laufen. Das funktoniert 
mega.

Ich habe mir diese nrf24 Module bestellt:
https://www.amazon.de/AZDelivery-NRF24L01-Wireless-Arduino-Raspberry/dp/B06XJN417D/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3KRVC99S97ZF8&keywords=nrf24&qid=1666518169&qu=eyJxc2MiOiIzLjYzIiwicXNhIjoiMy4xNiIsInFzcCI6IjIuNjIifQ%3D%3D&sprefix=nrf2%2Caps%2C327&sr=8-1-spons&psc=1&smid=A1X7QLRQH87QA3

und an meinen Pi angeschlossen.

Mein Problem:
Ich empfange nur extrem sporadisch Daten des Wechselrichters. Gefühlt 
kommt 1 response auf 100 requests. Ich habe schon die Sendeleitung 
variiert und die Ausrichtung der Antenne geändert. Der Pi liegt direkt 
neben meinem Router und der WR ist in max 5 Meter Entfernung auf dem 
Balkon.
Hat jemand noch eine Tipp für mich? Gerne versuche ich auch noch andere 
nrf24 Module, wenn das zielführend ist.

Vielen Dank euch!

[Steffen D. (steffen_d)]

Die Nrf von AZ Del.simd auf jeden Fall kompatibel und funktionieren bei 
mir sehr gut.

[Joe G. (feinmechaniker)]

Sowohl mein Steckbrettaufbau als auch mein Lochrasteraufbau waren extrem 
zickig. Das Verhältnis zu korrekten und fehlerhaften Frames war ca. 1:1. 
Der nun realisierte Aufbau auf einer Leiterplatte mit 90 Grad versetzten 
Antennen läuft besser. Das Verhältnis korrekte und fehlerhafte Frames 
liegt etwa bei 3:1. Von vier gekauften NRF24L01+ Modulen laufen zwei 
nicht.

[Tobias K. (reserve)]

ich kann das so unterschreiben, die kleinen Module hatten bei mir auch 
sehr viele fehlerhaft empfangene Pakete.
Seit ich das Modul mit "langer" Antenne verwende:
  Receive success: 416
  Receive fail: 0
  Frames received: 2491
  Send Cnt: 1823
Das ist aktuell von heute.

[Detmar (Gast)]

So, ich habe jetzt die Nrf-module getauscht. Auch um 90^Versetzt 
angeordnet.
Mite Ahoy geht einfach nicht die Limitiereung. RX Fehler und auch das 
mehrfache Reboot/Speichern hilft nicht. Was kann ich noch tun ?

[Joe G. (feinmechaniker)]

Einen meiner ersten Steckbrettaufbauten hatte ich auch nicht zum Laufen 
bekommen. Nachdem ich im System Config Menü die serielle Console 
aktiviert hatte (beide Häkchen) trudelten plötzlich korrekte Frames ein.

[Mc S. (mcsplanish)]

Tobias K. schrieb:
> ich kann das so unterschreiben, die kleinen Module hatten bei mir auch
> sehr viele fehlerhaft empfangene Pakete.
> Seit ich das Modul mit "langer" Antenne verwende:
>   Receive success: 416
>   Receive fail: 0
>   Frames received: 2491
>   Send Cnt: 1823
> Das ist aktuell von heute.

Vielen Dank!
Auf so einen Tipp hatte ich gehofft und mir direkt Mal die anderen 
Module mit Antenne bestellt. Ich melde mich mit Ergebnissen.

[Mc S. (mcsplanish)]

Joe G. schrieb:
> Einen meiner ersten Steckbrettaufbauten hatte ich auch nicht zum Laufen
> bekommen. Nachdem ich im System Config Menü die serielle Console
> aktiviert hatte (beide Häkchen) trudelten plötzlich korrekte Frames ein.

Kannst du das nochmal genauer beschreiben?
Die SPI habe ich auch aktiviert. Was denn noch?

[Joe G. (feinmechaniker)]

Unter Setup/System Config/Serial Console die beiden Häkchen print 
inverter data und Serial Debug aktivieren. Jetzt werden die daten 
zusätzlich über die serielle Schnittstelle ausgegeben. Damit erzeugte 
der Empfang vom Inverter plötzlich auch keine Fehler mehr an.

[Uli (Gast)]

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Hallo,
in der gleichen Situation half mir im Access Point Betrieb in der

void app::loop(void)

 einen else Zweig für

if (!apActive)

einzubauen. Ist aber erstmal noch vorläufig und ein arger Hack. 
Nebenwirkungen untersuche ich noch.

    if(checkTicker(&mNtpRefreshTicker, mNtpRefreshInterval)) {
        if(!apActive) {
            mTimestamp  = mWifi->getNtpTime();
            DPRINTLN(DBG_INFO, "[NTP]: " + getDateTimeStr(mTimestamp));
        } else 
        {
            mTimestamp = 1; // default, dass ap active ist, evtl hochzählen? todo 
                            // damit wird fake ntp Aufruf möglich und AHOY-DTU sendet wieder. 
                            // Empfang?
        }
    }

Meine Controller HW:

platform = espressif32
board = nodemcu-32s

[Uli (Gast)]

und noch der Verweis zur Frage (der oben ist falsch, sorry):
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Simon L. (solar_island)]

Hallo zusammen,
ich bin neu hier im Forum und total begeistert von euren Erfolgen.

WR die ich gerade im BKW Einsatz habe:
- Hoymiles HMI-250
- TSUN M350

Leider habe ich zu diesen beiden Modellen wenig bis nichts lesen können.
Konnten manchen Mitglieder hier schon Erfolge mit diesen WRs verbuchen?

Ziel ist bei mir auch die Nulleinspeisung über Nacht mit der am Tag in 
Akkus gespeicherten Solarenergie.

Die Daten vom Bild sind aus OpenHAB, gemessen von einem Shelly 3EM und 
über MQTT verfügbar. Meine Überschüsse vom Tag decken sich sehr gut mit 
den 70 W bis 90 W je nach Taktzyklus des Kühlschranks.

Überschuss Tag an guten Tagen: 0,8 kWh
Verbrauch in der Nacht: 10h * 80 W = 0,8 kWh

Viele Grüße
Simon

[Rudi (Gast)]

Hallo,
Danke für den Tipp mit dem „nochmals Flashen“.
Jetzt habe ich wieder die ursprüngliche Situation.
d.h. ich habe über mein Heimnetzwerk keinen zugriff schalte ich das 
Heimnetzwerk ab meldet er sich nach einigen Sekunden als W-LAN an und 
ich habe zugriff. Ich habe noch ein zweites W-LAN von Delovo mit dem 
gleichen Ergebnis :-( .Habe mich bei github nochmal durchgehangelt. Da 
steht das eine IP Adresse zugewiesen wird und man diese herauszufinden 
muss ! Ich dachte das würde automatisch passieren. Mal eine Frage für 
einen Anfänger!!! Warum macht man den Umweg über das Heimnetzwerk wenn 
es auch ohne funktionieren würde und er ein eigenes W-LAN zur Verfügung 
stellen kann ?
Auf github steht das er darüber die Aktuelle Uhrzeit bekommt! Was auch 
stimmt, wenn ich das Netzwerk abschalte und zugriff über W-LAN bekomme 
dann hat er die Aktuelle Zeit. Warum ist die Uhrzeit so wichtig ? Und 
wie mache ich das mit der IP Adresse?

Vg Rudi

[Grisu (krisu)]

Wieviele WLAN-Netze möchtest denn noch aufspannen?

Sei doch froh, daß er dann übers Heimnetz erreichbar ist. Oder möchtest 
den PC oder Handy immer umstellen damit du zugreifen kannst?
Außderdem wohin sollte er seine MQTT Daten hinschreiben ohne Heimnetz, 
das macht doch alles nur Sinn im Heimnetz.
Wie sollte der die Daten schreiben ohne Zeit?
Was wären die dann wert?

Brauchst doch nur dem PC eine fixe IP verpassen, mit cmd und "arp -a" 
siehst dann die IP.

[Ha F. (harry_f)]

Lässt dein Router neue WLAN Geräte zu?

Was sagen die Ausgaben an der seriellen Konsole?

[Rudi (Gast)]

Hallo,
Nein, er ist eben nicht übers Heimnetz erreichbar :-(
Das devolo ist nur Aktiv wenn ich im Garten oder auf der Terrasse bin 
weil
Das andere Netz nur im Haus funktioniert. Ich habe das devolo
jetzt mal nur zu Test Zwecken eingeschaltet in der regel ist es aus da 
ich es nur selten brauche.
Wie gesagt ich bin Anfänger auf dem Gebiet, ich habe nicht die leiseste 
Ahnung was es mit diesen MQTT Daten auf sich hat oder wozu man die 
braucht. Ich will doch „nur“ die Daten vom WR auslesen um zu sehen wie 
viel Leistung er gerade bringt oder ein Solarmodul einen Fehler hat etc. 
auf die Uhr schauen kann ich selber.
Scheinbar bin ich zu blöd dazu, jedenfalls werden mir keine weiteren IP 
Adressen angezeigt, nur die vom PC und selbst wenn, was soll ich damit 
den anstellen ??

vg Rudi

[Tobias K. (reserve)]

Nicht falsch verstehen, aber ich glaube das Teil ist nix für dich. Es 
ist eben kein „Consumer“ Produkt - sondern ein Entwickerprojekt bei dem 
du selbst auch diverse Einstellungen und Problemchen lösen bzw. 
vornehmen musst. Wenn du nicht weißt was du am Ende mit der zugewiesenen 
IP Adresse anfangen sollst, dann ist es einfach nix für dich. Aber es 
gibt ja auch die DTU von Hoymiles die ja Plug and Play funktioniert.

Wozu brauchst du das devolo Teil denn, hänge den Controller an den 
Rechner, aktiviere die serielle Schnittstelle und dann kannst du sehr 
wahrscheinlich schon sehen was das „Problem“ ist. Ferndiagnose ist 
einfach schwierig.

[Willi (willibutz)]

Hallo Community,
nachfolgend meine Erfahrungen mit dem Projekt und einige Hinweise die 
vielleicht helfen.

Ich nutze seit 'einigen Jahren' div. ESP8266 und ESP-32 Module.
So kam mir AHOY-DTU auf einem ESP8266 sehr gelegen.

Was nutze ich:
ESP8266 D1mini V3 (4MB Flash)
NRF24L01+ Modul mit extra Chip für Sender (mit und ohne ext. Antenne)

Die teilweise vorgeschlagene Verdrahtung ESP zum NRF finde ich 
problematisch.
Problem ist bei D3/GPIO0:
Wenn der bei Boot des ESP auf low ist, geht der ESP in den 
Programmiermodus.
Problem ist bei D4/GPIO2:
Beim D1mini hängt die blaue LED daran.
Die Pin sollte man meiden

Meine Empfehlung (so verdrahten und im Webinterface konfigurieren):
NRF = ESP
CS = D8 (GPIO15)
CE = D1 (GPIO5)
IRQ = D2 (GPIO4)

Problematisch ist auch die Stromversorgung des NRF24L01+.
Der Sender wird mit 3,3V versorgt.
Die 3,3V kommen aus einem Spannungsregler auf dem D1mini ESP8266 Modul.
Der ist nur für geringe Ströme ausgelegt.
Stromversorgung ist schon beim ESP8266 alleine problematisch.
Beim Senden werden kurzfristig Stromspitzen gezogen.
Um das etwas zu entspannen einen low ESR Elko auf 3,3V gegen Masse 
schalten. Ab 100microF sollte passen.

Im Webinterface in der Kofiguration ‚Radio (NRF24L01+) den Amplifier 
Power Level' auf ‚MIN‘ setzen.
Sonst hat es bei mir nicht funktioniert. Wobei ich ja Module mit 2 Chips 
habe.
Ein Modul OHNE ext. Antenne hat durch 2 Wände stabilen Empfang.
Das hat auf Anhieb funktioniert.
Die Teile sind alle über Ali bestellt. Billigstes Abgebot.

Empfohlene Software Version ist ab 0.5.17.
Problematisch ist auch bei 0.5.18, wenn ein eingerichtetes MQTT Ziel 
nicht verfügbar ist. Dann hängt irgendwie alles.

Danke für das tolle Projekt und viel Erfolg!

[Grisu (krisu)]

Rudi schrieb:
> jedenfalls werden mir keine weiteren IP Adressen angezeigt, nur die vom
> PC und selbst wenn, was soll ich damit den anstellen ??

Die sollst dann im Browser eingeben und das Teil vollständig 
konfigurieren beginnend mit der Eingabe deines Heim-WLAN, damit die 
Verbindung darüber hergestellt werden kann. Da bekommt es dann eine 
andere IP vom Router zugewiesen, welche findest im Router angeführt, 
falls es über DHCP eine bekommt, bzw. kannst der MAC eine bestimmte IP 
vorgeben.

Aber ich glaub auch, daß das alles deinen Horizont weit übersteigt.
Such dir vielleicht einen Bekannten der sich nur etwas damit auskennt 
und laß es dir einmal zeigen.

Aber so ganz ohne Dunst von der Materie, wie bist du dann überhaupt an 
das Teil gelangt und wie programmierst du es???
Irgendwann stehst sowieso an dem Punkt, daß du es neu programmieren 
mußt, ging mir auch schon so ohne "etwas getan" zu haben außer ab und zu 
die Werte ansehen.

Kauf dir lieber um 20€ ein Energiemeßgerät und häng es zw. Stecker und 
Steckdose, da kannst immer ablesen wieviel grad produziert wird. Wird 
deinen Ansprüchen vermutlich viel besser gerecht und ist echt plug&play.

[pakman (Gast)]

Maik R. schrieb:
> wäre ioBroker/FHEM & Co wohl reaktionsschneller, oder?
> Also wenn mir noch mal jemand einen Tipp geben kann wie man den
> MQTT-Ausgang vom AHOY als Aktor in ioBroker einbinden kann, oder wo es
> gute Tutorien dazu gibt, das wäre schon super!

Du musst in ioBroker zwei Adapter installieren:
- MQTT Broker/Client (als Broker)
- MQTT-Client

AHOY schickt die Daten über MQTT an den Broker. Diese sind dann schon 
mal in "Aufzählungen" sichtbar. Im MQTT-Client pickst Du Dir die 
interessierenden Topics raus, die dann unter "Objekte" erscheinen. Mit 
denen kannst Du dann wir gewohnt weiterarbeiten.

In JavaScript kannst Du vermutlich die Stati aus "Aufzählungen" direkt 
verwenden, ohne Umweg über den MQTT-Client.

Tutorials hierzu kann mal wohl vergessen, fast immer werden ältere 
ioBroker-Versionen beschrieben. Zur aktuellen v6.2.22 gibt es kaum was. 
Das ist besonders doof, weil sich doch Entscheidendes geändert hat.

[Rudi (Gast)]

Hallo,

„ welche findest im Router angeführt“

Das war die entscheidende Info die Ich brauchte oder nicht verstanden 
hatte. Habe die IP in den Netzwerkeinstellungen vom PC gesucht. Wie dem 
auch sei habe jetzt den Zugang übers Netzwerk.
Wie ich an das Teil gelangt bin ? Habe es selber gebaut, steht ja alles 
auf Github.
Was meinen Dunst von der Materie angeht ? Naja hatte während des 
Studiums auch E-Technik und Informatik auf dem Lehrplan ist aber schon 
viele Jahre her. Mit Elektronik beschäftige ich mich seid über 45 Jahren 
Hauptsächlich Analoge Transistor und Röhrentechnik habe aber auch das 
eine oder andere Mikrocontroller Projekt in „C“ und „Bascom“ auf die 
Beine gestellt .
Ja so ein Energiemessteil habe ich tatsächlich angeschlossen. 
Funktioniert sehr gut aber dazu muss ich immer nach draußen gehen um es 
abzulesen und es zeigt mir nicht an was die einzelnen Module bringen! 
Sicher hätte ich mir die Original Hoymiles DTU besorgen können finde den 
Preis für diesen Stick aber viel zu hoch außerdem geht es doch ums 
Bauen, Lernen und Verstehen.
Wie ich schon sagte Ich bin „Noch“ Anfänger auf dem Gebiet, das muss 
aber nicht so bleiben. Ihr ward sicher auch mal an diesem Punkt und 
sicher froh über jeden Tipp und Info die ihr bekommen konntet!
Nochmal vielen lieben dank für die Info.

vg Rudi

[Grisu (krisu)]

Ist halt schwierig zu helfen, wenn an keinen Schimmer hat wo ansetzen. 
;-)

Na Hauptsache du hast das jetzt auch hinbekommen.
Hab ähnliche Voraussetzungen, nur die Röhren blieben mir schon erspart.

[Hotzenwälder (Gast)]

Danke für das Projekt openDTU das bei mir mit einem HM300 und HM400 
läuft.
Ich habe noch einen Volkszähler und hole mir von dort den aktuellen 
Verbrauch über ein python-script. Dieses Script setzt dann das Limit für 
den Wechselrichter.
Das Script wird über crontab 1/minute aufgerufen.
Wenn ihr mal kucken wollt:
https://gitlab.com/p3605/hoymiles-tarnkappe
Gruss
Peter

[Mustafa K. (musti)]

Hallo zusammen,
ich nutze ebenfalls die aktuelle Ahoy-Version, danke dafür.
Jetzt habe ich mal eine Frage zur Limitierung. Diese wird ja von 
Hoymiles auf jeden Eingang umgerechnet. Sprich, wenn ich auf 50% setze, 
wird beim HM1500 jeder Eingang auf 187,5W begrenzt (4x 187,5W = 750W).
Ich möchte aber nun eine HM1500 nur mit 2 Modulen betreiben und den WR 
auf 600W begrenzen. Geht das jetzt nur so, dass ich die Begrenzung NICHT 
statisch auf 600W setze, sondern prozentual auf 80%? Nur dadurch würde 
ja jeder Eingang auf 300W begrenzt werden? Und wenn ein Modul mal 
verschattet und weniger als 300W generiert, kann das zweite Modul wohl 
trotzdem nicht die fehlende Leistung zum 300W kompensiere, und mehr als 
300W erzeugen können, korrekt?
Wäre eigentlich ziemlich schade, weil genau das beim DTU Pro ziemlich 
nervig ist..

[Mc S. (mcsplanish)]

Mc S. schrieb:
> Tobias K. schrieb:
>> ich kann das so unterschreiben, die kleinen Module hatten bei mir auch
>> sehr viele fehlerhaft empfangene Pakete.
>> Seit ich das Modul mit "langer" Antenne verwende:
>>   Receive success: 416
>>   Receive fail: 0
>>   Frames received: 2491
>>   Send Cnt: 1823
>> Das ist aktuell von heute.
>
> Vielen Dank!
> Auf so einen Tipp hatte ich gehofft und mir direkt Mal die anderen
> Module mit Antenne bestellt. Ich melde mich mit Ergebnissen.

Gestern sind die Module mit externer Antenne angekommen und 
funktionieren bei mir fast fehlerfrei.
Vielen Dank für den Tipp @Tobias K.

Jetzt muss ich nur noch die Bugs im python code finden ;)

[Grisu (krisu)]

Der Wert wird doch pro WR eingestellt und nicht pro Panel, wirkt also am
Ausgang des WR.
Und ob in Watt oder % ist nur eine Anzeigesache, funktionieren tut er im 
Hintergrund glaub ich immer mit % vom jeweiligen WR Peak-Wert.
Wenn du mehrere WR eingebunden hast kannst den Wert für
jeden separat einstellen, auch klar, daß da einer den anderen
nicht ausgleichen kann, die wissen voneinander doch nichts.

[Mc S. (mcsplanish)]

Eine kleine Frage noch. Ich habe auf die Schnelle nichts gefunden.
Kann mir jemand die beiden Werte daily und total erklären?

total: erzeuge Gesamtleistung in KWh?
daily: ??

Vielen Dank

[Grisu (krisu)]

Genau was es heißt, Total seit Anbeginn und Daily was heute erzeugt 
wurde.

Mustafa K. schrieb:
> Ich möchte aber nun eine HM1500 nur mit 2 Modulen betreiben und den WR
> auf 600W begrenzen.
Dann häng aber auch einen rechts und den anderen links an, damit jeder 
seinen eigenen Tracker hat und somit jeweils im Optimum betrieben wird.
Und trag halt 600 Watt persistent ein.

[CE E. (cees0k)]

Joe G. schrieb:
> Eine Platine ist erfolgreich bestückt. Die Daten [1] sind somit
> freigegeben. Alle die eine Zusage zu einer Platine von mir haben,
> erhalten nun in den nächsten Tagen Post.
>
> [1] https://aisler.net/p/EAYHGSED

Vielen Dank für deinen Beitrag. Das Design ist echt gut.

Kannst du uns nochmal Informationen zu den zusätzlichen Teilen 
mitteilen:

bis dato habe ich mitgeschnitten:
- deine Platine
- Wemos D1 Mini
- NRF24L01+ Modul
- Verbindungselemente zwischen Platine und Wmos sowie NRF24L01+ Modul

Was braucht man noch an elKos, Widerständen, Pinouts etc. und an welcher 
Stelle (C1, C2 usw.)? Ist eine Antenne von nöten und wenn ja welche?

[Mustafa K. (musti)]

Grisu schrieb:
> Der Wert wird doch pro WR eingestellt und nicht pro Panel, wirkt also am
> Ausgang des WR.
> Und ob in Watt oder % ist nur eine Anzeigesache, funktionieren tut er im
> Hintergrund glaub ich immer mit % vom jeweiligen WR Peak-Wert.
> Wenn du mehrere WR eingebunden hast kannst den Wert für
> jeden separat einstellen, auch klar, daß da einer den anderen
> nicht ausgleichen kann, die wissen voneinander doch nichts.

Es geht nicht um mehrere WR sondern weniger Solarmodule als Eingänge 
vorhanden sind (oder alternativ dass 1-2Module stark verschattet sind 
und nichts liefern).Den HM1500 auf 600W limitiert, heisst doch pro 
Eingang 150W. Und wenn dann zwei Module gar nicht angeschlossen sind 
(oder stark verschattet sind) liefert der WR mit den verbliebenen zwei 
Modulen eben nur maximal 300W, obwohl die beiden Module (z.b je 410W) 
eigentlich 600W liefern könnten. Wie bekommt ihr dieses Problem gelöst?

[M. P. (matze7779)]

Ob die Begrenzung sich auf alle 4 Eingänge aufteilt oder auf die 2 MPPT 
hab ich noch nicht herausgefunden.
Auf die zwei MPPT aber habe ich es aber feststellen können.

Du müsstest also auf 1200W begrenzen.

Aber um so "richtig" zu begrenzen und auch unterschiedliche Leistungen 
durch Verschattung an den einzelnen Modulen usw. zu beachten bräuchtest 
Du eine aktive Regelung.
Ich hatte mir da mal mit ioBroker gebastelt.
Leistung unter 600W --> Begrenzung erhöhen bis max 100%
Leistung über 600W --> Begrenzung verringern

[Grisu (krisu)]

Ich schrieb doch, daß es sich auf den AUSGANG des WR bezieht. Wie sich 
das auf die Panele aufteilt ist ihm völlig wurscht, er regelt die beiden 
Tracker eben so weit runter, daß die eingestellten 600W passen.
Die Angabe der Modulleistung ist nutzlos für den Betrieb (kannst auch 0 
oder 1MW eintragen) und rein für Statistikzwecke, damit du weißt was 
eines könnte in der Anzeige.

[M. P. (matze7779)]

Grisu schrieb:
> Ich schrieb doch, daß es sich auf den AUSGANG des WR bezieht.

Und genau das ist falsch.

Beispiel von mir mit HM-1200

Modul 1 & 2: Süd
Modul 3 & 4: West

Angenommen Limit auf 100% (1200W) Sonne scheint auf Süd und West ist 
verschattet.
Süd = 600 Watt
West = 100 Watt

Jetzt das Limit auf 50% (600W) passiert folgendes. Süd und West werden 
auf JEWEILS 300W gegrenzt.
Ergebnis:
Süd = 300 Watt
West = 100 Watt

Mehrfach getestet und das Thema hatten wir hier auch schon im Thread.

[Joe G. (feinmechaniker)]

CE E. schrieb:
> Kannst du uns nochmal Informationen zu den zusätzlichen Teilen
> mitteilen:

Das Layout ist für einen Wemos D1 Mini sowie ein NRF24L01+ Modul 
ausgelegt. Bei den NRF24L01+ Modulen können die mit integrierter Antenne 
und die mit zusätzlicher PA und externer Antenne verwendet werden. Die 
Anschlüsse sind pinkompatibel. Nach meiner Erfahrung funktionieren die 
Module mit externer Antenne zuverlässiger.

Zur Abblockung der Stromversorgung benötigt man auf der 5V und 3.3V 
Schiene jeweils einen Elko von 100 µF und einen 100n 
Vielschichtkondensator. Für den Anschluss der Spannungsversorgung (5V) 
gibt es zwei Schraubklemmblöcke im Rastermaß 5mm. Die beiden Module 
(Wemos und NRF24L01+) sind auf einreihige Buchsenleisten im Rastermaß 
2.5mm gesteckt (beim NRF24L01+ zwei nebeneinander).
Anhand es Bestückungsaufdruckes ist zu erkennen, an welcher Stelle die 
Kondensatoren sitzen. Die anderen Lötaugen können für den „normalen“ 
Betrieb frei bleiben.
Für die Steckverbinder, Buchsenleisten, Kondensatoren habe ich keine 
exakte Bauteilbezeichnung. Ich habe alles aus meinen vorhandenen 
Lagerbeständen bestückt. Wenn noch etwas unkla bleiben sollte, einfach 
fragen.

[M. P. (matze7779)]

@Joe

Nur als kleine Anregung. Integriere doch das Netzteil mit auf der 
Platine.
Anbei ein Bild von meinem in einer Abzweigdose mit Netzteil.

[Ziyat T. (toe_c)]

M. P. schrieb:
> Grisu schrieb:
>> Ich schrieb doch, daß es sich auf den AUSGANG des WR bezieht.
>
> Und genau das ist falsch.
>
> Mehrfach getestet und das Thema hatten wir hier auch schon im Thread.

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[CE E. (cees0k)]

Joe G. schrieb:
> CE E. schrieb:
>> Kannst du uns nochmal Informationen zu den zusätzlichen Teilen
>> mitteilen:
>
> Das Layout ist für einen Wemos D1 Mini sowie ein NRF24L01+ Modul
> ausgelegt. Bei den NRF24L01+ Modulen können die mit integrierter Antenne
> und die mit zusätzlicher PA und externer Antenne verwendet werden. Die
> Anschlüsse sind pinkompatibel. Nach meiner Erfahrung funktionieren die
> Module mit externer Antenne zuverlässiger.
>
> Zur Abblockung der Stromversorgung benötigt man auf der 5V und 3.3V
> Schiene jeweils einen Elko von 100 µF und einen 100n
> Vielschichtkondensator. Für den Anschluss der Spannungsversorgung (5V)
> gibt es zwei Schraubklemmblöcke im Rastermaß 5mm. Die beiden Module
> (Wemos und NRF24L01+) sind auf einreihige Buchsenleisten im Rastermaß
> 2.5mm gesteckt (beim NRF24L01+ zwei nebeneinander).
> Anhand es Bestückungsaufdruckes ist zu erkennen, an welcher Stelle die
> Kondensatoren sitzen. Die anderen Lötaugen können für den „normalen“
> Betrieb frei bleiben.
> Für die Steckverbinder, Buchsenleisten, Kondensatoren habe ich keine
> exakte Bauteilbezeichnung. Ich habe alles aus meinen vorhandenen
> Lagerbeständen bestückt. Wenn noch etwas unkla bleiben sollte, einfach
> fragen.

Dazu noch folgende Fragen:
Kann ich das gesamte Konstrukt auch über den USB Port beim Wemos D1 
betreiben oder ist zwingend eine 5V Verbindung über die 
Schraubklemmblöcke notwendig?

Warum ist bei deinem Bild kein Kondensator C1 und C2 eingelötet?

Wofür benötige ich die RST Pins und wie werden diese aktiviert?

Ist die Position des 100nF und des 100uF Kondensators egal?

Danke dir!

[Joe G. (feinmechaniker)]

CE E. schrieb:
> Kann ich das gesamte Konstrukt auch über den USB Port beim Wemos D1
> betreiben oder ist zwingend eine 5V Verbindung über die
> Schraubklemmblöcke notwendig?
Wenn das NRF24L01+ Modul gesteckt ist, kommt man an die USB-Buchse nicht 
mehr ran. In diesem Fall müssen die 5V extern zugeführt werden.

> Warum ist bei deinem Bild kein Kondensator C1 und C2 eingelötet?
Weil ich zunächst die Stabilität der Spannungsversorgung mit dem Oszi 
überprüft hatte. Die Elkos hatte ich im nächsten Schritt eingelötet.

> Wofür benötige ich die RST Pins und wie werden diese aktiviert?
Ist nur für Testzwecke vorgesehen, wird also im normalen Betrieb nicht 
benötigt.
>
> Ist die Position des 100nF und des 100uF Kondensators egal?
ja, beide liegen im Layout parallel

[mimi (Gast)]

Wo sind bei der Version AhoyDTU © 2022 0.5.25
die Einstellungen für die Leistungsbegrenzung geblieben?

[chrisbie (Gast)]

Willi schrieb:
> CS = D8 (GPIO15)
> CE = D1 (GPIO5)
> IRQ = D2 (GPIO4)

Mit dieser Konfiguration habe ich den WeMos D1 mini Pro von Elektor zum 
laufen gebracht.

[Volker.B. (Gast)]

mimi schrieb:
> Wo sind bei der Version AhoyDTU © 2022 0.5.25
> die Einstellungen für die Leistungsbegrenzung geblieben?

Das geht nur noch über die serielle Konsole und auch da nicht 
zuverlässig.
Aber diese Version ist irgendwie total geschrottet, wenn Abends der WR 
nicht mehr produziert, verschwinden auch viele Werte, wie z.B. 
YieldTotal, unter MQTT erscheint dann nur noch available and not 
producing.

[mimi (Gast)]

Volker.B. schrieb:
> Das geht nur noch über die serielle Konsole und auch da nicht
> zuverlässig.
> Aber diese Version ist irgendwie total geschrottet, wenn Abends der WR
> nicht mehr produziert, verschwinden auch viele Werte, wie z.B.
> YieldTotal, unter MQTT erscheint dann nur noch available and not
> producing.

Uhaa, das hört sich nicht gut an.
Welche Version gilt denn als "stabil".
Über Github ist das nicht wirklich ersichtlich, schade..

[mimi (Gast)]

HM1500 Limit 202% | last Alarm: Inverter start

Schräg....

[Grisu (krisu)]

Zeigt er hier auch an 202%. Dürfte aber "nur" ein Anzeigefehler sein.

[Grisu (krisu)]

Mustafa K. schrieb:
> Es geht nicht um mehrere WR sondern weniger Solarmodule als Eingänge
> vorhanden sind (oder alternativ dass 1-2Module stark verschattet sind
> und nichts liefern).Den HM1500 auf 600W limitiert, heisst doch pro
> Eingang 150W. Und wenn dann zwei Module gar nicht angeschlossen sind
> (oder stark verschattet sind) liefert der WR mit den verbliebenen zwei
> Modulen eben nur maximal 300W, obwohl die beiden Module (z.b je 410W)
> eigentlich 600W liefern könnten. Wie bekommt ihr dieses Problem gelöst?

M. P. schrieb:
> Und genau das ist falsch.

Tut mir Leid, zuvor einen ziemlichen Schmarrn geschrieben zu haben!
Durch meine 4 Panele hat es sich (zufällig) so dargestellt.
Würds ja gern wieder löschen wenn das hier ginge ...

Die eingestellte Leistung teilt sich tatsächlich auf die beiden Tracker 
auf, die sich dann NICHT gegenseitig ausgleichen können.

Aber dennoch ist das dann auch bei dir kein großes Problem.
Die Leistungsbegrenzung wird auf % umgerechnet und dann auf beide 
Tracker angewandt. Beim HM1500 also 750W pro Tracker bei 100% oder falls 
du insgesamt max. 600W möchtest eben auf 40% einstellen. Somit wird 
jeder Tracker max. 300W liefern, zusammen also die gewünschten 600W.
Du brauchst also immer nur ein "verschattetes" Modul zu einem besonnten 
hängen (rechte Seite) bzw. 2 weitere links. Also nicht 2 besonnte auf 
einer Seite sondern immer ein gutes mit einem schlechten pro Seite 
sprich pro Tracker.

Hier ein Bild von meinen, wie man sieht sind für den Test 400W (26%) 
eingestellt. Beide Seiten (1+2 bzw. 3+4) liefern somit bis zu je 200W, 
wobei das 4. Modul verschattet ist und durch das 3. Modul auf diesem 
Tracker ausgeglichen wird. Am anderen Tracker ist ein Modul nur ganz 
leicht verschattet, daher ähnliche Werte.

[PIC (Gast)]

Grisu schrieb:
> Zeigt er hier auch an 202%. Dürfte aber "nur" ein Anzeigefehler
> sein.

Du meinst Dein System zeigt das in Deiner Umgebung auch an?

[Grisu (krisu)]

Ja alle beide verbundenen WR, aber irgendwie nicht immer, sieht so aus 
erst nach einer gewissen Zeit.
Da ich gestern herumgespielt habe mit der Leistung steht aktuell 'Limit 
100% (not controlled)', bevor ich die Änderungen begann war es jedoch 
bei beiden 'Limit 202% (not controlled)'. Ich glaub mich zu erinnern, 
daß es erst nach einer gewissen Zeit dann umspringt. Nach einem Neustart 
steht ja noch 65535% dort, solange kein Kontakt zum WR erfolgt ist.

Ich hab auch noch nie verstanden oder gefunden was auf der Homepage die 
Angaben (v0) bzw. (v1) oder (v10018) bedeuten.
Vielleicht kann mir das jemand erklären?
Anfangs ohne Kontakt zum WR dürfte es immer (v0) sein, später dann für 
mich unerklärlich (v1) oder (v10018).

[M. P. (matze7779)]

Grisu schrieb:
> Anfangs ohne Kontakt zum WR dürfte es immer (v0) sein, später dann für
> mich unerklärlich (v1) oder (v10018)

Das ist glaub ich die Firmware-Version vom Wechselrichter.

[Gerri (Gast)]

Hallo zusammen,
ich habe eine Frage zur Leistungsreduzierung (v0.5.17).
Wenn ich im Ahoi-DTU Setup unter Inverter Active Power Limit die 100 und 
und unter Active Power Limit Control Type relativ in percent persistent 
eintrage, werden diese Werte, da ja permanent, ins Eprom geschrieben.

Wann und wie oft wird damit das Eprom mit beschrieben?

Schöne Grüße
Gerri

[Grisu (krisu)]

Ich glaube (!!!) 1x, und sobald er es dann später beim Auslesen wieder 
so zurückbekommt nicht mehr - wie gesagt eine Vermutung wie es sein 
sollte.
Alles andere wäre auf Dauer ja zerstörerisch.

Wäre aber schön wenn das ein Wissender bestätigen (oder berichtigen) 
könnte.

[Hinz (Gast)]

M. P. schrieb:
> Grisu schrieb:
>
>> Anfangs ohne Kontakt zum WR dürfte es immer (v0) sein, später dann für
>> mich unerklärlich (v1) oder (v10018)
>
> Das ist glaub ich die Firmware-Version vom Wechselrichter.

In der Doku nicht zu finden😪

[Gerri (Gast)]

Grisu schrieb:
> Ich glaube (!!!) 1x, und sobald er es dann später beim Auslesen wieder
> so zurückbekommt nicht mehr - wie gesagt eine Vermutung wie es sein
> sollte.
> Alles andere wäre auf Dauer ja zerstörerisch.
>
> Wäre aber schön wenn das ein Wissender bestätigen (oder berichtigen)
> könnte.

Vielen Dank erstmal für die Info.
Ich denke es wird auch so sein.

Jedenfalls habe ich noch festgestellt, das das Setzen von einem 
Powerlimit über MQTT (ioBroker) bei der v0.5.17, nur sporadich bei bei 
mir funktioniert!

[Grisu (krisu)]

Ich denke für kontinuierliche Anpassung ist das so und so nicht wirklich 
geeignet. Eher für eine fixe Einstellung, etwa um ihn auf 600 oder 800W 
zu limitieren und dennoch weit mehr Module anhängen oder den HM-1200 
bzw. 1500 verwenden zu können, um auch bei weniger Sonne weit höhere 
Ausbeute zu erhalten.
Möglicherweise sind andere NRF-Module als meines besser geeignet und 
können tatsächlich alle 30s Daten austauschen ohne Fehler.

[Christian F. (christian_f744)]

Hallo zusammen.

Ist es eigentlich schon jemandem gelungen den Esp8266 für mehr als 3 
Wechselrichter zu flashen? Ich versuche es seit Tagen, aber es 
funktioniert nur mit 3 WRs. Sobald ich mehr in die Config gebe, habe ich 
keine Möglichkeit mehr, sie einzugeben.

Vielleicht kann mir ja wer eine Bin erstellen für 9 WRs?

Danke, LG

[M. P. (matze7779)]

Christian F. schrieb:
> Ist es eigentlich schon jemandem gelungen den Esp8266 für mehr als 3
> Wechselrichter zu flashen?

Also da würde ich lieber mehrere Esp8266 nehmen.

[M. P. (matze7779)]

Grisu schrieb:
> Möglicherweise sind andere NRF-Module als meines besser geeignet und
> können tatsächlich alle 30s Daten austauschen ohne Fehler.

Also ich hab hier 5 Sekunden eingestellt. Und das funktioniert 
erstaunlich gut seit den 100uF an der 3,3V Leitung und Sendeleistung auf 
"Low".
Der ESP ist ca. 6m entfernt in einer Abzweigdose mit Sichtverbindung.

[hoytest (Gast)]

rolf schrieb:
> signal-2022-10-15-154236_002.jpeg
>
>             310 KB
>
>
>
>
>             signal-2022-10-15.jpeg
>
>             310 KB

Interessante Befestigung.
Kannst du davon mal Details posten?

[IngoEF (Gast)]

Moin,

gestern wurde meine DTU-Basis aus Raspi 1 mit NRF24+ fertig, das ReadMe 
im ahoy-git bis zur Anweisung, die Module crcmod, pyyaml + paho-mqtt zu 
aktualisieren und zu laden, abgearbeit.
Das System meldet keine Fehler beim Aufruf der 
Beispielapplikation"python3 getting_started.py".
Gehe ich nun einen Schritt im ahoy-Readme weiter und rufe diesen Befehl 
in der Shell auf:
sudo python3 -um hoymiles --log-transactions --verbose --config 
/home/dtu/ahoy.yml ,
kommt nach kurzer Zeit:
/usr/bin/python3: No module named hoymiles
und jetzt komme ich nicht weiter.
Laut Befehlsparameter wird das Modul namens "hoymiles" angefordert, nur 
leider bin ich wahrscheinlich zu blind um einen Hinweis zur Installation 
desselben zu entdecken.
Würde mir bitte jemand eine Anleitung oder einen Hinweis zur 
entsprechenden Dokumentation geben?

Danke + Gruß - Ingo

[Alexander H. (agentsmith1612)]

Vielleicht wurde das schon hier erklärt aber ich habe das noch nicht 
gefunden.
Was ist der genaue unterschied zwischen den Power Einstellungen "non 
persitent" und "persistent".

So ganz kann ich mir nicht herleiten was, welche Einstellung bedeutet.

[Mustafa K. (musti)]

Persistent sollte dauerhafte Drosselung sein, non persistent bis zum 
nächsten Reboot des WR (also nur bis Sonnenuntergang)..


Ich hab auch mal eine Frage: Wenn der WR offiziell mit der DTU Pro 
gedrosselt wurde, würde der "No power Limit" über Ahoy diese Drosselung 
aufheben, oder sind dies unterschiedliche und unabhängige 
Drosselungs-Arten?

[Tobias K. (reserve)]

Non-Persistent verliert die Einstellungen nachdem der Inverter im 
Power-Off war (z.B. über Nacht). Persistent ist eben für immer.

[Heinz (Gast)]

Hallo Ingo,
hast Du die Zip-Datei aus git heruntergeladen und entpackt?
Wenn nicht mach das erst mal.
- Dann in der Konsole per "cd-Befehl" in den Ordner ahoy-main/tools/rpi/ 
wechseln z.B.

cd ahoy-main/tools/rpi/

- Darin die Datei "ahoy.yml.example" mit einem Texteditor (z.B. nano) 
öffnen.

nano ahoy.yml.example

- Unten in dieser Datei gibt es einen Abschnitt "inverters:" Dort hinter 
"serial:" die Seriennummer Deines Inverters eintragen. Wenn Du später 
mittels ioBroker o.ä. eine Auswertung machen möchtest, würde ich diese 
Nummer auch gleich in der letzten Zeile unter "mqtt:" hinter "topic: 
'hoymiles/...'" eintragen.
- Nun die bearbeitete Datei unter anderem Namen abspeichern, z.B. 
ahoy.yml
- nano schließen.
- Du befindest Dich in der Konsole immer noch im Ordner "rpi". Hier 
existiert auch der Unterordner "hoymiles", der die Pythonmodule - die in 
Deinem Aufruf nicht gefunden wurden - enthält.
- Hier kannst Du nun den Befehl

python3 -um hoymiles --log-transactions --verbose --config ahoy.yml

aufrufen.
Willst Du später per Script den Befehl ausführen, muss der komplette 
Pfad dorthin in diesem Script angegeben werden.

Gruß Heinz

[Heinz (Gast)]

Danke schön...
An dieser Stelle möchte ich allen aktiv hier mitarbeitenden Entwicklern, 
Testern usw. ein ganz großes "Danke schön" sagen. Ich verfolge die 
Arbeit hier schon seit geraumer Zeit - und was hier entstanden ist, ist 
aller Achtung wert.
Macht weiter so und lasst Euch von Kritikern, die es auch hier gibt, 
nicht unterkriegen.

Recht herzlichen Dank
Heinz

[Marc (Gast)]

Hallo Ingo, da Problem hatte ich auch.
Schlussendlich musste ich noch das Projekt selber auf meinen RPI bringen
git clone https://github.com/stefan123t/ahoy.git
half.
Dann im Ordner ahoy/toolf/rpi starten.

[Grisu (krisu)]

Hat schon jemand die neue ahoy v0.5.28 getestet und ist bereit seine 
Erfahrungen damit zu teilen?
Kann man getrost das Update einspielen.
Verliert man damit die Leistungsbegrenzungsmöglichkeiten im GUI?

[Tobias K. (reserve)]

Nein, du verlierst das nicht. Meiner Meinung nach eine super Version! 
Die Weboberfläche ist wesentlich schneller und es kommt mir stabiler 
vor. Die Leistungsbegrenzung funktioniert nahezu in Echtzeit und 
problemlos. Ich kann das Update absolut empfehlen bisher!

[Thomas (Gast)]

Hallo
könnte jemand die v0.5.28 hier reinsetzen zum download, oder den kniff 
sage wie es von githup geht?

[Tobias K. (reserve)]

Du musst auf Releases klicken auf github. 
https://github.com/lumapu/ahoy/releases/tag/ahoy_v0.5.28

[IngoEF (Gast)]

Hallo Herbert und Marc,

danke für eure Super-Unterstützung, aber ich stecke trotzdem weiterhin 
fest.

@Marc

Das git ahoy repository hatte ich mir via

$ git clone https://github.com/grindylow/ahoy.git

(es scheint egal zu sein, ob es von "grindylow" oder "stefan123t" geholt 
wird)

schon gezogen, die Einstellungen in "ahoy.yml.example" editiert, als 
"ahoy.yml" gespeichert und damit kamen dann die im Beitrag gezeigten 
Fehler.

Wäre ich man gleich in den rpi-Ordner gewechselt, wären meine Probleme 
andere gewesen.

Wenn ich im rpi-Ordner bin komme ich schon weiter, aber der Aufruf

sudo python3 -um hoymiles ...

kommt jetzt zu dem Schluss:

Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "/home/ingo/dtu/ahoy/tools/rpi/hoymiles/__init__.py", line 13, in <module>
    import crcmod
ModuleNotFoundError: No module named 'crcmod'

Obwohl

pip list modules

die benötigten Module u.a. anzeigt:

crcmod                     1.7
RF24                       1.4.6
paho-mqtt                  1.6.1
PyYAML                     6.0

und damit die requirements erfüllt sind.

@Herbert

Hole ich per wget das Archiv 
"http://github.com/lumapu/ahoy/releases/download/ahoy_v0.5.28/ahoy_v0.5.28.zip";
steckt da nicht das richtige drin.

$ unzip -l ahoy_v0.5.28.zip

zeigt:

Archive:  ahoy_v0.5.28.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   918320  2022-10-30 22:11   221030_ahoy_0.5.28_esp32_2e08ee0.bin
   434880  2022-10-30 22:10   221030_ahoy_0.5.28_esp8266_1m_2e08ee0.bin
   434864  2022-10-30 22:10   221030_ahoy_0.5.28_esp8266_2e08ee0.bin
    17403  2022-10-30 22:11   User_Manual.md
---------                     -------
  1805467                     4 files

also vermutlich nur esp-Support.

Wo finde ich denn die für Raspi (rpi?) geeignete Zip-Datei?

Das oft erwähnte "ahoy.py"-Skript habe ich auch noch nicht entdeckt, 
aber das scheint sich im Laufe der Entwicklung verflüchtigt zu haben.

Gruß - Ingo

[Grisu (krisu)]

Thomas schrieb:
> Hallo
> könnte jemand die v0.5.28 hier reinsetzen zum download, oder den kniff
> sage wie es von githup geht?

Einfach auf Release und die zip runterladen und entpacken, dann im 
Web-GUI deiner DTU FW-Update starten und die passende .bin auswählen 
(bei mir die 221030_ahoy_0.5.28_esp8266_2e08ee0.bin).

Sieht echt toll aus die neue Ansicht und da dürfte echt was weitergehen, 
hoffe es funktioniert wenigstens so gut wie bisher - nach oben ist 
natürlich immer Luft. :-)
Leider wurden die Daten nur zum Teil übernommen, mußte die WR neu 
eingeben ebenso MQTT-Daten, Rest wurde übernommen.

[Ziyat T. (toe_c)]

Maik R. schrieb:
> Leistungsbegrenzung via AHOY einen DTSU666 -> ModbusRTU ->
> InfluxDB-/MQTT-Adapter in C oder C++ fertig?
>

ich steuere meine dtu-pro + dtsu666 über pymodbus, hab auch nen 
quick&dirty pymodbus (python) code für dtsu666

[IngoEF (Gast)]

Zu meinem letzten Post:

keine Ahnung, was passiert ist, aber auf einmal funktioniert der Aufruf.
Gemacht habe ich nichts, nur anstatt des Parameters "--config" den von 
der Hilfe angezeigten "-c" zu benutzen.

Manchmal hilft die Hilfe.

Inzwischen habe ich herausgefunden, dass

-c Dateiname,
--config Dateiname
--config-file Dateiname

gleichberechigt nutzbar sind und jetzt seltsamerweise alle 3 hier 
funktionieren. Hoffentlich bleibt das so.

Nochmals Danke + Gruß - Ingo

[El Capitan (Gast)]

Grisu schrieb:
> Thomas schrieb:
>> Hallo
>> könnte jemand die v0.5.28 hier reinsetzen zum download, oder den kniff
>> sage wie es von githup geht?
>
> Einfach auf Release und die zip runterladen und entpacken, dann im
> Web-GUI deiner DTU FW-Update starten und die passende .bin auswählen
> (bei mir die 221030_ahoy_0.5.28_esp8266_2e08ee0.bin).
>
> Sieht echt toll aus die neue Ansicht und da dürfte echt was weitergehen,
> hoffe es funktioniert wenigstens so gut wie bisher - nach oben ist
> natürlich immer Luft. :-)
> Leider wurden die Daten nur zum Teil übernommen, mußte die WR neu
> eingeben ebenso MQTT-Daten, Rest wurde übernommen.

Die Version hat keine Möglichkeit zur Leistungslimitierung?!

[Jürgen D. (juergen_diel)]

Wo ist der Unterschied zwischen der BIN-Datei: 
"221030_ahoy_0.5.28_esp8266_1m_2e08ee0.bin"

und der: "221030_ahoy_0.5.28_esp8266_2e08ee0.bin"

Danke für eine kurze Rückmeldung.

Gruß Jürgen

[IngoEF (Gast)]

Moin,

Jürgen D. schrieb:
> Wo ist der Unterschied zwischen der BIN-Datei:
> "221030_ahoy_0.5.28_esp8266_1m_2e08ee0.bin"
>
> und der: "221030_ahoy_0.5.28_esp8266_2e08ee0.bin"

das "1m" im Namen weist bestimmt auf eine Speichergrenze hin

- Ingo

[Jürgen D. (juergen_diel)]

Hallo Ingo,

danke für den Hinweis.

Gruß Jürgen

[IngoEF (Gast)]

Moin,

nachdem mein TSUN TSol-M800(DE) Wechselrichter nun auch seine Daten an 
die Hoymiles DTU preisgibt, habe ich nun noch eine Frage:

welche Applikation empfiehlt die Gemeinde denn so als GUI-Server für den 
Raspberry, denn den hatte ich noch rumliegen und deswegen eingesetzt.

Ich würde gern eine Anzeige im Browser des PCs sehen.

Danke + Gruß - Ingo

[Grisu (krisu)]

El Capitan schrieb:
> Die Version hat keine Möglichkeit zur Leistungslimitierung?!

Doch, jedoch an anderer Stelle (habs nicht auf Funktion überprüft).
Es gab nur im Vorfeld Diskussionen bei den Zwischenreleases, daß es weg 
wäre, deshalb fragte ich lieber bevor ich es aufspiele, war mir dann 
aber egal und nicht wichtig auf eine Antwort zu warten und war sehr 
positiv beeindruckt!

Jetzt zeigt ein HM-1500 noch brav die 100% (unlimitiert) an, der andere 
jedoch nicht mehr die von früher bekannten 202% sondern gleich "Limit 
202.1%", warum auch immer. :-)

Allerdings fehlt nun die Funktion "kein Power-Limit".
Man kann nur mehr nicht/persistent in Watt oder % einstellen nach 
Auswahl des WR, aber nicht mehr ohne Limitierung.
Muß man wohl jetzt den jeweiligen max. Wert des WR eintragen oder 100%.

Interessant finde ich auch die aktuelle Watt Anzeige (bisserl witzlos):
Total 57.199999999999996 W

Und die Zeit ist bei mir im Serial-Interface eine Stunde zurück.

Gerri schrieb:
> Wann und wie oft wird damit das Eprom mit beschrieben?
Also in der neuen Version 0.5.28 jedenfalls nur mehr einmal auf 
Anforderung, wenn man den Wert setzt.

[El Capitan (Gast)]

Hallo Grisu et. al,

eine Einstellung für Limitierung finde ich in der 0.5.28 nirgendwo.
Oder mir fehlt die Phantasie…

Mich beschleicht immer das Gefühl, dass die Einspeisung gedrosselt wird 
und ich die schöne Sonnenenergie nicht abschöpfe.
Das Webinterface kann mir ja viel vorgaukeln.
Malen wir mal nicht den Teufel an die Wand…
Es wird immer besser.
Toller Job

[Tobias K. (reserve)]

Die Funktion befindet sich unter „Serial Console“.

[Alexander H. (agentsmith1612)]

Hat jemand ein Schaltplan wo der 100µF Kondensator genau hin soll.
Auf der wohl neuen Ahoy Website: https://ahoydtu.de/
Steht was von Kondensator und auch hier im Thread wurde das kurz 
erwähnt, jedoch finde ich kein Schaltplan/Schaltbild wo der hin soll.

Ich habs zwar ganz gut verstanden wieso aber ein Schaltbild/plan ist da 
doch 100% eindeutig.

Danke

[Grisu (krisu)]

Am Eingang des NRF-Moduls zw. 3,3V und Masse. Steht eh vielfach hier.

[Joe G. (feinmechaniker)]

Die 5V bzw. 3.3V sollten möglichst in der Nähe der der beiden Module 
gepuffert werden. Zusätzlich zu den 100µF ist jeweils ein 100n 
Kondensator recht hilfreich.
https://www.mikrocontroller.net/attachment/574169/Hoymiles.sch.pdf

[El Capitan (Gast)]

Tobias K. schrieb:
> Die Funktion befindet sich unter „Serial Console“.

Da hätte ich sie niemals vermutet....

Befemdlich diese Stelle.

Was trage ichein wenn ich KEIN Limit möchte?
Was trage ich eine wenn ich 50% möchte, oder konkret nur 600 Watt 
einspeisen möchte?

Das kann man doch auch im Webinterface kurz erläutern.
Wäre m.E. viel funktionaler und unmißverständlich.

[Grisu (krisu)]

Warum nicht einfach 100% eintragen wenn du kein Limit möchtest?
Was gäbe es da zu erklären?
Gib halt 600W ein, wenn du das so willst oder den %-Satz der bei deinem 
den 600W entspricht.

[Christian E. (christian_e775)]

IngoEF schrieb:
> welche Applikation empfiehlt die Gemeinde denn so als GUI-Server für den
> Raspberry

Für meinen kleinen 3er Raspi nutze ich volkszaehler (kann das 
python-script ja mittlerweile direkt ansteuern, die Beispiel-Config hat 
alles korrekt drin). Grafana + InfluxDB geht auch, ist aber aufwendiger 
(und ich habs nicht auf dem Raspi hinbekommen da ich es nicht geschafft 
habe, influx2 zu installieren).

[Ingo E. (ingoef)]

Christian E. schrieb:
> Für meinen kleinen 3er Raspi nutze ich volkszaehler

danke für den Hinweis.

Mal sehen, was ich so hinbekomme.

Welche Visualisierung läuft eigentlich in der esp-Umgebung?

Ein probeweises

apt install influxdb

hat in meinem Raspi funktioniert; influxdb2 scheint nicht zu existieren.

[Grisu (krisu)]

Die Limitierung in % dürfte (zumindest bei meinem HM-1500) vermurkst 
sein. Angaben in Watt flüchtig und dauerhaft scheinen korrekt zu 
funktionieren.
Nur in % wenn ich es eintrage tut sich nichts.
Habt ihr ähnliche Beobachtungen?

[Tobias K. (reserve)]

Stimmt, bei mir das gleiche. Hatte es nur mit den Watt probiert und das 
funktionierte auf Anhieb.

[Joe G. (feinmechaniker)]

Grisu schrieb:
> Nur in % wenn ich es eintrage tut sich nichts.
> Habt ihr ähnliche Beobachtungen?

Kann ich bestätigen (HM-1500). Bei Einträgen in % kommt auch keine 
Antwort bei Ctrl result: Die Einstellungen in Watt funktionieren.

[Wolfi (Gast)]

Hallo zusammen ...

Ein Super Projekt!! Mein HM-600 ist im Versand und da kommt das 
natürlich gerade recht. Ich habe mal einen Wemos D1 mini geflasht und 
eingerichtet. Das NRF24L01+ sollte im laufe des Tages kommen.

Will das ganze per MQTT mit Homeassistant verbinden und dabei ist mir 
aufgefallen das die Verbindung bzw. der login abgelehnt wird.

Liegt das tatsächlich daran das die anderen Komponenten noch nicht 
angeschlossen sind?

2022-11-02 11:38:38: New connection from 192.168.xxx.xx:52211 on port 
1883.
2022-11-02 11:38:38: Client <unknown> disconnected, not authorised.

Gruß Wolfi

[Wolfi (Gast)]

> 2022-11-02 11:38:38: New connection from 192.168.xxx.xx:52211 on port
> 1883.
> 2022-11-02 11:38:38: Client  disconnected, not authorised.
> Gruß Wolfi

Ok, hat sich erledigt. Es durfte nicht der admin von mqtt (Mosquitto) 
sein. Einfach noch einen Benutzer anlegen in Homeassistant und dann ging 
es.

INFO: MQTT is connected, 473 packets sent

Gruß Wolfi

[planlos (Gast)]

Tobias K. schrieb:
> Stimmt, bei mir das gleiche. Hatte es nur mit den Watt probiert und das
> funktionierte auf Anhieb.

Was trägt man nun optimaler Weise ein, wenn man sicher keine Begrenzung
haben möchte?

Einen Phantasiewert wie 5000 Watt?

Danke

[planlos (Gast)]

Oder einfach NICHTS?

[M. P. (matze7779)]

planlos schrieb:
> Was trägt man nun optimaler Weise ein, wenn man sicher keine Begrenzung
> haben möchte?

Die Leistung deines Wechselrichters mit "Persistent".
Bzw. wenn er jetzt auf 100% läuft. Einfach nix.

Das was Du dort einträgst wird einmal an den Wechselrichter übertragen.
Es ist keine feste Einstellung in AHOY. Sondern wird nur einmal gesendet 
wenn Du auf "Send Power Limit" klickst.

[M. P. (matze7779)]

Und die Prozentangaben funktionieren beim HM1200 auch nicht.

[Tobias K. (reserve)]

Danke M.P. für das melden des Issues.

[IngoEF (Gast)]

Christian E. schrieb:
> Für meinen kleinen 3er Raspi nutze ich volkszaehler (kann das
> python-script ja mittlerweile direkt ansteuern, die Beispiel-Config hat
> alles korrekt drin)

Hallo Christian,

Volkszähler läuft, UIDs habe ich für die einzelnen Messwerte erzeugt und 
entsprechend in

ahoy.yml

 eingetragen, in der MySQL-DB sind alle Entities und Properties zu 
finden. Nur laufen trotz funktionierender DTU keine Daten aus ahoy in 
die Middleware.
Sniffen auf port 80 zeigt keinerlei Aktivität oder bin ich bzgl. der 
Schnittstelle auf dem Holzweg?
Welcher Trick fehlt mir noch?

Gruß - Ingo

[Daniel (Gast)]

Guten Abend,

Ich hab die Ahoy-DTU nach gebaut und installiert. Den Inverter 
eingerichtet, aber ich bekomm die Meldung das der „Inverter #0: is not 
available“.

Ich hoffe ihr könnt mir weiterhelfen.

Schön Dank schon mal im Vorraus.

[Tobias K. (reserve)]

Das ganze funktioniert nur wenn der Inverter Strom hat - sprich 
Tagsüber. Nachts hast du keine Verbindung.

[Grisu (krisu)]

planlos schrieb:
> Tobias K. schrieb:
> Was trägt man nun optimaler Weise ein, wenn man sicher keine Begrenzung
> haben möchte?
> Einen Phantasiewert wie 5000 Watt?
Natürlich keinen Phantasiewert sondern den max.-Wert deines WR.
Also beim HM-1500 eben 1500W.

[Daniel (Gast)]

Das hab ich schon gelesen, hat heut Mittag/Nachmittag auch nicht 
funktioniert.

[Helmut H. (der_andere)]

Tobias K. schrieb:
> funktioniert nur wenn der Inverter Strom
Wenn die Solar Panel Spannung liefern, genauer.
Hast Du denn in seriellen Ausgabe (z.B. mit HTerm) Mitteilungen gesehen, 
die die Kommunikation beschreiben, läuft Die?

[Christian E. (christian_e775)]

IngoEF schrieb:
> Nur laufen trotz funktionierender DTU
> keine Daten aus ahoy in die Middleware.
>

Kommen denn auch wirklich Daten vom Wechselrichter beim Raspi an? Am 
besten mal mit "--log-transactions --verbose" auf der Kommandozeile 
starten und schauen was da ankommt.
Falls Du etwas python kannst, ggf. in der outputs.py ein paar Ausgaben 
einbauen oder mich per Mail kontaktieren (siehe git commit logs)

[Manfred H. (mhen)]

So, nun möchte auch ich (Teil der "stillen-Mitleser-Armee") Erfolg 
vermelden und mich bei den Entwicklern bedanken!
Im provisorischen Betrieb ist ein Hoymiles HM600 (Serien-Nr. 11418....) 
mit einem von zwei TrinaSolar Panels, im Garten ausgebreitet (für das 
Garagen Flachdach fehlt es noch an Befestigungs- und Dichtungsmaterial).
Ein WEMOS D1 mini (4MB) von Berrybase mit einem nRF24L01+ (Altbestand 
aus unbekannter Quelle mit o oben links!)und Stütz-Elko funktioniert mit 
ahoy 0.5.28 einwandfrei.
(Einstellungen wie vom Kollegen "hoymiles-tarnkappe" hier etliche 
Threads zuvor empfohlen: CS = D8 (GPIO15), CE = D1 (GPIO5) und IRQ = D2 
(GPIO4).

Die ersten Versuche, einen NodeMCU-ESP32 von Joy-it zu flashen (liegen 
hier rum und hätten vermutlich auch etwas stabilere 3,3V), schlugen 
fehl, allenfalls rasch blinkende rote LED oder überhaupt keine Reaktion.
Erst ein Webdienst, für den ich dann noch Chromium als Browser nehmen 
musste, klappte überraschend gut!
Hier ist mein Problem, dass ich keine Referenz gefunden hatte, welcher 
PIN mit welchem GPIO korrespondiert, um die o.g. Zuordnungen.
Das "Espressif ESP32 Flashtool" (nur Win) funktioniert bei mir nicht, 
der "ESP-Flasher-x86" (auch für Win) mit der NodeMCU-ESP32 ebenfalls 
nicht, aber mit der WEMOS D1 mini.

Sehr hilfreich ist übrigens eine korrekte Seriennummer ;-)
Es hat mich eine Stunde und Nerven gekostet, dass der Wechselrichter 
sich einfach nicht kontaktieren lassen wollte ... von der 1141 war noch 
eine "1" mehr auf meinen Handzettel reingerutscht und damit die letzte 
Ziffer beim Eintragen in die AHOY-DTU herausgefallen und der WR 
inzwischen, natürlich, hinter dem Panel verschraubt.
Beim ersten Betrieb fällt mir auf, dass ein Shelly Plug-S 
Steckdosen-Adapter rund 50W MEHR Leistung vom Wechselrichter anzeigt, 
als die AHOY-DTU Software !?
Wenn ich den WR softwaremäßig "restarte" wird die tägliche Stromernte 
gelöscht, die bisher aufgelaufene Gesamtmenge kWh bleiben erhalten?
Eine Kleinigkeit:
den Abfrageintervall von 30 Sek. habe ich mal auf 20 Sek. verkürzt, 
klappt problemlos, die Entfernung zum WR im Garten war zu diesem 
Zeitpunkt vielleicht 10-12m mit einer Kellermauer dazwischen (ich habe 
einen ebenerdigen Kellerausgang zum Garten) und jede Abfrage produzierte 
eine ordentliche Antwort.
Die Anzeige "Every 30 seconds the values are updated" ändert die 
Einstellung auf 20 Sekunden aber nicht. Wirklich nicht wichtig, aber 
wenn ganz viel Zeit übrig ist, könnte der Intervall als Variable im 
String ausgegeben werden können.

[Manfred H. (mhen)]

Manfred H. schrieb:
Zunächst eine Korrektur/Ergänzung:
> Hier ist mein Problem, dass ich keine Referenz gefunden hatte, welcher
> PIN mit welchem GPIO korrespondiert, um die o.g. Zuordnungen.

"... welcher PIN mit welchem GPIO korrespondiert, um die o.g. 
Zuordnungen der CE/CS/IRQ vornehmen zu können".

Zur AHOY-DTU Software:
Wenn ich die Elektronik zum Kollegen im Dorf mitnehme, um ihm die 
Funktionen an SEINER PV-Anlage zu zeigen, komme ich außerhalb meines 
WLAN nicht auf die Weboberfläche zum Einstellen z.B. der Seriennummer.
Wie reagiert die AHOY-DTU, wenn beim Einschalten das eingestellte Netz 
nicht erreichbar ist? Rückfall auf den eigenen Accesspoint?

Manfred

[Ameise (Gast)]

Wieder einmal jemand, der mit dem Projekt Geld verdienen will.
Na ja, die Abmahn Rechtsanwälte wird´s freuen und das Finanzamt, 
Gewerbeaufsichtsamt und einige andere auch.

https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-ahoy-mit-gehaeuse-und-anleitung/2262602790-168-2700

[El Capitan (Gast)]

Ameise schrieb:
> Wieder einmal jemand, der mit dem Projekt Geld verdienen will.
> Na ja, die Abmahn Rechtsanwälte wird´s freuen und das Finanzamt,
> Gewerbeaufsichtsamt und einige andere auch.
>
> 
https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-ahoy-mit-gehaeuse-und-anleitung/2262602790-168-2700

Was sollte denn dagegen rechtlich einzuwenden sein?
Das sollte jeder Ameise klar sein, NIX!

NIX!

[Grisu (krisu)]

Zudem er es sogar ohne FW anbietet, also als reine HW die man erst 
selbst in Betrieb nehmen muß.
Verwerflich, ja in gewissem Rahmen, aber sonst auch schon rein gar 
nichts.
Höchstens die Finanz könnte daran Gefallen finden!

Und irgendwann wirst meine auch auf einer solchen Plattform angeboten 
finden, wenn ich mein System möglicherweise nächstes Jahr umstelle und 
keine Bedarf mehr daran haben werde. Vielleicht behalt ich es aber aus 
sentimentalen Gründen oder als Reserve, wer weiß - freu mich allenfalls 
schon auf deine "Anwälte".


Manfred H. schrieb:
> Zur AHOY-DTU Software:
> Wenn ich die Elektronik zum Kollegen im Dorf mitnehme, um ihm die
> Funktionen an SEINER PV-Anlage zu zeigen, komme ich außerhalb meines
> WLAN nicht auf die Weboberfläche zum Einstellen z.B. der Seriennummer.
> Wie reagiert die AHOY-DTU, wenn beim Einschalten das eingestellte Netz
> nicht erreichbar ist? Rückfall auf den eigenen Accesspoint?

Du kannst dich doch mit deren Hotspot verbinden und sein WLAN eintragen.

Wieso fragst du so etwas anstatt es einfach mal auszuprobieren.
Dreh dein WLAN in der Nacht mal kurz ab und versuch es ...
Dann hast Sicherheit und zudem schon mal geübt, um nicht allzu blöd vor 
dem  Freund dazustehen.

[Wolfi (Gast)]

Hallo Gemeinde ...

Blöde Frage! Ich hab irgendwo gelesen das auf Git auch die Dev als 
binarys irgendwo zum download sind. Bin ich blind, oder wo findet man 
die denn genau?

Gruß Wolfi

[Volker.B. (Gast)]

Wolfi schrieb:
> Hallo Gemeinde ...
>
> Blöde Frage! Ich hab irgendwo gelesen das auf Git auch die Dev als
> binarys irgendwo zum download sind. Bin ich blind, oder wo findet man
> die denn genau?
>
> Gruß Wolfi

[Volker.B. (Gast)]

Aso, ja.

[Werner (10kloc)]

Hallo,
Ich weiß nicht ob ich mit meinem Problem hier richtig bin.
Wenn nicht, wäre ich für einen passenden link dankbar.
Der link in der Ahoy weboberfläche scheint mir gehacked.
Ich habe einen Hoymiles 1000.
Und eine Box mit esp 8266.
Die neueste Firmware ist geladen.
Leider bekomme ich keine Daten Hoymiles 1000.
Laut meinem shelly wir Energie erzeugt.
Am WR war schon mal eine hoymiles dtu pro.
Diese ist aktuell spannungslos, Den WR hatte ich von 230V getrennt.

Kann mir jemand helfen?

Grüße
Werner

[Grisu (krisu)]

Dann hat er schlicht keine Verbindung zum WR.
Hast du die richtige SN eingetragen und auch die Pin-Zuordnung korrekt 
deinem Aufbau entsprechend eingestellt?

[Ziyat T. (toe_c)]

Werner schrieb:
> Hallo,
> Ich weiß nicht ob ich mit meinem Problem hier richtig bin.
> Wenn nicht, wäre ich für einen passenden link dankbar.
> Der link in der Ahoy weboberfläche scheint mir gehacked.
> Ich habe einen Hoymiles 1000.


was ist das für ein WR? MI oder HM? oder welche serienummer hat er, die 
ersten 6 stellen würde auch weiter helfen

[Ziyat T. (toe_c)]

Werner schrieb:

> Der link in der Ahoy weboberfläche scheint mir gehacked.

wie? kannst du einbisschen genauer sein?

sonst ist die hilfe unter 
https://discord.com/channels/984173303147155506/ zu finden

[Werner (10kloc)]

Das schaut für mich aus wie eine Abzocker seite

[Werner (10kloc)]

Es ist ein HM 1000, HMS-1000-2T
Seriennummer = 11448016...
Diese hab ich im Web ui eingetrage

[Ziyat T. (toe_c)]

Werner schrieb:
> Es ist ein HM 1000, HMS-1000-2T
> Seriennummer = 11448016...
> Diese hab ich im Web ui eingetrage

ist er jetzt ein HM oder HMS?

imho, es werden folg serienummern unterstützt:
HM-300    | 1121
HM-350    | 1121
HM-400    | 1121
HM-600    | 1141
HM-700    | 1141
HM-800    | 1141
HM-1200   | 1161
HM-1500   | 1161

[Grisu (krisu)]

Werner schrieb:
> Diese ist aktuell spannungslos, Den WR hatte ich von 230V getrennt.
Vielleicht solltest den WR mal in Betrieb nehmen, woher sollte er wohl 
sonst den Strom für die Funkübertragung hernehmen wenn du ihn vom Netz 
trennst und somit außer Betrieb nimmst?
Das war doch mit deiner DTU-pro auch nicht anders, oder?

[Ziyat T. (toe_c)]

Grisu schrieb:
> Werner schrieb:
>> Diese ist aktuell spannungslos, Den WR hatte ich von 230V getrennt.
> Vielleicht solltest den WR mal in Betrieb nehmen, woher sollte er wohl
> sonst den Strom für die Funkübertragung hernehmen wenn du ihn vom Netz
> trennst und somit außer Betrieb nimmst?
> Das war doch mit deiner DTU-pro auch nicht anders, oder?

wr braucht die dc-spannung der panels zum funktionieren bzw. zur 
übertragung, nicht das ac-netz, wenn man ihn vom ac-netz trennt, er 
produziert einfach nichts, aber funktioniert weiter

[isnoAhoy (Gast)]

AhoyDTU development Builds findet man nach dem Github Login unter 
Actions. Dort einfach einen der letzten Build Läufe auswählen und dann 
hängen die Artefakte als ein ZIP ganz unten dran. Im ZIP findet man die 
ESP8266 und ESP32 builds. Ich glaube sogar eine 1MB Variante für ESP8265 
oder so ist darunter.

[isnoAhoy (Gast)]

Werner schrieb:
> Das schaut für mich aus wie eine Abzocker seite

Hallo Werner,

bitte mal den Aluhut beiseite legen, das ist die Anmeldeseite von 
Discord. Die Entwickler und viele andere unterhalten sich dort weil es 
ein bißchen interaktiver ist, als das mittlerweile 14 Seiten lange und 
sehr lineare uC Forum hier.

Der Meldung nach zu urteilen versuchst Du zu senden, bekommst aber keine 
Antwortpakete zurück. Den Serial Debug Level könntest Du ggf. noch etwas 
hochstellen und auch mal ein Log des USB Serial Logs mitschneiden. Da 
meldet sich der NRF24 mit Modellbezeichnung und ob er richtig 
angeschlossen ist. Vermutlich kommt er aber mit dem D3 Pin als IRQ nicht 
zu Recht.

Was ist denn eigentlich die neueste Firmware (0.5.28 wie auf Deinen 
Screenshots oder die development Version 0.5.32) und vor allem wie sieht 
es in Deiner Blackbox mit ESP8266 drin aus ?
Ist da ein Wemos D1 mini drin oder ein etwas größerer NodeMCU ? Der 
Wemos D1 mini braucht i.d.R. den IRQ auf D1 / D2 weil er bei D3 nichts 
empfängt. Die Ursache kennen wir nicht ist aber m.W. hinreichend in der 
FAQ und get-started dokumentiert.
Hast Du einen NRF24L01+ mit einer externen Antenne oder nur so einen 
einfachen mit auf die Schaltung geäzter Leiterbahn ?
Ist ein entsprechender Elko am NRF24 Pin1&2 GND&+3.3V verbaut ?
Ein Bild von Deiner Schaltung wäre auch noch ganz gut.

Viele Grüße,
Stefan

[isnoAhoy (Gast)]

Manfred H. schrieb:
> "... welcher PIN mit welchem GPIO korrespondiert, um die o.g.
> Zuordnungen der CE/CS/IRQ vornehmen zu können".

Schau doch bitte mal in die getting started Beispiele auf der 
lumapu/ahoy Seite dort sind die vorgeschlagenen Pin Verbindungen 
dokumentiert. Je nach verwendetem ESP8266 / ESP32 Modul kann man sich 
die Pinouts im Internet suchen und dann sind dort die GPIO Nummern 
angegeben. Die Bezeichnungen / Zuordnungen von DX Pins und GPIO können 
sich je nach Modell unterscheiden, daher sind die GPIOs eigentlich die 
richtigen Bezeichnungen.
MISO, MOSI und SCLK sollten klar sein (bei ESP32 gibt es die V-/H-, ich 
glaube die OpenDTU Dokumentation beschreibt da die richtigen). Und für 
die anderen drei CE/CS/IRQ hast Du die freie Wahl, wir haben ein 
Beispiel seit Urzeiten als Default festgelegt und einige haben so auch 
Ihre Platinen geätzt / gelötet daher bleibt es wohl auch dabei. Obwohl 
es immer wieder Berichte gibt, dass die Kombination von D3 = IRQ auf dem 
Wemos D1 mini (v1/v3) Probleme macht. Hier kann man einfach den D1 / D2 
Pin verwenden und es sollte nach Konfigurationsänderung im Setup gehen.

[Grisu (krisu)]

Ziyat T. schrieb:
> wr braucht die dc-spannung der panels zum funktionieren bzw. zur
> übertragung, nicht das ac-netz

Ja, da hab ich mich wohl unglücklich um nicht zu sagen falsch 
ausgedrückt, ein Panel ohne Sonne (etwas Licht halt) beschert ihm aber 
auch noch keine Funkverbindung.

[planlos (Gast)]

Volker.B. schrieb:
>> Blöde Frage! Ich hab irgendwo gelesen das auf Git auch die Dev als
>> binarys irgendwo zum download sind. Bin ich blind, oder wo findet man
>> die denn genau?
>>
>> Gruß Wolfi

Du klickst auf das entprechende "DEV", dann auf der neuen Site ganz nach 
unten scrollen.

[Werner (10kloc)]

Hallo,
Zunächst mal die Schaltung
Beiliegend die Bilder.

Der link oben
https://discord.com/channels/984173303147155506/
Bringt mich nicht weiter.
Welchen Channel muß ich öffnen, mit welchem Thema.

[Grisu (krisu)]

Vorzugsweise lötest gemäß voherigen Beiträgen D4 nach D1 und D3 nach D2 
um und stellst es in der Config dann entsprechend ein.
CS: D8
CE: D1
IRQ: D2
Und dann hängst wenigstens ein Panel an bei Sonnenschein, wenn du ihn 
schon nicht ans Netz hängen möchtest, wirst halt auch keine brauchbaren 
Daten dann bekommen.
Sonst sieht dein Machwerk gut aus.

[Dirk (pip3000)]

Sorry (fast schon off-topic):

@Werner - ich beziehe mich auf Dein "20221107_125951.jpg": Darf ich 
fragen, was das für Kabel sind und wie Du das so sauber gelötet 
bekommst? Ich habe schon wirklich viel gelötet, aber das gefällt mir 
besonders gut!

[planlos (Gast)]

Dirk schrieb:
> Ich habe schon wirklich viel gelötet, aber das gefällt mir
> besonders gut!

Gutes Werkzeug, gutes "Blei" Lötzin, dann sollte das schon passen

[Grisu (krisu)]

Litzen abisolieren, verdrillen, durchstecken und von unten mit etwas 
Zinn mit Flußmittel kurz hinhalten, das sieht doch dann bei allen so 
aus.

[planlos (Gast)]

Grisu schrieb:
> Litzen abisolieren, verdrillen, durchstecken und von unten mit etwas
> Zinn mit Flußmittel kurz hinhalten, das sieht doch dann bei allen so
> aus.

Wenn die Löcher groß genug sind, verdrille und verzinne ich das vorher.
Dann ist auch alles schön "durchtränkt";-).
Kable, ja.. auf jeden Fall nicht die Flachkabel/Flachbandleitung von der 
Rolle.
Da ist meist zu wenig Kupfer dran.
Und nicht Dupond Kabel abschneiden und verlöten.
Das Zeugs läßt sich oft gar nicht löten, keine Ahnung was das für ein 
Stahldraht ist.

Beim Absiolieren keine der feinen Litzen abschneiden!!

und BLEILOT!

[Ziyat T. (toe_c)]

Werner schrieb:
> Hallo,
> Zunächst mal die Schaltung
> Beiliegend die Bilder.
>
> Der link oben
> https://discord.com/channels/984173303147155506/
> Bringt mich nicht weiter.
> Welchen Channel muß ich öffnen, mit welchem Thema.


>> Es ist ein HM 1000, HMS-1000-2T
>> Seriennummer = 11448016..

du hast angegeben dass du ein wr mit 1144 hast,
das ist ein wr der HMS serie,
den unterstützt die ahoy-dtu nicht!

[Werner (10kloc)]

Ok,
War wohl nix.

Kennt jemand eine Lösung für einen HMS 1000?

[Grisu (krisu)]

Mach hier weiter ...
Beitrag "Re: Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"

[Werner (10kloc)]

Vielen Dank für eure Unterstützung.

Der link oben https://discord.com/channels/984173303147155506/ Bringt 
mich nicht weiter. Welchen Channel muß ich öffnen, mit welchem Thema?

[Dirk (pip3000)]

Grisu schrieb:
> Litzen abisolieren, verdrillen, durchstecken und von unten mit etwas
> Zinn mit Flußmittel kurz hinhalten, das sieht doch dann bei allen so
> aus.

Ahh. Die sind durchgesteckt. Ich bin davon augegangen, dass ihr (wie 
ich) einen ESP32 habt, wo die Pins schon angelötet sind. Dort dann noch 
zusätzlich eine Litze dranlöten, stelle ich mir schwierig vor. Aber 
klar: Man braucht die Pins ja nicht zwingend - und wenn man's 
durchstecken kann, dann gehts.
Danke für die Antworten!

[Wolfgang B. (woltech)]

Joe G. schrieb:
> Eine Platine ist erfolgreich bestückt. Die Daten [1] sind somit
> freigegeben. Alle die eine Zusage zu einer Platine von mir haben,
> erhalten nun in den nächsten Tagen Post.
>
> [1] https://aisler.net/p/EAYHGSED

Danke fürs bereitstellen des Layouts. Hab eben welche geordert.

Gruß Wolfi

[Discodia (Gast)]

Ziyat T. schrieb:
> sonst ist die hilfe unter
> https://discord.com/channels/984173303147155506/ zu finden

Das scheint nicht ganz zu funktionieren, siehe Bild

[Ziyat T. (toe_c)]

Discodia schrieb:
> Ziyat T. schrieb:
>> sonst ist die hilfe unter
>> https://discord.com/channels/984173303147155506/ zu finden
>
> Das scheint nicht ganz zu funktionieren, siehe Bild

eigentlich den link brauche ich fast jeden tag, aber ev. diesen 
probieren

https://discord.gg/RxC4kx4z

[Alexander (Gast)]

Herzlichen Dank für das Board. Hab's mir besorgt und freue mich darauf 
meinen fliegenden Aufbau abzulösen. Kannst Du bitte kurz auflisten was 
für die komplette Bestückung noch nötig ist? Gerade die Kondensatoren. 
Vielen Dank Alexander

[Grisu (krisu)]

Den 100µ Elko (manche nehmen noch einen 100nF dazu), USB-Kabel (zur 
Versorgung) und Drähtchen, wenn du es fix verlöstest (was für die 
Funktion auch nur vorteilhaft ist).

[online user (Gast)]

Hallo,

wie stehen die Chancen, dass die HMS-Serie von Hoymiles auch von OpenDTU 
unterstützt wird?

Vielen Dank.

[Grisu (krisu)]

Sicher nie, da es ganz anders funktioniert bzw. aufgebaut ist.
Höchstens, daß es vielleicht einmal ein eigenes Projekt dazu gibt, wenn 
es einmal funktionieren sollte.
Hier kannst gern mitentwickeln: 
Beitrag "Re: Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"

[Andreas (dicc)]

Moin,

ich bekomme 5.28 nicht ans laufen, bis 5.17 alles ohne Probleme!
Das Teil geht noch dem flashen nicht in den AP Modus!
Habe den eindruck das Reste im Flashspeicher bleiben!

[Tobias K. (reserve)]

ja hatte ich auch, lösche den Flash einfach vorher dann sollte es 
funktionieren.

[Martin (Gast)]

Ist es per default so, dass die Zähler  (Total Yield Total/Day) nach 
einem reboot des WR zurückgesetzt werden bzw. neu starten? Hardware ist 
ein ESP32.

[Grisu (krisu)]

Nein eigentlich nicht, der Total zählt seit Erstinbetriebnahme bei mir 
hoch und dürfte im WR selbst abgelegt sein. Über Nacht machen sie doch 
täglich einen Reboot wenn sie ohne Licht völlig abdrehen.
Der tägliche setzt sich natürlich zurück, wenn du ihm den Saft nimmst 
oder rebootest.

[planlos (Gast)]

Grisu schrieb:
> Nein eigentlich nicht, der Total zählt seit Erstinbetriebnahme bei mir
> hoch und dürfte im WR selbst abgelegt sein. Über Nacht machen sie doch
> täglich einen Reboot wenn sie ohne Licht völlig abdrehen.
> Der tägliche setzt sich natürlich zurück, wenn du ihm den Saft nimmst
> oder rebootest.

Kann ich so bestätigen.

[Ulrich K. (ulrich65)]

Ich warte im Moment auf Solarpanels und einen Hoymiles HM-600 
Wechselrichter und möchte die Ahoy DTU verwenden. Mein Problem ist, daß 
ich am Aufstellort der Panels kein WLAN habe (Gartenhausdach mit einigen 
Hindernissen).

Ich möchte auch keine zusätzlichen WLAN Aussenantennen installieren, um 
nicht die ganze Gegend übermäßig mit meinen Signalen zu belästigen.

Da ich seit längerem eine kleine LoRa, bzw. LoRaWan Infrastruktur über 
TTN mit einem Indoor Gateway und einigen Sensoren am Laufen habe, wollte 
ich die Datenweitergabe der DTU über LoRa implementieren.

Der erste Ansatz war die Portierung des Ahoy Codes auf meine LoRa 
Platformen. Ich verwende Heltec Lora 151 Nodes mit STM32L151 MCU und 
Nodes mit AtTiny3216.

Sinnvoller wäre aber doch eher die Möglichkeit, die Daten der Ahoy DTU 
über eine der gängigen Schnittstellen wie z.B. I2C anzapfbar zu machen. 
Also den LoRa Node an die DTU zu hängen.

Jetzt die eigentliche Frage:

Hat ausser mir noch jemand ähnliche Anforderungen und würde es Sinn 
machen, eine entsprechende Schnittstelle in die Ahoy DTU zu integrieren? 
Evtl. als optionale Möglichkeit über Defines.

[Frank G. (frankgef)]

Ich habe gerade 3 Tsol M800 an der DTU hängen. Geht einwandfrei. 
Nochmals vielen Dank.

[Andre (Gast)]

Hallo zusammen,

auch von mir erst mal ein herzliches Dankeschön and die Akteure hier.
Ich bin mit der exakt gleichen Fragestellung nach der Regelung der 
Hoymiles ohne den Kauf einer (sauteuren) DTU Pro vor 2 Wochen auf diese 
Seite gestoßen.
Mittlerweile habe ich 3 Hoymiles (1xHM-600, 2xHM-1500) mit 9 
405Wp-Modulen installiert.
Eure systematische Herangehensweise finde ich klasse !!! Und natürlich 
das Ergebnis.
Da ich alles, was ich brauchte, sowieso aus anderen Projekten hier 
herumliegen hatte, habe ich gestern mal den ESP8266m, den NRF24L01+ und 
die Kabel zusammengesteckt, das NodeMCU Flash und die 0.5.28 
heruntergeladen und auf den ESP geflasht. Funktionierte wunderbar.
Einrichten des WLANs mit Einbindung in mein existierendes ging auch und 
alle 3 Hoymiles wurden richtig erkannt.
Heute am sonnigen Tag gingen dann auch alle Hoymiles ins Netz und 
lieferten ihre Daten. Das taten sie allerdings nicht immer direkt 
vollzählig. Ich denke, dort muss ich noch den optimalen Aufstellungsort 
finden.
Aber für einen ersten Start bin ich super zufrieden.
Auch das Limitieren der Leistung hat einwandfrei funktioniert. Wobei 
aber noch zu sagen bleibt, dass eine Limitierung auf eine Wattzahl auch 
eine prozentuale Limitierung mit sich bringt. Limitiere ich den HM-1500 
auf 500 Watt, so wird er bei 600 Watt Sonnen-Leistung auch nur 200 Watt 
bringen.

Jetzt bleibt nur noch die Erstellung eines io-Boker-Servers.

Gruß
André

[Grisu (krisu)]

Das hätte ich jetzt so bei meinen nicht festgestellt, da war das Limit 
immer auf den Max-Wert bezogen, obgleich ich mit der 0.5.28 nur mehr in 
Watt einstellen kann und sich bei % nichts tut. 50% bedeuten also eine 
Limitierung auf 750W beim HM-1500 und nicht eine Halbierung des aktuell 
gerade erzeugten bzw. möglichen Wertes.
Das ginge m.E. ja auch gar nicht, da er den aktuell möglichen Wert nicht 
kennt oder mißt um ihn überhaupt halbieren zu können.

[Alexander H. (agentsmith1612)]

Mal eine ganz andere Frage:
Die DTU zeichnet ja nichts selber auf, kann aber MQTT.

Gerne würde ich das ganze Aufzeichnen und Visualisieren, wie mache ich 
das am besten?

Ich habe schon viel gelesen und ausprobiert, hatte sogar einen IT 
Studenten (gegen Bezahlung) mal daran der irgendwas gemacht hat aber 
auch nicht hinbekommen hat.
Ich besitze eine Synology DS 220+.
Raspeberry Pi würde ich auch verwenden sind aber derzeit unverschämt 
teuer.

Ich selber habe diverse Male ioborker per Docker probiert bekomme aber 
keine Verbindung hin.
Der Student hat irgendwas von Mosquitto Sever installiert, Influx 
Datenbank und Grafana.
Funktionierte aber an einigen Stellen nicht und jetzt meldet er sich 
nicht mehr.

Gibt es irgendwo eine Seite oder irgendjemand der mir das einfach 
erklären kann was ich machen muss? Das ganze was ich bis jetzt gelesen 
habe und gemacht wurde ist für mich Raketenwissenschaft.
Das kann doch insgesamt nicht so schwer sein einfache Datenpunkte 
aufzunehmen und zu visualisieren?

Denn ich habe auch noch einen IR Lesekopf an meinem Stromzähler der auch 
MQTT kann und dann würde ich beides gerne übereinanderlegen. Nur per 
Browser den gerade ist Wert abrufen bringt mir nicht viel.

[revilo (Gast)]

Hallo habe ein HM-1200 ,
der Serien Nummer fängt mit 1061 an .. der wird nicht erkannt von Ahoy . 
Wie bekomme ich den zum laufen ?

[Alexander H. (agentsmith1612)]

revilo schrieb:
> Hallo habe ein HM-1200 ,
> der Serien Nummer fängt mit 1061 an .. der wird nicht erkannt von Ahoy .
> Wie bekomme ich den zum laufen ?


Laut Seriennummernliste hast du mit der 1061 einen MI-1200.

HM-1xxx haben 1161.

Ob das einen Unterschied macht ob HM oder MI weiß ich nicht.

[revilo (Gast)]

Ok , danke für den Hinweis ..

da gibts schon mögliche Ansatzpunkte zur Integration:

https://github.com/lumapu/ahoy/issues/258

[Ulrich K. (ulrich65)]

@Alexander H

Erst mal die Frage: Worauf hat Dein Student Mosquitto, Influx, etc. 
installiert?

Die Ahoy DTU und der IR Lesekopf produzieren Daten und können diese an 
einen MQTT Broker (z.B. Mosquitto, ==> publish) weitergeben. Dort können 
die Daten von Interessenten abonniert werden (==> subscribe) und 
weiterverarbeitet werden. Wenn Du aus diesen Daten Grafiken oder 
Statistiken erzeugen willst, mußt Du natürlich mindestens die Daten aus 
dem interessierenden Zeitraum parat haben. Dafür brauchst Du eine 
Datenbank (z.B. InfluxDB, Zeitreihen-Datenbank). Die eigentlichen 
Diagramme kannst Du dann z.B. mit Grafana erzeugen.

Damit das funktioniert, müssen mindestens der MQTT Broker und die 
Datenbank permanent laufen, oder zumindest in der Zeit, in der Daten 
entstehen. Da käme dann der Raspberry Pi als kleiner sparsamer Server 
ins Spiel. Darum meine Frage oben nach dem Installationsort.

Ich hatte zum Thema Stromzähler vor ein paar Tagen schon mal was 
geschrieben:

Beitrag "Re: Tasmota / Volkszähler - Wie fängt man an?"

Unter dem Blickwinkel ist die Ahoy DTU nur ein weiterer Datenproduzent.

Zusammengefaßt könnte es so aussehen:

1. diverse Datenquellen (Stromzähler, Ahoy DTU, Wettersensoren, usw.) 
publizieren Daten per MQTT
2. MQTT Broker vermittelt die Daten an Interessenten
3. Aufbereiten der Daten des MQTT Brokers (grafisch z.B. mit NodeRed, 
oder per Config-Datei mit Telegraf)
4. Weitergabe der aufbereiteten Daten an die Zeitreihen-Datenbank
5. Erzeugen von Grafiken, Statistiken aus den Zeitreihen-Daten

Die Verwendung eines MQTT Brokers ist maximal flexibel: Wer Daten 
produziert, stellt sie dort bereit und wer sich für die Daten 
interessiert, holt sie dort ab. Nichts ist fest verdrahtet und 
Produzenten und Konsumenten sind voneinander unabhängig.

Was Tools wie ioBroker, HomeAssistant hier übernehmen können, weiß ich 
nicht. Ich baue mir bisher lieber alles aus Einzelkomponenten zusammen 
und habe auch keinen Bedarf für eine Hausautomatisierung. Ich wollte 
mich aber demnächst mal damit befassen.

In Deinem Fall böte es sich an, die Zeitreihen-Datenbank auf dem NAS zu 
installieren, wenn das geht. Auch damit habe ich keine Erfahrung. Wenn 
das NAS Betriebssystem mit Docker klarkommt, kannst Du natürlich auch 
alle nötigen Dienste dort als Container laufen lassen. Mosquitto, 
NodeRed und InfluxDB sind nicht besonders resourcenintensiv und laufen 
bei mir problemlos neben einigen anderen Diensten auf einem RPi4 mit 4 
GByte RAM.

[Ziyat T. (toe_c)]

revilo schrieb:
> Hallo habe ein HM-1200 ,
> der Serien Nummer fängt mit 1061 an .. der wird nicht erkannt von Ahoy .
> Wie bekomme ich den zum laufen ?

1061 ist ein MI1500/MI1200 und kann mit ahoy nicht ausgelesen werden!
für MI gibts:
https://github.com/Ziyatoe/DTUsimMI-Hoymiles

[CrazyJ (Gast)]

@ Alexander H.
Genau so wie du es vor hast, habe ich es schon zum Teil umgesetzt.
Habe auf meiner Synology im Docker Container den IOBroker installiert.
Dort dann über MQTT und andere Adapter bekomme ich dann die Daten.
Unter anderem vom Stromzähler und HM600.
Zur einfachen Verarbeitung habe ich noch ein Java Skript aus dem 
Internet etwas modifiziert (für Speicherung der Werte gestern, letzte 
Woche, letztes Jahr).
Darüber hinaus verwende ich Flot für Diagramme und Vis für die 
Visualisierung (am einfachsten und am schnellsten).
Besser ist wohl Influx und Grafana, erschien mir aber für den Anfang zu 
kompliziert.

[Thomas (Gast)]

Alexander H. schrieb:
> Ich selber habe diverse Male ioborker per Docker probiert bekomme aber
> keine Verbindung hin.
> Der Student hat irgendwas von Mosquitto Sever installiert, Influx
> Datenbank und Grafana.
> Funktionierte aber an einigen Stellen nicht und jetzt meldet er sich
> nicht mehr.

Hallo,
ich habe es nach dieser Anleitung gemacht, läuft absolut stabil seit 2 
Wochen

https://schroederdennis.de/tutorial-howto/shelly-tasmota-mqtt-node-red-influxdb-ins-grafana-dashboard-anleitung/

https://grafana.com/grafana/dashboards/16850-pv-power-ahoy/

[Sonixx (Gast)]

Vielen Dank,
Jetzt muss ich mich mal Dumm stellen. Die Hardware ist vorhanden jedoch 
habe ich keine Ahnung wie ich das Programm von 
https://github.com/Ziyatoe/DTUsimMI-Hoymiles auf meinen ESP8266 bekomme. 
Bei meinem HM habe ich es über https://ahoydtu.de gemacht was für mich 
kein Problem war.
Vll kann mir das hier jemand Step for Step erklären oder mir eine 
Anleitung schicken. An [e-mail]

[Grisu (krisu)]

Ich konnte die .bin es mit esptool-v4.2.1-win64.zip am Win-PC hochladen.

[tic (Gast)]

Vielen Dank für die geleistete Arbeit.

Ich hab mir openDTU von tnobody zusammengebaut, alles funktioniert 
einwandfrei.

Allerdings, seit ich eine DTU pro parallel betreibe, gibt es Störungen 
bei der Übertragung. Ist da irgendwas bekannt oder irgendwas zu 
beachten? openDTU und DTU pro haben jeder seine eigene SerialId.

Ich habe eine DTU pro und einen HM-1500 falls ich irgendwas mit meinen 
begrenzten Mitteln beitragen kann.

[Grisu (krisu)]

Darfst ja auch nur mit einer DTU verbinden, also entweder oder.
Zumindest nicht die selben S/N (Wechselrichter) auf beiden verwenden, 
steht schon lang früher wo (glaub sogar mehrfach) in diesem 
Endlosthread.

[Ziyat T. (toe_c)]

Sonixx schrieb:
> Vielen Dank,
> Jetzt muss ich mich mal Dumm stellen. Die Hardware ist vorhanden jedoch
> habe ich keine Ahnung wie ich das Programm von
> https://github.com/Ziyatoe/DTUsimMI-Hoymiles auf meinen ESP8266 bekomme.
> Bei meinem HM habe ich es über https://ahoydtu.de gemacht was für mich
> kein Problem war.
> Vll kann mir das hier jemand Step for Step erklären oder mir eine
> Anleitung schicken. An [e-mail]

geht es um HM oder MI?
falls MI:
unter https://github.com/Ziyatoe/DTUsimMI-Hoymiles gibt es kein binary 
file; dort gibts ja ein readme, und es steht dort, dass man die 
arduino-ide braucht, nicht?

[Sonixx (Gast)]

Ok Danke,
ArduinoIDE habe ich aber wie gehts jetz weiter, wie bekomme ich die 
dateien auf den chip oder so ähnlich?

[Ziyat T. (toe_c)]

Sonixx schrieb:
> Ok Danke,
> ArduinoIDE habe ich aber wie gehts jetz weiter, wie bekomme ich die
> dateien auf den chip oder so ähnlich?


google hilft da vielleicht weiter:
https://randomnerdtutorials.com/how-to-install-esp8266-board-arduino-ide/

[Grisu (krisu)]

Seit der 0.5.41 findet sie nach einem Neustart bei mir den Zeitserver 
nicht mehr (DHCP). Muß dann immer zuerst auf "vom Browser übernehmen" 
klicken.
Hat das noch jemand?

[SE (Gast)]

Kann ich so bestätigen. Man kann im Setup auch auf NTP Sync nach einiger 
Zeit drücken. Vorher gibt es offenbar Probleme mit der Namensauflösung.

[Manfred H. (mhen)]

Ich habe eben ein Update aus der "ahoy-dtu" heraus von 0.5.28 auf 
v0.5.41 durchgeführt, endet mit der Meldung "... success, ... reboot in 
20 sec".
Dann kommt aber zunächst der eigene Accesspoint "AHOY-DTU", mit dem ich 
mich verbinden kann, aber der Webserver reagiert nicht auf die IP 
192.168.1.1 !??
Habe ich irgendetwas falsch verstanden mit dem OTA-Update?

[Grisu (krisu)]

Dürfte sich wohl zu viel verändert haben und man muß alles neu 
konfigurieren, war bei mir auch so.

[Manfred H. (mhen)]

Ja, sieht so aus.
Zum neu konfigurieren müsste ich aber schon den eingebauten webserver 
bemühen.
Also nun einfach den/das *.bin File (mit esp-flasher-x86) geflasht, 
offenbar erfolgreich, denn in dessen Terminal sehe ich erste 
Lebensäußerungen, dass z.B. das nRF24-Modul nicht gefunden wird. Stimmt, 
ich habe es ja an D8/D1/D2 angeflanscht.
Also Laptop mit dem Ahoy-eigenen Accesspoint verbunden, die Startseite 
auf 192.168.1.1 aufgerufen ... keine Chance, irgendwann kommt time-out.
Grundsätzlich läuft der Wemos D1, beim Start blinkt die blaue LED einmal 
kurz (wie schon vorher) und nun noch einmal deutlich länger.

Gleich schiebe ich noch einmal die v0.5.28 auf den Chip, sollte ja 
weiterhin funktionieren.

[Gerri (Gast)]

Manfred H. schrieb:
> aber der Webserver reagiert nicht auf die IP
> 192.168.1.1 !??

... nimm mal wie in der Dokumentation beschrieben ist, die 192.168.4.1 !

[Manfred H. (mhen)]

Manfred H. schrieb:
> Gleich schiebe ich noch einmal die v0.5.28 auf den Chip, sollte ja
> weiterhin funktionieren.

Jetzt wird es kurios:
soeben die Version 0.5.28 geflasht (Win10, esp-flasher-x86), aber dieses 
Mal das Terminal offen gelassen. Etliche Meldungen, Systemparameter usw. 
laufen durch, zuletzt eine time-out Meldung, dass der AP (ahoy-dtu) in 
60 Sek. geschlossen wird, in 45 Sek., in 30 Sek. usw.
Nun das Laptop mit diesem AP verbunden, rödelt hier ziemlich lange 
herum, während im Terminal sich eine Meldung wiederholt: "1 client 
connected" und "AP closed in xx sec." oder ähnlich.
Windows meldet "verbunden", ok.
Im Firefox die IP 192.168.1.1 aufgerufen, die Eingangsseite vom 
"ahoy-dtu" erscheint in voller Schönheit und ich könnte jetzt alles so 
konfigurieren, wie ich es gerne hätte.
Ich kann aber auch gleich das OTA Update machen ... ;-)
Auf der entsprechenden Seite mit dem Update-Button und der Dialogzeile, 
um den passenden File auf dem Rechner aufzusuchen, bin ich mit dem 
Finger etwas schneller als mit dem Kopf und betätige den Update-Button 
bei leerer Adresszeile!
Weniger als eine Sekunde später erscheint die Meldung "update 
successful" oder ähnlich und "reboot in 20 sec." ;-)
Der Laptop verliert die Verbindung zum AHOY-DTU Accesspoint, kann wieder 
verbunden werden, aber nun klappt der Aufruf der Startseite unter 
192.168.1.1 nicht mehr!!
Erkenntnis? Ich kann die Version 0.5.28 flashen, einrichten und 
verwenden,
ich kann die Version 0.5.41 auch flashen, aber nicht einrichten oder gar 
verwenden (gleicher Laptop, gleiches Win10, gleicher WEMOS D1 mini, 
gleiches Kabel, gleiche Powerbank zur Versorgung).

[Manfred H. (mhen)]

Gerri schrieb:
> Manfred H. schrieb:
>> aber der Webserver reagiert nicht auf die IP
>> 192.168.1.1 !??
>
> ... nimm mal wie in der Dokumentation beschrieben ist, die 192.168.4.1 !
oh, tatsächlich!
Ich musste erst noch einmal umflashen auf die Version 0.5.41, aber jetzt 
klappt es!
Besten Dank!!

Edit:
was ich jetzt nicht noch einmal probiert habe, ob das OTA-Update nun 
klappt.

[Ralf Thielecke (Gast)]

Hallo,

Zunächst einmal vielen lieben Dank an alle, die das Projekt entwickelt 
haben. Das Forum liest sich vom Start weg wie die Ermittlungen in einem 
Krimi.

Das Setup mit einem eps8266 lief bei mir vom Start weg rund mit einem 
Inverter der Serie 1141########. Als MQTT-Broker habe ich Mosquito auf 
einem Raspberry Pi laufen, dahinter eine Node-Red Instanz zum spielen 
mit einem Dasboard.

Um etwas zum Projekt beizutragen, würde ich den Node-Red- Flow hier 
posten. Wäre das OK? Oder besser woanders?

Gruß, Ralf Thielecke
(Der so blöd ist, Ende November eine Solaranlage zu bauen)

[Herbert K. (avr-herbi)]

Ralf Thielecke schrieb:
> Um etwas zum Projekt beizutragen, würde ich den Node-Red- Flow hier
> posten. Wäre das OK? Oder besser woanders?
Hallo Ralf,
vielleicht direkt im github? Dort zusammen mit allen anderen Dokus macht 
vielleicht am meisten Sinn? Das wäre so mein Vorschlag.
Später hier suchen ist dann fast wie ne Stecknadel im Heuhaufen.
Viele Grüße Herbert

[Herbert S. (herbert_s445)]

Hallo,

ich wollte gerade mein DTU-AHOY von 5.17 auf 5.41 upgraden. Im 
Release-Paket finden sich die Dateien:
 221119_ahoy_0.5.41_esp8266_dec333f.bin
 221119_ahoy_0.5.41_esp8266_1m_dec333f.bin

welche Datei sollte ich zum flashen verwenden bzw. was ist der 
Unterschied?

Danke für die Unterstützung

Herbert

[Grisu (krisu)]

Die Antwort findest hier (1MB Variante für ESP8265), wenns stimmt:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Testcase (Gast)]

Ist in den HM-600/700/800er wirklich eine andere Hardware verbaut oder 
kann die Leistungsbegrenzung theoretisch auch über das Maximum gebracht 
werden?
Also der HM-600 auf zB. HM-700 umparametriert werden?

Frage für einen Freund... ;)

[Grisu (krisu)]

Die HW wird schon wohl sehr ähnlich sein, aber auch fix hinterlegt der 
unverändliche Max-Wert.
Dies ist auch nötig, da die Leistungskomponenten und Elkos dafür 
ausgelegt sein müssen inkl. Kühlung.
Also selbst wenn du öffnest und umprogrammieren könntest würdest 
niemandem einen Gefallen erweisen, allenfalls der Wirtschaft durch 
baldigen Neukauf.

[Alexander H. (agentsmith1612)]

@Ulrich K.
Erstmal vielen Dank für deine Erläuterungen:
Alles läuft bis jetzt auf einer Synology DS220+ im Docker.

Ich habe soweit alles verstanden was du schreibst und mir leuchtet das 
auch ein. Das Problem ist das Wie.
Wo muss ich was drücken, wie installiere ich was und wo muss ich was 
einstellen. Das ist mein größtes Problem, ich bin kein ITler und Dokus 
von solchen Dingen sehen für mich teilweise so aus wie für manche das 
Periodensystem. Ich verstehe manche Dokus schon, weiß aber dann dennoch 
nicht was ich für meinen Anwendungsfall machen und einstellen muss.
Oder anders gesagt nur weil man die Straßenverkehrsordnung versteht kann 
man ja auch noch kein Auto bedienen. ;-)

Bis jetzt habe ich mit jemand anderem auf Synology im Docker den MQTT 
Broker zum laufen bekommen und auch Verbindung mit meinen Geräten 
bekommen.

Jetut klemmt es an der Übertragung der Daten vom Broker in die 
Influx-Datenbank, dazu braucht man eine Art Übersetzter namens Telegraf, 
es klemmt weil uns die Config für Telegraf noch nicht ganz klar ist was 
wir einstellen müssen.

ICh glaube hier sind auch mehrere Leute die das genau so machen oder 
zumindest hier mal erwähnt hatten.

Naja wir probieren uns weiter durch.

[Hoschbaer (Gast)]

Hallo zusammen,

ich wollte gerade die Software über AhoyDTU aufspielen.
Allerdings kommt jedes mal die folgende Fehlermeldung:

Failed to initialize. Try resetting your device or holding the BOOT 
button while clicking INSTALL.

Ein Resett bringt keine Veränderung.

Habt ihr einen Tip für mich?

Vielen Dank!

[Joe G. (feinmechaniker)]

Alexander H. schrieb:
> Jetut klemmt es an der Übertragung der Daten vom Broker in die
> Influx-Datenbank, dazu braucht man eine Art Übersetzter namens Telegraf,
> es klemmt weil uns die Config für Telegraf noch nicht ganz klar ist was
> wir einstellen müssen.

Du installierst den MQTT-Adapter im IOBroker.
Du installierst den influxdb-Adapter im IOBrocker.
Du ordnest dem Datenpunkt welchen du in der Datenbank speichern möchtest 
die Datenbank zu (Zahnrad).
Jetzt kannst du mit einem Dashboard, z.B. Grafana, die Daten aus der 
Datenbank visualisieren.

[LittleHelper (Gast)]

Hoschbaer schrieb:
> Habt ihr einen Tip für mich?

ESP D1-Mini flashen:
Beim "PowerUp" des ESP "GND" und "D3" verbinden.

HTH

[John P. (brushlesspower)]

Mein HM 400 wird heute ungewohnt warm ;)

[Grisu (krisu)]

Hatte doch schon jemand hier gepostet, daß negative Temperaturen binär 
offensichtlich nicht berücksichtig wurden.
Irgendwo hab ich das schon mal gelesen, finde aber nichts mehr, 
vielleicht wurde es wieder gelöscht.
Mußt halt vom Wert 6553,5 abziehen oder so ähnlich.
Oder du baust es zum Fusionsreaktor um.

[Frank W. (Firma: DB1FW) (frankw)]

John P. schrieb:
> Mein HM 400 wird heute ungewohnt warm ;)

Meiner hat :  Temperature   6.552,90 °C

Habe gestern im Forum bei Github nachgefragt.

Das Problem ist bekannt und bereits bearbeitet und erledigt.

     Siehe #432 und #246
     Das Problem wurde am 20. Oktober behoben....

( https://github.com/tbnobody/OpenDTU/discussions/445 )

Also doch mal neue Software aufspielen.
Habe bisher kein Update gemacht, weil mein openDTU seit Monaten 
friedlich und zuverlässig funktioniert hat. Da gab es keine Grund.

Gruss Frank

[John P. (brushlesspower)]

Frank W. schrieb:
> Habe bisher kein Update gemacht, weil mein openDTU seit Monaten
> friedlich und zuverlässig funktioniert hat. Da gab es keine Grund.

Sehe ich ganz genauso.
Da ist es mir auch wurscht welche Temperatur er anzeigt.

Offtopic:
Was ist besser?
Das Solarpanel mit frost überzogen lassen?
Oder halb von Frost befreien?

Komme nicht komplett ran und das halbe freikratzen zeigte wenig Wirkung.

[Grisu (krisu)]

Naja, sobald die Sonne kommt wird es dort beginnend wo schon schwarz ist 
sodann schneller wegschmelzen, somit ist es sicher kein Nachteil was 
halt geht entfernen.
Nur glaub ich nicht, daß die Oberflächen sehr entzückt sind wenn du mit 
dem Schaber anrückst. Gefrorenes würd ich persönlich daher eher lassen 
und warten. Schnee runterwischen hingegen reinigt sie ja sogar.

[Alexander H. (agentsmith1612)]

Joe G. schrieb:
> Du installierst den MQTT-Adapter im IOBroker.
> Du installierst den influxdb-Adapter im IOBrocker.
> Du ordnest dem Datenpunkt welchen du in der Datenbank speichern möchtest
> die Datenbank zu (Zahnrad).
> Jetzt kannst du mit einem Dashboard, z.B. Grafana, die Daten aus der
> Datenbank visualisieren.

Dieser Weg war mir noch nicht bewusst, das das funktioniert. Mein 
Problem mit iobroker war das ich zwar den MQTT Adapter installieren kann 
aber der meine Adapter (DTU und Tasmota aufm Stromzähler) nicht findet.
Auch auf der DTU steht dann immer MQTT not connected. Habe schon alles 
versucht, mir wurde im ioborker Forum gesagt das das an meiner Synology 
und Docker liegt, ich solle doch einen Pi oder irgendso einen Fujitsu 
Kram nehmen. Auf meine Frage ob mir jemand dabei helfen kann oder es 
Anleitungen gibt wurde nicht reagiert.

[Joe G. (feinmechaniker)]

Zur Überprüfung und Test einer MQTT-Verbindung finde ich den MQTT 
Explorer [1] sehr hilfreich. Damit kannst du zunächst prinzipiell 
überprüfen, ob du dich mit dem MQTT Adapter vom IOBrocker verbinden 
kannst. Wenn das nicht funktioniert, dann bekommt die AhoiDTU auch keine 
Verbindung.

[1] http://mqtt-explorer.com/

[CrazyJ (Gast)]

@ Alexander H.
Kann mir nicht vorstellen, dass es an der Synology und am Docker liegt.
Was hast denn in der mqtt Instanz im iobroker eingestellt.
Hast den gestartet?
Gleiche/richtige Einstellungen im DTU / Tasmota?

[M. P. (matze7779)]

Alexander H. schrieb:
> meiner Synology
> und Docker liegt

Hast Du den Port an den Container weitergeleitet?

[Vapo (Gast)]

Hallo
Habe hier 2 HM 1200 mit Seriennummer 1168 bekommen würden die auch mit 
OpenDTU funktionieren?

Gruß

[Thomas B. (tbnobody)]

Vapo schrieb:
> Hallo
> Habe hier 2 HM 1200 mit Seriennummer 1168 bekommen würden die auch mit
> OpenDTU funktionieren?
>
> Gruß

100% Versprechen kann ich es natürlich nicht, aber wenn ich eine 
Seriennummer eingebe die mit 1168 beginnt wird diese zumindest korrekt 
als HM-1200 identifiziert.

[Vapo (Gast)]

Danke das hört sich doch schonmal gut.

[Christian (nordichris)]

Danke erstmal an alle für das Super Tool.
Ahoy funktioniert erstmal einwandfrei.
ABER leider habe ich für meinen gebraucht gekauften HM-300 KEINE 
Seriennummer (nicht mehr lesbar).
Gibt es eine Möglichkeit den Inverter trotzdem zu integrieren?
Dummynummer, irgendwie auslesen, .....
Merci schon mal
VG Christian

[Uli (Gast)]

Seitdem ich dies Projekt vor ein par Monaten gefunden habe, bin ich 
begeistert. Inzwischen habe ich auch eine leise Ahnung, was Ihr hier auf 
die Beine stellt. Aber verstehen tue ich davon noch immer nicht viel. 
Und jetzt komme ich nicht weiter.

Ich habe ein D1 Mini ESP8266-12F v3 Modul von AZ-Delivery mit 
221119_ahoy_0.5.41_esp8266_dec333f.bin als Firmware, dass über den 
USB-Anschluss versorgt wird. Am 3,3V-Ausgang ist ein 100µF Kondensator. 
Inzwischen wird das Funkmodul durch ein Adapaterboard von AZ-Delivery 
versorgt, das am 5V-Pin des D1 Mini angeschlossen ist, versorgt. Als 
Funkmodul habe ich ein  nRF24L01+ Modul von AZ-Delivery mit Antenne auf 
der Platine und ein NRF24L01+PA+LNA Wireless Transceiver RF Transceiver 
Module with SMA Antenna 2.4G von Hailege. Verbunden werden soll mit 
einem HM-1200. Der war auch schon mal mit einem geliehenen DTU-Stick von 
Hoymiles verbunden.

Beide Funkmodule habe ich getestet mit unterschiedlichen Ausrichtungen, 
Entfernungen, Sendeleitungen und vertauschten CE und IRQ. Die 
Seriennummer ist mehrfach überprüft, unten ersetzt. In allen Varianten 
bekommen ich dieselben Ausgaben in der Console:

n/a09:12:26 I: [NTP]: 2022-12-27 08:12:26 UTC
09:12:36 I: enqueued cmd failed/timeout
09:12:36 I: (#0) I: no Payload received! (retransmits: 0)
09:12:36 I: resetPayload: id: 0
09:12:36 I: (#0) Requesting Inv SN 1161xxxxxx41
09:12:36 I: (#0) enqueuedCmd: 11
09:12:36 I: (#0) enqueuedCmd: 1
09:12:36 I: (#0) enqueuedCmd: 5
09:12:36 I: (#0) sendTimePacket
09:12:36 I: TX 27B Ch40 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b 
09:12:37 W: while retrieving data: last frame missing: Request Retransmit
09:12:37 I: (#0) sendTimePacket
09:12:37 I: TX 27B Ch61 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b 
09:12:39 W: while retrieving data: last frame missing: Request Retransmit
09:12:39 I: (#0) sendTimePacket
09:12:39 I: TX 27B Ch75 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b 
09:12:41 W: while retrieving data: last frame missing: Request Retransmit
09:12:41 I: (#0) sendTimePacket
09:12:41 I: TX 27B Ch3 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b 
09:12:43 W: while retrieving data: last frame missing: Request Retransmit
09:12:43 I: (#0) sendTimePacket
09:12:43 I: TX 27B Ch23 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b 
09:12:46 W: while retrieving data: last frame missing: Request Retransmit
09:12:46 I: (#0) sendTimePacket
09:12:46 I: TX 27B Ch40 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b

Hab Ihr einen Tip für mich? Besten Dank

[Andreas (dicc)]

Christian schrieb:
> Danke erstmal an alle für das Super Tool.
> Ahoy funktioniert erstmal einwandfrei.
> ABER leider habe ich für meinen gebraucht gekauften HM-300 KEINE
> Seriennummer (nicht mehr lesbar).
> Gibt es eine Möglichkeit den Inverter trotzdem zu integrieren?
> Dummynummer, irgendwie auslesen, .....
> Merci schon mal
> VG Christian
Moin evlt. mal aufschrauben vielleicht steht dort nochmal irgendwo die 
Sn!?

[Andreas (dicc)]

LittleHelper schrieb:
> Hoschbaer schrieb:
>> Habt ihr einen Tip für mich?
>
> ESP D1-Mini flashen:
> Beim "PowerUp" des ESP "GND" und "D3" verbinden.
>
> HTH
Was passiert dann?

[Lukas P. (lumapu)]

Lange gabs von mir hier nichts neues. Heute habe ich ein neues Release 
veröffentlicht:

https://ahoydtu.de/web_install/
https://github.com/lumapu/ahoy/releases/tag/ahoy_v0.5.66

Ich hoffe, dass mit dieser Version das neue Jahr einen guten Auftakt 
haben wird. Vielen Dank an alle, die hier mitgewirkt haben! Echt enorm 
was sich in den letzten 9 Monaten entwickelt hat.

Nächstes Jahr können wir hoffentlich endlich mit den HMS und HMT 
Invertern durchstarten.

Viele Grüße und einen guten Rutsch allerseits!

[Grisu (krisu)]

Zur Info falls andere auch suchen, weil keine Werte mehr kommen:
Nach dem Update wurde kein WR mehr gefunden (überall gelbe Rufzeichen).
Mußte in den Einstellungen erst bei jedem das Häkchen für "Communication 
Enable" setzen, das es früher gar nicht gab und nun offensichtlich per 
Default aus war.
Das Feld übersieht man auch recht leicht mal, wenn man es nicht 
erwartet.

Ansonst Hut ab vor dem gesamten Projekt und dessen Fortschritt!!!
Auch daß es Bestrebungen bezügl. HMT gibt stimmt mich sehr froh.

DANKE allen Mitwirkenden!

[Grisu (krisu)]

Lukas P. schrieb:
> Lange gabs von mir hier nichts neues. Heute habe ich ein neues Release
> veröffentlicht:

Darf ich dir hier einen "Verbesserungsvorschlag" einbringen?
Die Reihenfolge der Felder ist m.E. verbesserungswürdig.
Damit man die wesentlichen Infos in logischer Reihenfolge zuerst sieht 
und auch an den selben Positionen bei 'Total' und den einzelnen 
Wechselrichtern möchte ich folgende Anordnung vorschlagen bzw. 
diskutieren.
(Die Panel-Ansicht finde ich ok wie sie ist ohne Änderungsbesdarf.)

                               Total
---------------- ---------------- ---------------- ----------------
[W] P_AC         [var] Q_AC       [Wh] YieldDay    [kWh] YieldTotal
---------------- ---------------- ---------------- ----------------
[W] P_DC

                               1. WR
---------------- ---------------- ---------------- ----------------
[W] P_AC         [var] Q_AC       [Wh] YieldDay    [kWh] YieldTotal
---------------- ---------------- ---------------- ----------------
[V] U_AC         [A] I_AC         [Hz] F_AC        [] PF_AC
---------------- ---------------- ---------------- ----------------
[W] P_DC         [%] Efficiency   [°C] Temp

[Sorbit (Gast)]

Hallo,

es ist wohl möglich ein Display OLED 1306 anzuschließen ( Ahoy)
Wo ist dokumentiert wie es angeschlossen wird?

Frohes Neues!

[Gerri (Gast)]

@Sorbit
... gugst du! https://github.com/lumapu/ahoy/pull/401

[Sorbit (Gast)]

Danke, ich probiere es in den nächsten Tagen mal aus…

[Sorbit (Gast)]

Danke, ich probiere es in den nächsten Tagen mal aus…

[bloedkolben (Gast)]

Hallo,

erstmal habe ich heute fast den ganzen Nachmittag verbracht, diesen 
Thread zu lesen - das liest sich wie ein Krimi. Ich mag solche 
Forschungen und die Teamarbeit - ein großes Danke und "Chapeau" an alle 
Beteiligten.
Da ich gestern zum ersten Mal eher zufällig von Ahoy-DTU gehört habe, 
habe ich kurzentschlossen einen Beutel 24L01+-Module bestellt, ESPs habe 
ich noch haufenweise. Ein Hoymiles-WR hängt seit 1. November in der Nähe 
meiner 3 Module und trägt seinen Teil dazu bei, dass die Energiekosten 
hier etwas gedämpft werden. Eine geregelte Speicherung (Ziel der 
Nulleinspeisung) folgt noch im Frühjahr.

Um dann HEUTE zu lesen, dass die HMS und HMT-Serie auf einer ganz 
anderen Frequenz funkt und dazu wohl wenig bekannt ist.
Ich bin Elektroniker, kein Programmierer. Habe einen HMT-1800 im 
Einsatz, der aber bisher eher vergeblich auf irgendwelche Funksignale 
hört. Toll, zu hören, dass es hier ebenfalls in der Planung ist.
Somit denke ich, dass ich beim Testen und Debuggen helfen kann, die 
Werte des WR hätte ich nämlich auch gern im ioBroker, der bei mir im 
Keller auf einem Raspi Daten sammelt, als gäbe es kein Morgen mehr.
Daumen hoch und auf ein tolles 2023 mit neuen Erkenntnissen!

Stefan

[Stefan F. (bloedkolben)]

bloedkolben schrieb:
> Toll, zu hören, dass es hier ebenfalls in der Planung ist.
> Somit denke ich, dass ich beim Testen und Debuggen helfen kann

... und deshalb habe ich mich auch mal angemeldet.

Grüße vom Stefan!

[Heinz R. (heijz)]

bloedkolben schrieb:
> Toll, zu hören, dass es hier ebenfalls in der Planung ist.

Habe ich was verpasst?

Gibt es Neuigkeiten zu HMS / HMT?  WO findet sich hierzu was?

[Ulrich K. (ulrich65)]

Meine Steckersolaranlage steht inzwischen auf einem Gartenhaus weit 
ausserhalb der Reichweite des häuslichen WLANs. Deshalb würde ich gerne 
die von der Ahoy-DTU gewonnenen Daten abzapfen und über einen 
LoRaWan-Node weiterschicken.

Damit würde sich in etwa folgendes Szenario ergeben:

Ahoy-DTU dauerhaft im Access-Point only Modus, der auch den Reset 
überlebt. Das war bei ersten Versuchen (damals noch ohne Solaranlage) 
nicht der Fall. Nach dem Reset war die DTU nicht mehr als AP erreichbar.

Eventuell die Möglichkeit, das WLAN z.B. über einen Schalter komplett 
auszuschalten, nachdem die DTU in WLAN-Reichweite mit dem Laptop o.ä. 
konfiguriert ist.

Weitergabe der Daten über eine der gängigen Schnittstellen nach aussen. 
Bevor die DTU in den Nachtmodus geht, eine Mitteilung an den Client 
schicken, dass er ebenfalls schlafen kann. Aufwachen kann er von selbst 
über einen Interrupt, wenn bei entsprechender Helligkeit die nächsten 
Daten kommen. Alternativ könnte der Client auch einfach schlafen gehen, 
wenn eine  Zeit lang keine Daten mehr kommen.

Die Daten, die über die Schnittstelle kommen, würde ich auf dem Client 
sammeln, das wichtige selektieren und in Paketen weiterschicken (wegen 
der begrenzten Datenmenge im LoRaWan).

Holen der aktuellen Zeit vom Client (ist dort über die LoRa-Daten 
verfügbar).

Jetzt die Frage:
Gibt es ausser mir noch mehr Leute mit ähnlichen Anforderungen 
(fehlendes WLAN)?

Ich hatte vor einiger Zeit schon mal eine ähnliche Anfrage gestellt, 
aber keine Reaktionen erhalten.

Ich würde mich freuen, dieses Mal eine Antwort zu bekommen, selbst wenn 
sie negativ ist.

Viele Grüße,
Uli

[Gerri (Gast)]

@Ulrich K. (ulrich65)
Welches nRF Funkmodul hast du verbaut?
Das mit der externen Antenne hat eine enorme Reichweite!

[Ulrich K. (ulrich65)]

@Gerri

Das Modul mit der externen Antenne.

Die Entfernung von der Solaranlage zum Haus ist etwa 100 Meter mit 
einigen Hindernissen dazwischen.

Die Möglichkeit hatte ich bis jetzt noch nicht auf dem Schirm. Muss ich 
ausprobieren.

Gruß,
Uli

[Gerri (Gast)]

Einfach mal die Ahoy-DTU ins Haus stellen (Fenster Richtig der 
Anlage)und evtl. mit der Sendeleistung etwas Testen!

[Ulrich K. (ulrich65)]

Werde ich ausprobieren. Melde mich dann wieder.

Gruß,
Uli

[Ulrich K. (ulrich65)]

@Gerri

Klappt einwandfrei. Danke, Du hast mir den Tag (Woche, Monat) gerettet!

Ich hatte ganz weit vorne im Thread über die geringe Reichweite der RF24 
Module gelesen und hatte die einfache Möglichkeit mir der direkten 
Kommunikation abgehakt. Statt es einfach mal auszuprobieren. Na ja, 
wieder was gelernt.

Die Module mit Antenne haben wirklich eine enorme Reichweite. Ich habe 
selbst mit der niedrigsten Leistung durch das Fenster (ich sitze in der 
warmen Wohnung) eine sichere Verbindung.

Umso erstaunlicher, da das Haus südlich des Inventers steht, der hinter 
einem der Panels hängt und hinter dem Inverter nichts ist, was 
reflektieren könnte.

Noch danke und viele Grüße,
Uli

[Gerri (Gast)]

@Ulrich K

... wunderbar! 👍😊

[Uli (Gast)]

Uli schrieb:
> ... In allen Varianten
> bekommen ich dieselben Ausgaben in der Console:
>

 n/a09:12:26 I: [NTP]: 2022-12-27 08:12:26 UTC
> 09:12:36 I: enqueued cmd failed/timeout
> 09:12:36 I: (#0) I: no Payload received! (retransmits: 0)
> 09:12:36 I: resetPayload: id: 0
> 09:12:36 I: (#0) Requesting Inv SN 1161xxxxxx41
> 09:12:36 I: (#0) enqueuedCmd: 11
> 09:12:36 I: (#0) enqueuedCmd: 1
> 09:12:36 I: (#0) enqueuedCmd: 5
> 09:12:36 I: (#0) sendTimePacket
> 09:12:36 I: TX 27B Ch40 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 
> f4 00 00 00 00 00 00 00 00 38 b7 9b
> 09:12:37 W: while retrieving data: last frame missing: Request 
> Retransmit
> ...

Hallo, wer kann mir einen Hinweis geben, ob ich da was falsch 
zusammengebaut/konfiguriert habe oder ob ich weitere Funkmodule 
ausprobieren muss?
Besten Dank Uli

[Gerri (Gast)]

@Uli
Welches nRF-Modul, ESP, Firmwareversion, Pins für CE und IRQ verwendest 
du?

[Uli H. (wetterschau)]

@Gerri, besten Dank

D1 Mini ESP8266-12F v3 von AZ-Delivery
3,3V-Ausgang mit 100µF Kondensator
Firmware 221230_ahoy_0.5.66_esp8266_f8fe044.bin u. 
221119_ahoy_0.5.41_esp8266_dec333f.bin getestet

nRF24L01+ Modul von AZ-Delivery mit Antenne auf der Platine und 
NRF24L01+PA+LNA Wireless Transceiver RF Transceiver Module with SMA 
Antenna 2.4G von Hailege
beide mit/ohne Adapaterboard von AZ-Delivery getestet

CS an D8 (GPIO15)
CE an D4 (GPIO2)
IRQ an D3 (GPIO0)
CE und IRQ in den Settings auch getauscht.

Viele Grüße Ul

[Grisu (krisu)]

Vorzugsweise solltest CE und IRQ auf einen anderen Pin legen 
(Begründungen in früheren Beiträgen), wird dein Problem aber auch nicht 
lösen.
CS an D8 (GPIO15)
CE an D1 (GPIO5)
IRQ an D2 (GPIO4)

[Uli H. (wetterschau)]

@Grisu
Besten Dank, das probiere ich nachher aus.

[Uli H. (wetterschau)]

Habe CE an D1 (GPIO5) und IRQ an D2 (GPIO4) getestet. Die Fehler 
bestehen, wie von Grisu erwartet, weiterhin. Es macht auch keinen 
Unterschied, wenn ich in den Settings für CE/IRQ  D1/D2 vertausche oder 
bei D4/D3 belasse.
Viele Grüße Uli

[Gerri (Gast)]

@Uli H.
Stimmt die Seriennummer vom Inverter?

[Uli H. (wetterschau)]

@Gerri
leider ja

[Gerri (Gast)]

@Uli H.
evtl. die FW nochmal neu flashen über USB mit Erase, oder mal einen 
anderen ESP nehmen!

[Uli H. (wetterschau)]

@Gerri
besten Dank, mit neu flashen und
CE an D1 (GPIO5)
IRQ an D2 (GPIO4)
läuft es jetzt mit meinem ganze Sortiment an Funkmodulen.

Bin begeistert. Jetzt geht der Spaß weiter. Vielen Dank!

[Andreas (dicc)]

Hallo zusammen,
wollte mal kurz auf ein "Phänomän" hinweisen:
In benutze "noch" die Version 5.15 mit EPS6288 stabil seit 4 Monaten. 
Gestern konnte keine Verbindung mehr zum HM-1500 auf gebaut werden(not 
available and not producing). Alle versuche mit reboot von HM und ESP 
blieben erfolglos.
Dann stellte ich fest das MTTQ auch nicht verbunden war und musste 
feststellen das der IOBroker auf PI "defekt" war, zuerst habe ich da gar 
keinen Zusammenhang gesehen, aber nach (langer) Reperatur mit diversen 
Scripten usw. lief der IOBroker wieder und es konnte wieder auf den HM 
connectet werden!

nur mal so als Hinweis!

Grüsse

Andreas

[fx2 (Gast)]

Ja. Bekannter alter bug ( sollte in diner aktuellen version weg sein ).

[Stefan F. (bloedkolben)]

Moin,

weiß eigentlich schon jemand, auf welcher Frequenz die HMS- und 
HMT-Serie funkt...? Da er ja nicht ständig ohne Anforderung einer DTU 
funkt, wird ja auch nicht mit einem SA die Frequenz direkt an der 
Antenne zu detektieren sein, denke ich.

"SUB 1G" ist ja weit gefaßt - aus meiner Sicht bleiben ja nur 433 und 
868 MHz als "freie" Frequenzen ohne Anmeldung und Gebühren.

[HMS (Gast)]

HMS wird hier behandelt, da andere Übertragungstechnik:
Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"
Und dort Bitte weiterdiskutieren.

[HMS (Gast)]

HMT wird hier behandelt, da andere Übertragungstechnik:
Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless"
Und dort Bitte weiterdiskutieren.

[Stefan F. (bloedkolben)]

Oh, sorry.
Dann beobachte ich den mal.

[Ralf L. (Gast)]

Ulrich K. schrieb:
> Ich warte im Moment auf Solarpanels und einen Hoymiles HM-600
> Wechselrichter und möchte die Ahoy DTU verwenden. Mein Problem ist, daß
> ich am Aufstellort der Panels kein WLAN habe (Gartenhausdach mit einigen
> Hindernissen).

Vielleicht sollte man das für zukünftige Versionen noch mit LoRaWan 
kombinieren :-)

[Christian (nordichris)]

Kurze Frage:
Kann man der Wert der Gesamtleistung (YieldTotal) per Ahoy zurücksetzen?

Hintergrund:
Ich habe den Umrichter gebraucht gekauft und würde gerne die von MIR 
erzeugte Gesamtleistung anzeigen.

Merci
MfG Christian

[Grisu (krisu)]

Nicht möglich, ob durch FW des WR ausgeschlossen oder nur noch nichts 
gefunden wurde dies zu ändern weiß ich nicht, vermute aber eher 
ersteres.
Wäre ja so als würdest den km-Zähler am Auto ändern.

[Christian (nordichris)]

Dachte ich mir schon.
Muss ich mir halt im iobroker was basteln.

[nosilent (Gast)]

Gibt es eigentlich die Möglichkeit das Netzprofil (Wechselrichter 
Parametrisierung, zb. Cos, phi=1, etc.) einzustellen ?

[Grisu (krisu)]

Dzt. nicht (hab zumindest noch nichts dazu gefunden) - geht nur mit der 
HM-DTU-pro ein TOR-Profil hochzuladen.

[MAatMC (Gast)]

Hallo,

ich habe den halben Tag damit verbracht diesen Thread zu lesen und es 
fällt mir nur eines dazu ein: RESPEKT(!) und DANKE(!) für die geniale 
Demonstration was möglich ist, wenn Menschen zusammenarbeiten.


Eine Frage hätte ich aber: Lässt sich für die Hoymiles HMnnn Serie 
darüber die abgegebene Leistung limitieren?

[Grisu (krisu)]

Ja doch unter Serial/Control.

[John P. (brushlesspower)]

ist es unter Ahoy/OpenDTU möglich Befehle an den WR zu senden ohne MQTT 
und Smart home?

Ich möchte eigentlich nur ein paar Zeilen Code hinzufügen

if(dc_Spannung < 24V){
    switch_off;
}
if(dc_Spannung > 26V){
    switch_on;
}


nur leider fehlt mir das verständnis an welcher stelle ich welche Klasse 
verwenden kann, um die DC Spannung des Wechselrichters zu bekommen und 
entsprechend ein und aus zu Schalten.

[Daniel (smitna)]

Dafür gibt es doch die jeweilige API

Bei OpenDTU siehe
https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md

Bei ahoy siehe
http://[ip ahoy device]/api

Nun lässt sich z.B. bei ahoy per cURL ein JSON abschicken. cURL ist auch 
in verschiedenen Skriptsprachen verfügbar, z.B. PHP

Für die Konsole (Linux/Windows) würde das so aussehen:

Abfrage Daten (auch im Browser)
http://[ip ahoy device]/api/live

Abschalten:

curl -i -X POST -H "Content-Type: application/json" -d 
'{"id":"0","cmd":"power","val":"0"}' http://[ip ahoy device]/api/ctrl


Einschalten:

curl -i -X POST -H "Content-Type: application/json" -d 
'{"id":"0","cmd":"power","val":"1"}' http://[ip ahoy device]/api/ctrl

[John P. (brushlesspower)]

Daniel schrieb:
> Dafür gibt es doch die jeweilige API
>
> Bei OpenDTU siehe
> https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md
>
> Bei ahoy siehe
> http://[ip ahoy device]/api
>
> Nun lässt sich z.B. bei ahoy per cURL ein JSON abschicken. cURL ist auch
> in verschiedenen Skriptsprachen verfügbar, z.B. PHP
>
> Für die Konsole (Linux/Windows) würde das so aussehen:
>
> Abfrage Daten (auch im Browser)
> http://[ip ahoy device]/api/live
>
> Abschalten:
>
> curl -i -X POST -H "Content-Type: application/json" -d
> '{"id":"0","cmd":"power","val":"0"}' http://[ip ahoy device]/api/ctrl
>
>
> Einschalten:
>
> curl -i -X POST -H "Content-Type: application/json" -d
> '{"id":"0","cmd":"power","val":"1"}' http://[ip ahoy device]/api/ctrl

Mir fehlt absolut das verständnis wie das gehen soll?

für OpenDTU konnte ich das schon umsetzen. Muss es aber nocht testen:

auto inv = Hoymiles.getInverterByPos(0);
    float dcvoltage = inv->Statistics()->getChannelFieldValue(CH0, 
FLD_UDC);

    if(dcvoltage < 24.0){
        //switch off
        inv->sendPowerControlRequest(Hoymiles.getRadio(), false);
    }
    else if(dcvoltage > 25.0){
        // switch on
        inv->sendPowerControlRequest(Hoymiles.getRadio(), true);
    }

[Malte _. (malte)]

Vielen Dank für das Projekt. Ich habe mich genau wegen OpenDTU für einen 
Hoymiles 300 Wechselrichter entschieden. Esp32 und NRF24L01+ gekauft, 
eingespielt und alles geht auf Anhieb. :)

Aus Interesse, gibt es irgendwo eine Protokollübersicht? Ich habe den 
Thread aufgrund der Länge jetzt nur Quergelesen. Demnach scheinen die 
letzten 5 Byte der Seriennummer einfach die Empfangsadresse zu sein, 
aber verschlüsselt ist da nichts? Sprich, jeder der nach eingerichtete 
Hoymiles Wechselrichter lauscht und auf dieses Weise die Seriennummer 
erfährt kann sie danach auch auslesen + konfigurieren?

[Jörg R. (rejoe2)]

Malte _. schrieb:
> Aus Interesse, gibt es irgendwo eine Protokollübersicht? Ich habe den
> Thread aufgrund der Länge jetzt nur Quergelesen. Demnach scheinen die
> letzten 5 Byte der Seriennummer einfach die Empfangsadresse zu sein,
> aber verschlüsselt ist da nichts? Sprich, jeder der nach eingerichtete
> Hoymiles Wechselrichter lauscht und auf dieses Weise die Seriennummer
> erfährt kann sie danach auch auslesen + konfigurieren?

Es gibt irgendwo hier in diesem Thread eine Excel-Datei 
(RF_communication_protocol-V6.5.xlsx), in der das Protokoll dokumentiert 
ist. Prinzipiell kann jeder mitlesen bzw. auch Kommandos absetzen, der 
weiß, wie es geht (und ggf. die "korrekte" DTU-Adresse verwendet, auf 
die der jeweilige WR grade hört).
Verschlüsselt wird da jedenfalls afaik nichts, es kann aber sein, dass 
man ein "Passwort" einrichten könnte (das aber dann nach meinem 
VErständnis wohl auch mitgelesen werden könnte...).

[Malte _. (malte)]

Jörg R. schrieb:
> Es gibt irgendwo hier in diesem Thread eine Excel-Datei
> (RF_communication_protocol-V6.5.xlsx), in der das Protokoll dokumentiert
> ist. Prinzipiell kann jeder mitlesen bzw. auch Kommandos absetzen, der
> weiß, wie es geht
Danke :) Damit hab ich es gefunden:
https://github.com/dad401/ahoy/blob/main/doc/hoymiles-format-description.txt
und
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Auch wenn die fehlende Verschlüsselung sicher die Analyse stark 
vereinfacht hat, wenn ich in der Doku einen "Download Firmware" Befehl 
sehe, ist der Wechselrichter potentiell offen wie ein Scheunentor, wenn 
da nicht noch eine Signierung und Überprüfung erfolgt.

[martin (Gast)]

Malte _. schrieb:
> ist der Wechselrichter potentiell offen wie ein Scheunentor

Prinzipiell schon - aber eine Scheune, aus der nix geklaut werden kann, 
braucht man doch auch nicht abschließen?
Mit welchem Ziel sollte dir jemand den Wechselrichter "hacken" und tot 
programmieren?

So ein Aufwand nur um dich zu ärgern? Da kann er dir auch die Autoreifen 
plattstechen...

[Neugierig (Gast)]

Willi schrieb:
> Die teilweise vorgeschlagene Verdrahtung ESP zum NRF finde ich
> problematisch.
> Problem ist bei D3/GPIO0:
> Wenn der bei Boot des ESP auf low ist, geht der ESP in den
> Programmiermodus.
> Problem ist bei D4/GPIO2:
> Beim D1mini hängt die blaue LED daran.
> Die Pin sollte man meiden
>
> Meine Empfehlung (so verdrahten und im Webinterface konfigurieren):
> NRF = ESP
> CS = D8 (GPIO15)
> CE = D1 (GPIO5)
> IRQ = D2 (GPIO4)

Hi, ist das beschriebene Problem noch akut?

Fände es schade, wenn man den I2C-Bus an D1/D2 dafür opfern müsste 
(wegen Display).

Eine flackernde blaue LED am Chip-Select würde mich persönlich nicht 
stören.

Evtl. könnte man den D3 mit einem Single-Gate  Analog-Schalter  FET / 
Dirty-Trick, was auch immer entkoppeln, dass erst wenn die Firmware 
läuft, die IRQ-Signale vom nRF durchgereicht werden?

Hat jemand Erfahrungen dazu?

[Oliver R. (esp_loeter)]

Hallo zusammen,
aufgrund vieler Nachfragen habe ich wieder einige Platinen machen 
lassen.
Wemos D1 mini und NRF24 zusammen auf einer Platine mit der Verdrahtung
wie im GitHub beschrieben.
RF24_CS_PIN        D8 GPIO 15
RF24_CE_PIN        D4 GPIO 2
RF24_IRQ_PIN       D3 GPIO 0
Läuft bei mir mit dieser Verdrahtung schon seit Monaten störungsfrei.
Ich habe noch einige Platinen übrig und würde die für 2€ pro Stück
abgeben.
Einfach in ebay-Kleinanzeigen nach esp-dtu suchen...

[Stefan S. (kami)]

Moin, mal eine kurze Frage, macht der Hoymiles HM-600 irgendwas, wenn 
nur Wechselspannung und keine Module angeschlossen sind? Kriege meine 
Module erst nächste Woche und wenn ich AC-Spannung anschließe, bleibe 
die Status-LED dunkel. Ist das richtig so?

Danke.

Gruß kami

[Dirk S. (fusebit)]

Das gehört so, der WR wird aus den Solarzellen versorgt.

[Andreas Dicke (Gast)]

Moin,
ist die PIN-Belegung "Standart" und passt die Platine auch für NRF24L01+ 
ohne externe Antenne ?

Grüsse

[gzi (Gast)]

Für die AhoyDTU gibt es jetzt eine Integration ins Projekt 
"Solaranzeige" .
Siehe https://solaranzeige.de/phpBB3/viewtopic.php?t=3387

[Tom J. (tom_j306)]

Hallo,

kann mir vielleicht jemand bei meinem Problem weiterhelfen?
Ich habe einen Wemos D1 Mini Pro (ESP8266EX) und einen NRF24L01+ PLUS.
Ich habe das aktuelle bin geflashed, habe aber immer das Problem, dass 
sich der Access Point nicht aufbaut.
Ich habe schon mehrere Wemos D1 getestet und verschiedene Versionen 
geflasht.
Wenn ich mich per Putty(seriell) verbinde, sehe ich die Meldung, dass 
ich mich mit dem AP verbinden soll.
Allerdings hatte ich schon 2 Mal das Phänomen, dass nach ein paar 
Stunden der AP doch auftauchte, allerdings konnte ich mich nur einmal 
kurz damit verbinden, jedoch ohne Eingaben zu speichern (danach war er 
wieder weg).

Was mache ich falsch?

Danke

[Robert B. (nada_zero)]

Hi,

seit heute Morgen ist mein HM_600 offline.
Fehlermeldung: 144 Grid: Grid overfrequency
Die Frequenz steht im openDTU bei 51.74 Hz
Die Anlage lässt sich auch nicht mehr starten bzw ohne Erfolg.
Kann ich an den Einstellungen im HM 600 etwas ändern?
Wo liegen die Grenzen bei der Frequenz?
Würde mich über eine Hilfestellung freuen.
Grüße
Robert

[Heinz R. (heijz)]

Robert B. schrieb:
> Fehlermeldung: 144 Grid: Grid overfrequency
> Die Frequenz steht im openDTU bei 51.74 Hz

Woher kommen diese 51,74 Hz?

Bist Du am Verbundnetz angeschlossen?
Falls ja ist wohl der WR defekt, es gab die letzten Tage in Europa keine 
so hohen Frequenzen

Ab 50,2 Hz müssen Umrichter beginnen abzuregeln, ab 51,5 Hz müssen sie 
komplett aus sein

[Martin P. (mpolak77)]

außer dein Netzbetreiber macht gerade irgendwelche Wartungsarbeiten und 
hat deine Region vom eigentlichen Netz abgetrennt um sie per 
Notstromaggregat zu versorgen. In so einem Fall wird nämlich die 
Netzfrequenz in diesem Teil künstlich angehoben, damit genau alle PV 
Wechselrichter abschalten und nicht "gegen" das Notstromaggregat 
einzuspeisen versuchen.

Quelle: 
https://www.goingelectric.de/forum/viewtopic.php?p=996735#p996735

[Robert B. (nada_zero)]

Danke für die Aufschlussreichen Antworten. Seit 13:45 ist die Frequenz 
wieder bei 50.02Hz. Ich werde weiter beobachten und die Frequenz nun 
mitloggen.
Grüße
Robert

[Heinz R. (heijz)]

Martin P. schrieb:
> außer dein Netzbetreiber macht gerade irgendwelche Wartungsarbeiten und
> hat deine Region vom eigentlichen Netz abgetrennt um sie per
> Notstromaggregat zu versorgen.

Das kann natürlich auch sein - informieren die Netzbetreiber bei so was 
nicht?

Kann ja wohl kaum sein das hier dann zig Leute auf Fehlersuche gehen?

[Grisu (krisu)]

Warum sollten sie, solange alles in der zugesagten Bandbreite liegt?
Funktioniert ja alles wie geplant und vorgesehen inkl. Abschaltung 
deiner WR.
Zig Leute hängen nicht täglich am WR um die Daten auszulesen.
Das installiert man und erfreut sich, wenn keine Sonne scheint kommt ja 
auch nichts. Anfangs ist man vielleicht interessiert und schaut öfter, 
aber wozu später noch, da genügt eine quartalsweise oder monatliche 
Kontrolle.
Ändern kann man an den Werten eh nix, also nur zum Zeitvertreib?
Ja, auch solche gibts mehr als genug, da die Menschheit zuviel Freizeit 
hat und unterbeschäftigt ist.

[Robert B. (nada_zero)]

Grisu schrieb:
> Ändern kann man an den Werten eh nix, also nur zum Zeitvertreib?
> Ja, auch solche gibts mehr als genug, da die Menschheit zuviel Freizeit
> hat und unterbeschäftigt ist.

Solche Beiträge bringen keinen weiter, haben nichts mit dem Thema zutun!

[Mathias (mathias83)]

Hallo und erstmal vielen Dank für die viele Arbeit, die in die Umsetzung 
dieses Projektes investiert wurde.

Da es vielleicht mehrere Minderbemittelte wie mich gibt, möchte ich hier 
einmal meinen Lösungsansatz vorstellen, wie ich die Daten der DTU 
auswerte, in der Hoffnung, dass es jemanden interessiert.

Meistens stolpert man über Broker und MQTT, wenn es um die 
Datenauswertung geht, ich bin aber sehr froh über die RESTAPI, die ich 
in openHAB auswerte.
Unter DietPi läuft das fast auf jeder Plattform.

Man braucht das HTTP Binding, um eine Verbindung mit der DTU aufzubauen 
und die JSONPath Transformation, um die Datei "lesen" zu können.

Danach kann man ein Thing anlegen mit der HTTP-Adresse 
http://192.xxx.xxx.xxx/api/live

Man legt jeweils einen Channel mit einer Status-Transformation an, z.B. 
JSONPATH:$.inverter[0].ch[0][5] für die Gesamterzeugung.

https://jsonpathfinder.com/ hilft bei beim Lesen der API.

Nochmal herzlichen Dank für die Entwicklungsarbeit. Ich bin absolut 
begeistert, wie viel Funktionalität sich auf dem bisschen Hardware 
unterbringen lässt.

Grüße,
Mathias

[Christian F. (christian_f744)]

Hallo zusammen!

Ich hab nach ein paar Monaten problemlosen Betrieb das Phänomen, dass 
ich keine Daten mehr von den Wechselrichtern erhalte. Ich hab nichts an 
der Konfiguration geändert. Es war von heute auf morgen weg.

Fehleranalyse … Wechselrichter blinken alle grün, also alles in Betrieb. 
Einmal Stromkosten gemacht und ein paar Minuten gewartet brachte keine 
Änderung.

AhoyDTU …. Ausgesteckt und neu gestartet nach ein paar Minuten. Brachte 
nichts. Update auf 0.5.66 brachte auch keine Änderung. Ich hatte damals 
noch eine Kombi gelötet, die funktioniert hat, auch keine Daten damit 
empfangen.

Hat noch wer einen Tipp, was ich machen könnte? 0.5.66 sagt nur „ 
Inverter #0: Paar1 (v0) is not yet available“ und „ Inverter #1: Paar2 
(v10010) is not yet available“ . Die Versionsnummer bekommt er vom 
zweiten Wechselrichter anscheinend…

Danke, Lg Christian

[Daniel R. (daniel92)]

Hallo Christian,

versuche mal bitte auch eine Werkseinstellung durchzuführen.
Trage dann alle relevanten Daten neu ein. Eventuell noch alle 
Verbindungen zwischen ESP und NRF prüfen. Nicht das sich was gelockert 
hat.

[Grisu (krisu)]

Gibt es eine Möglichkeit die WLAN-Leistung des Moduls zu begrenzen?
Dieses ist bei mir direkt neben dem Router plaziert, von dem es auch die 
5V über USB bekommt, und wie mir scheint diesen etwas überfordert durch 
die hohe Signalstärke.

[Alexander H. (agentsmith1612)]

Ich habe in meiner Ahoy meinen HM-1500 auf dem Dach und den vom Nachbarn 
auf dem seinen Carport.

Nun bin ich mit meinem Logging endlich weitergekommen. Die beiden 
IT-Studenten die ich bezahlen wollte haben es ja nicht hinbekommen. Zwar 
hab ichs auch auf meiner Synology NAS in Docker geschafft aber bin jetzt 
doch auf einen Rasberry Pi gewechselt.
Kurzum:
MQTT Server als normalen Dienst auf dem Pi installiert. Stromzähler 
Ausleseeinheit und Ahoy haben Verbindung.
Node-Red in Docker installiert und dort immer 3 Knoten pro Messwert zu 
nutzen- MQTT In --> Function Node für Tags --> Influx Out
InfluxDB 2.6.1 genutzt um die Daten zu speichern auch in Docker
Grafana für das Dashboard auch in Docker. Wobei ich sagen muss die 
Kombination InfluxDB 2.x und Grafana ist nicht unbedingt hilfreich da im 
Netz sehr viele Leute (noch) Influx 1.x nutzen und hier eine ganz andere 
Abfragesprache genutzt wird. Da ich das ganze nicht so verstehe war ich 
auf viel Hilfe in Foren und rumprobieren angewiesen, da solche 
Dokumentationen zu den Sachen für mich oft ein Buch mit 7 Siegeln ist. 
Ich lerne eher an Beispielen und den Ergebnisse und verusche das dann 
auf meine Bedürfnisse anzupassen, was natürlich nicht immer passt und 
klappt. Aber egal, mei Dashboard ist nun fast fertig und es 
funktonioniert.

Nun ist mir aufgefallen, das die Anlage vom Nachbarn sporadisch 
aussteigt. Leistung geht auf 0 W, Spannung und Frequenz sind weiterhin 
vorhanden.
Ich habe dann Hoymiles kontaktiert und die meinten ich soll mal auf die 
Spannung schauen bei 250V schaltet der WR ab.

Und siehe da, bei meinem Nachbarn geht es kurzzeitig auch mal auf 253,5 
V hoch. Was sogar außerhalb der Norm ist (230V +/- 10% sind die Norm --> 
207 - 253 V).
Nun die Frage, die Spannung die der WR misst ist das die die vom Netz 
kommt und er passt sich der dann an oder ist das die Spannung die er 
erzeugt?
Hoymiles hat angeboten wenn ich eine DTU hätte können die aus der Ferne 
dort das Limit etwas höher setzten nach dem Sie sich das 7 Tage lang 
angesehen hätten.

Nun mein Nachbar und ich hängen nicht an der selben Zuleitung. Ich 
bekomme es aus der Straße über ein Erdkabel und er von der Straße über 
uns per Überlandleitung. Er hat zudem vom Zählerschrank bis zur Anlage 
locker 30-40 m mit 4 oder 5 Klemmstellen und unterschiedlichen 
Querschnitten (manchmal auch nur 1,5 mm²). Dazu hat er auch noch einen 
Durchlauferhitzer 22kW für Warmwasser.

Nunja ich habe nun eine orginal DTU (USB Version gekauft, war im Angebot 
und ohne MwSt). auch um meinen WR mal zu updaten falls nötig. Da ich eh 
noch weitere 6 Stück hier liegen habe für eine Anlagenerweiterung kann 
das ja nicht schaden.

Ich wollte euch nur auch mal an solchen Sachen teilhaben lassen.

Das 0.6.0 Update habe ich auch schon gemacht, sieht gut aus. :-)

[Grisu (krisu)]

Da speisen wohl schon einige ein in der Umgebung und die Spannung läuft 
ihnen im Netz davon. Daher dann die Abschaltung der WR, was ja auch so 
sein muß. Bessere bzw. auch stärkere Zuleitung könnte da schon abhilfe 
schaffen, damit der Spannungsabfall geringer wird wenn sie einspeist.
Miß halt mal ganz vorn am Hauptschalter die Spannung, ob die dort 
spürbar niedriger ist als am Punkt wo der WR einspeist.

[Heinz R. (heijz)]

Alexander H. schrieb:
> Nun die Frage, die Spannung die der WR misst ist das die die vom Netz
> kommt und er passt sich der dann an oder ist das die Spannung die er
> erzeugt?

beides ist das Gleiche, an einem Messpunkt können ja keine 2 
verschiedene Spannungen sein?

[Grisu (krisu)]

Strom (Einspeisung) mal Widerstand (Leitung) ergibt Spannung(sabfall).
Mit anderen Worten, beim Einspeisen ist die Spannung direkt am WR 
gemessen sehr wohl etwas höher als vor dem Zähler gemessen.
Und normalerweise ist die Spannung an der Steckdose dann eine Spur unter 
der am Eingang (Zähler), beim Einspeisen ist das naturgemäß aber 
umgekehrt.
Von daher kann es dann schon um einzelne Volt gehen, daß er abregelt, 
obwohl vor dem Zähler noch etwas Spielraum zum tolerierten Maximum wäre.

[Heinz R. (heijz)]

da müsste er aber Hausintern schon sehr dünne Leitungen haben

Ich würde dann mal messen
- Steckdose unbelastet
- Steckdose mit einem Heizlüfter auf Stufe 1 - ca. 1000W

[Grisu (krisu)]

Alexander H. schrieb:
> Er hat zudem vom Zählerschrank bis zur Anlage
> locker 30-40 m mit 4 oder 5 Klemmstellen und unterschiedlichen
> Querschnitten (manchmal auch nur 1,5 mm²).

Schrieb er ja.

[Alexander H. (agentsmith1612)]

Die letzten Tage konnte ich sehen sobald die Sonne gut rauskommt geht es 
direkt Richtung 250 V bei ihm. Je näher es an 12 Uhr und volle 
Einstrahlung kommt je häufiger und länger gehts über die 250V.
Wenn ich mir das mal so genau ansehe dann ist er das 4. Haus auf der 
Überlandleitung nachdem es per Mast (hoffentlich aus dem Boden) kam.
Alle die mit dran hängen haben auch PV Anlagen auf dem Dach > 6 kwP 
(schätzungsweise).
Dann noch die ganzen alten und dünnen Leitungen sowohl im Haus als auch 
bis zur Solaranlage mit den gnazen Klemmstellen.
Für dauerhafte Abhilfe wäre wohl eine neue eigene Leitung nötig, auch 
wenn das heißt von der Übergabe im obersten Stock, runter in den Keller 
und dann noch die 30 m bis zum Carpot incl. Bach Überquerrung.

Es kommt vermutlich alles zusammen in dem Fall. Ich weiß ja auch nicht 
was für Überlandkabel mal da so früher genommen hat (Material und 
Querschnitt) wurde alles in den 70ern gebaut.

Gut das an der anderen Straße am Erdkabel hänge, wenn auch ich der 
letzte in der Reihe bin. Aber bei mir hat glaub ich kein Haus was mit 
dran hängt zumindest meine Straße, PV auf dem Dach.

Danke für eure Hilfe.

[Grisu (krisu)]

Das erklärt doch alles, wenn hinter ihm ein paar massiv einspeisen, daß 
die Spannung dann steigt, bis die eine oder andere PV dann eben abdrehen 
muß, wenns zu hoch geht.

[Lutz S. (lutzs)]

Das ist ja auch der Sinn der Regelung, 260 Volt im Netz will niemand. Da 
kann er nur den Heizstab z.B im Warmwasser zuschalten, so dass seine 
PV-Anlage dann auch wieder liefert ;-)

[Alexander H. (agentsmith1612)]

Ich hab jetzt die original DTU von Hoymiles (war im Angebot) noch warte 
ich auf den Account.
Dann wollen die Techniker von Hoymiles sich das mal anschauen und ggf. 
das Limit etwas hochsetzen hatten sie mir geschrieben. 253V sind ja 
erlaubt. ;-)

[Grisu (krisu)]

Den kann dir auch jeder erstellen der bereits einen Installer-Account 
hat.

[Heinz R. (heijz)]

Hast auch mal die anderen Phasen gemessen?  Evtl. hilft ja ein Wechsel?

[Alexander H. (agentsmith1612)]

Heinz R. schrieb:
> Hast auch mal die anderen Phasen gemessen?  Evtl. hilft ja ein Wechsel?
Ne gemessen noch nicht. Das Umklemmen wäre aber nicht ganz so einfach, 
weil im Hauptkasten (der kleiner kaum sein kann 70er halt) nur 6 
Sicherungen sind und das ganze Gedöns hängt an der für den Keller.
Würde bedeuten man müsste da komplett was tauschen, aber um ehrlich zu 
sein geht ich an son altes Zeug nicht dran. Einfach nicht anfassen.
Der Besitzer weiß selber das das alles nicht optimal ist und ärgert sich 
warum er nicht schon vor Jahren alles einmal neu gemacht hat.

Grisu schrieb:
> Den kann dir auch jeder erstellen der bereits einen
> Installer-Account
> hat.
Gut zu wissen, hast du einen?

[Grisu (krisu)]

Reicht doch von der Hauptsicherung zum FI oder LS 2 Phasen zu tauschen.
Alle Sicherungen rausschrauben damit das Haus stromlos ist und wie 
gesagt 2 Drähte tauschen.
Wenn kein Drehstrommotor (Wärmepumpe oder Poolpumpe etwa) im Haus 
vorhanden ist stellt das doch kein Problem dar, falls doch darst das 
ohne den ebenfalls geräteseitig irgendwelche 2 Phasen zu tauschen nicht 
machen, sonst sind sie hinüber mit Linksdrehfeld.

Sollte natürlich nur ein Elektriker machen oder jemand der dazu befähigt 
ist, aber keine große Sache wo allenfalls der Anfahrtsweg das teuerste 
ist.
Ich hab auch zw. den Phasen 1-2V differenz, wenn ihr die PV zufällig 
grad an der stärksten angeschlossen habt könnte das sehr wohl bereits 
eine Lösung sein.

PS: Ja hab einen (PN).

[Grisu (krisu)]

Alexander H. schrieb:
> Heinz R. schrieb:

> Gut zu wissen, hast du einen?

Liest du deine Mails nicht bzw. landen sie im Spam oder hast eine 
falsche bzw. nicht mehr gültige hier hinterlegt?

[Alexander H. (agentsmith1612)]

Grisu schrieb:
> Alexander H. schrieb:
>> Heinz R. schrieb:
>
>> Gut zu wissen, hast du einen?
>
> Liest du deine Mails nicht bzw. landen sie im Spam oder hast eine
> falsche bzw. nicht mehr gültige hier hinterlegt?


Ja doch ich hab jeden Tag auch geschaut ob was gekommen ist aber ist 
nichts angekommen. Ich habe meine Emailadresse eben geändert und die 
Änderung wurde auch bestätigt. Wäre nett wenn du mir nochmal die 
Nachricht schickst wenn möglich.
Vielen Dank

[Grisu (krisu)]

Ginge einfacher wennst mir eine PN mit deiner (gültigen) Mailadr. 
geschickt hättest. ;-)
PN werden hier nicht verwaltet oder gar gespeichert sondern nur direkt 
auf die hinterlegte Mailadr. versandt - Ende.

[Lutz S. (lutzs)]

Erst mal vielen Dank an alle für die beeindruckende Zusammenarbeit.

Der Thread ist ja nun sehr lang geworden, komme mit dem einlesen gar 
nicht nach.

Deshalb die Frage, vielleicht kann das jemand aus dem Stegreif 
beurteilen:

Ist der Wechselrichter auch für die Lösung geeignet?

https://www.reichelt.de/microinverter-hoymiles-hm-600-ho-hm-600-p331488.html?search=HO+HM-600

[Grisu (krisu)]

Ist doch genau das worums hier seit Anbeginn geht, also ja was sonst.

[Alexander H. (agentsmith1612)]

Lutz S. schrieb:
> Erst mal vielen Dank an alle für die beeindruckende
> Zusammenarbeit.
>
> Der Thread ist ja nun sehr lang geworden, komme mit dem einlesen gar
> nicht nach.
>
> Deshalb die Frage, vielleicht kann das jemand aus dem Stegreif
> beurteilen:
>
> Ist der Wechselrichter auch für die Lösung geeignet?
>
> 
https://www.reichelt.de/microinverter-hoymiles-hm-600-ho-hm-600-p331488.html?search=HO+HM-600

passt soweit, kannst ja hier kaufen ist nochmal ein ticken günstiger: 
https://www.offgridtec.com/hoymiles-hm-600-microinverter-modulwechselrichter.html
Oder manchmal bei Ebay noch einen 10er oder 20er günstiger, bei Neuware 
vom Händler.

[Lutz S. (lutzs)]

Grisu schrieb:
> Ist doch genau das worums hier seit Anbeginn geht, also ja was sonst.

Danke für die schnelle Antwort. Ich meinte irgendwo gelesen zu haben, 
dass manche Geräte die Schnittstelle nicht haben, aber vielleicht 
verwechsle ich da auch was.

[Alexander H. (agentsmith1612)]

Lutz S. schrieb:
> Grisu schrieb:
>> Ist doch genau das worums hier seit Anbeginn geht, also ja was sonst.
>
> Danke für die schnelle Antwort. Ich meinte irgendwo gelesen zu haben,
> dass manche Geräte die Schnittstelle nicht haben, aber vielleicht
> verwechsle ich da auch was.

Alle Wechselrichter von Hoymiles der Serie HM-XXXX können via Ahoy DTU 
oder Open DTU verbunden werden.

Die MI-XXXX Serie geht nur bedingt bis gar nicht und die HMS-XXXX Serie 
(jetzt ganz neu) geht auch (noch) nicht da hier eine ganz andere 
Frequenz/Schnittstelle genutzt wird.

[Andreas (andic)]

An dieser Stelle vielen Dank für dieses supertolle Projekt. Bei mir 
funktioniert alles bestens! hm800 iobroker
liebe Grüße

[Lutz S. (lutzs)]

Möchte mich auch bei allen bedanken die mitgewirkt haben. Habe das jetzt 
hier zunächst fliegend zusammengesteckt - funktionierte sofort, auch mit 
Display.

Funkkontakt zum Inverter HM-600 auch mit kleiner Antenne auf der Platine 
des Moduls durch mehrere Wände über ca. 20 Meter Entfernung völlig 
problemlos.

Auch die Einbindung mit MQTT ist reibungslos, Daten werden auch im Home 
Assistant sofort dargestellt.

Runde Sache, vielen Dank noch mal.

Falls jemand noch 2 leere Platinen abzugeben hat (für ESP32 Modul 
38-polig, kleines Funkmodul und 1,3" OLED Display 1306), bitte PN oder 
im Markt einstellen.

[Karsten B. (kastenhq2010)]

Gibt es eine Grafik, in welche Richtung die Leiterplattenantenne des 
NRF24L01 die beste Sendecharakteristik hat? Ich habe bei 5m Abstand mit 
zwei Betonwänden keinen Empfang mehr, mit einer Betonwand dazwischen ist 
ok.
Kann man herausfinden, ob die Pakete vom NRF oder vom Wechselrichter 
nicht ankommen?

Ansonsten ist das ein super Projekt. Klappt alles einwandfrei und ist 
verständlich, top!

[Grisu (krisu)]

Das wird nichts werden und ist auch unerheblich welche Seite nichts 
hört.
Antenne oder Empfänger (bzw. vice versa) verbessern hilft gleichermaßen.
Ich meine damit egal welches Teil, senden und empfangen ja beide.

Versuch mal das hier, könnte helfen, muß es doch glatt selbst 
ausprobieren:
https://www.instructables.com/Enhanced-NRF24L01/

[Joe G. (feinmechaniker)]

Gibt es bei der Version 0.6.9 (ESP32) Probleme mit dem WLAN?

Ich habe mir gerade eine Schaltung aufgebaut, um ein E-Paper 
anzuschließen. Das aktuelle heimische WLAN-Netz wird nur sehr sporadisch 
erreicht. (Ein ESP8266 läuft parallel in 2 Metern aber stabil). Wenn das 
heimische Netz nicht erreicht wird, funktioniert der Default 
Access-Point unter der http://192.168.4.1 auch sofort. Ich habe den 
Eindruck, dass der ESP32 zu kurz einen Verbindungsaufbau versucht.

[Ralf W. (energycartelhunter)]

Hallo zusammen!!Geniales Projekt.
Habe einen HM 1200-4 Module ca 375 W .Ahoy-DTU mit esp32/nrf24l01+ und 
Display läuft super und lässt kaum einen Wunsch offen.
Gibt es die Möglichkeit die Yield Total auf 0 zu resetten.Ich wollte 
nicht irgendetwas, wie zB Factory Reset bei System ausprobieren, da 
sonst alles super läuft.Ich habe einiges gelesen (nicht alles) aber 
nichts darüber gefunden.

Was mir aufgefallen ist, dass viele mit der Leistungsbegrenzung 
Schwierigkeiten haben.Wenn man auf senden drückt (bei Serial/Controle) 
kommt es bei mir öfter vor, dass es nicht gesendet wird und ich sah dann 
irgendwann, dass die Software direkt nach dem Button-Click eine 
Fehlermeldung bringt.
Ich hab das oft übersehen und mich gewundert, dass sich im WR nichts 
verändert hat.

[Grisu (krisu)]

Hast schon die aktuelle 0.6.9 drauf?
Falls ja empfehle ich dir mal genau nachzusehen bei den 
Paneleinstellungen (Korrektur), andernfalls mach ein Update.

[Ralf W. (energycartelhunter)]

Kann man eigentlich von einer 5er version direkt auf 6.9 updaten, oder 
muss man zuerst auf 6.0 gehen und vor allem, was kann schiefgehen, mein 
Teil läuft bestens.Ich würde nur gerne den Gesamtertrag des WR (Hm 1200) 
auf Null stellen.

[Grisu (krisu)]

Was sollte schief gehen?
Kann natürlich immer was sein, aber allenfalls hattest du ihn schon 
einmal komplett jungfräulich programmiert, wirst es also noch ein 2. Mal 
hinbekommen.

[Stefan K. (stefan5)]

Hallo Zusammen,

ich habe schon länger AHOY als Nulleinspeisung am laufen, funktioniert 
soweit :-)
Die Reaktionszeit auf eine neue Leistung ist mit dem letzten Update 
nochmals schneller geworden.
Jetzt versuche ich mich an einer weiteren Optimierung: Ich möchte das 
Daly-BMS-Projekt von Softwarecrash mit einbauen.
Damit kann ich dann auch das BMS auslesen. Ich spare mir somit ein ESP 
für das BMS und die ganze Schleife über Wlan usw. wird einfacher.
Dann habe ich ein ESP32 mit AHOY, DALY-BMS, und dem Programm für die 
Nulleinspeisung.
Hat das schon jemand versucht?
Bei mir klappts soweit, das BMS wird an der zweiten seriellen 
Schnittstelle am ESP32 eingelesen und ich bekomme die Werte.
Ich schaffs allerdings nicht, die Werte in meiner eigenen Funktion über 
MQTT rauszuschicken.
Da sind meine C++ Kenntnisse zu lasch. Templates, Klassen usw. kenn ich 
mich zu wenig aus.
Ich habe testweise versucht: (die 25.2 Volt ist dann natürlich die 
ausgelesene Spannung vom BMS)

    PubMqtt::publish ("BMS/Spannung","25.5V");
    myApp.mMqtt.publish("BMS/Spannung","25.5V");
    mClient.publish("BMS/Spannung", 0, 0,"25.5V");

Tut alles nicht...
Die MQTT Botschaften werden aus der pubMqtt.h verschickt.
Wie komme ich da an die Funktionen ran?
Habe in meiner Funktion eine Zeiger auf die "app" drin. Bräuchte aber 
irgendwas mit
template<class HMSYSTEM>
class PubMqtt {
    public:
        PubMqtt() {

Kann mich jemand erleuchten?


viele Grüße,

Stefan

[Edwin (fossi1)]

Hallo Stefan

..bei deiner Frage kann ich dir leider nicht weiterhelfen

..ich hab Ahoy auf esp8266 für 2x HM800 laufen und möchte die 
Ausgangsleistung eines HM800 dynamisch reduzieren

z.Zt versuch ich durch trennen eines PV Moduls über SSR eine Einspeisung 
über 800W zu verhindern

würd dies aber gerne quasi stufenlos (bei wechselnder Ertragsleistung 
der PV) machen

..ich heize mein Whirlpool mit reduzierter Heizleistung (über einen mit 
PWM steuerbaren SSR) z. Zt. noch mit manueller Regelung – sollte bald 
über IO Broker im Vergleich zur saldierten Netzleistung funktionieren 
(bin in Blockly noch nicht so fit)


..wie machst du die Nulleinspeisung und wie schnell/langsam ist die 
Reaktionszeit
..hast du Info’s für mich ?


Gruß aus Wien – fossi1

[Karsten B. (kastenhq2010)]

Grisu schrieb:
> Versuch mal das hier, könnte helfen, muß es doch glatt selbst
> ausprobieren:
> https://www.instructables.com/Enhanced-NRF24L01/

Hab's gemacht, hat keine fünf Minuten gedauert und funktioniert super. 
Wie viel besser die Antennenleistung ist, kann ich schlecht 
quantifizieren, aber Wechselrichter und NRF kommunizieren jetzt 
problemlos durch mehrere Betonwände.
Danke für den Link!

[Grisu (krisu)]

Danke für die Rückmeldung!
Dann werd ich mich auch mal ins Vergnügen stürzen und den kleinen Umbau 
wagen, vielleicht sehe ich dann den ungünstig gelegenen entfernten WR 
auch.

[Oswald S. (obmaroszi)]

Hallo zusammen.

ich habe ein Problem mit dem Befehl zum reduzieren der WR (HM 800) 
Leistung.
Ich habe die Beschreibung im Git gefunden jedoch habe ich keinen Erfolg 
bzw. ich weis nicht wie genau ich es machen muss.
SW ist Ahoy 0.6.9 auf ESP32
Versucht habe ich es mit:
http://192.168.178.133/ctrl/0/limit  50
http://192.168.178.133/api/ctrl/0/limit_nonpersistent_relative 50
http://192.168.178.133 /api/ctrl/0/limit   50

Kan mir da jemand helfen wie ich es genau machen muss.
Noch habe ich eine rückwertslaufenden Zähler der vermutlich heuer 
getauscht wird. Dafür möchte ich vorbereitet sein.

Danke im Voraus

[Martin M. (capiman)]

Hat jemand vielleicht bei der Analyse des Protokolls
solch einen Wechselrichter mal zerlegt?
Und könnte bei der folgenden Frage weiterhelfen?

Beitrag "Unteschied HM-600 <-> HM-800"

Vielleicht gibt auch das Protokoll etwas her,
ob man einen HM-600 später mal auf HM-800 aufrüsten könnte?

Gibt es eigentlich Protokoll-Erfahrung/Aufzeichnungen
wie ein Firmware-Update eines Hoymiles Mikrowechselrichters abläuft
(wenn dies überhaupt außerhalb der Fertigung möglich ist)?

[Grisu (krisu)]

Mit der Hoymiles DTU kann man schon ein Update einspielen, soviel ich 
gesehen hab (sofern es je eines gäbe).

Ich denk du wirst ihn schrotten wenn du aus einem 600 softwaretechnisch 
einen 800er machst, da dieser sicher thermisch und von der 
Bauteildimensionierung (Gleichrichter, Elkos, MOSFET/Triacs oder was 
eben verbaut ist) nicht ident bestückt sein wird.

Du darfst dir auch einen HM-1500 mit 4 Panelen nehmen, wenn du ihn auf 
800 oder 600W (was halt bei euch erlaubt ist) begrenzt.


Oswald S. schrieb:
> ich habe ein Problem mit dem Befehl zum reduzieren der WR (HM 800)
> Leistung.
> Ich habe die Beschreibung im Git gefunden jedoch habe ich keinen Erfolg
> bzw. ich weis nicht wie genau ich es machen muss.
> SW ist Ahoy 0.6.9 auf ESP32
> Versucht habe ich es mit:
> http://192.168.178.133/ctrl/0/limit  50
> http://192.168.178.133/api/ctrl/0/limit_nonpersistent_relative 50
> http://192.168.178.133 /api/ctrl/0/limit   50
>
> Kan mir da jemand helfen wie ich es genau machen muss.
> Noch habe ich eine rückwertslaufenden Zähler der vermutlich heuer
> getauscht wird. Dafür möchte ich vorbereitet sein.
>
> Danke im Voraus

Warum willst du ihn überhaupt begrenzen?
Wozu der Aufwand, dann schenkst halt dem Netz was du nicht selbst 
verbrauchst, kann dir doch völlig egal sein und der Umwelt hilfts 
jedenfalls auch wenn du nichts dafür bekommst.

Ich hatte nur mit Einstellung einer fixen W-Zahl Erfolg, mit % gings ab 
einer Version nicht mehr (mit der aktuellen 6.9 nicht getestet), aber 
mit Watt wunderbar, also beim HM-800 sind das für 50% laut Adam Riese 
400W.
Kannst fix einstellen, dann überlebts auch einen Neustart des WR oder 
temporär.
Eingetragen hab ich es im GUI.

[Oswald S. (obmaroszi)]

Grisu schrieb:

> Warum willst du ihn überhaupt begrenzen?
> Wozu der Aufwand, dann schenkst halt dem Netz was du nicht selbst
> verbrauchst, kann dir doch völlig egal sein und der Umwelt hilfts
> jedenfalls auch wenn du nichts dafür bekommst.

Ich verstehe Deine Antwort nicht ganz.
Ich möchte den WR begrenzen weil ich nach einem möglichen Zählertausch 
eine Nachteinspeisung realisieren möchte. Die zuviel produzierte 
Leistung möchte ich im Akku speichern und nachts einspeisen.
Das man es über UI machen kann weis ich aber beantwortet halt nicht 
meine Frage wie ich den Befehl senden muss.

[M. P. (matze7779)]

Oswald S. schrieb:
> Das man es über UI machen kann weis ich aber beantwortet halt nicht
> meine Frage wie ich den Befehl senden muss.

Per MQTT oder RestAPI.
Siehe: https://github.com/lumapu/ahoy/blob/main/User_Manual.md

[Grisu (krisu)]

Oswald S. schrieb:
> Ich verstehe Deine Antwort nicht ganz.
> Ich möchte den WR begrenzen weil ich nach einem möglichen Zählertausch
> eine Nachteinspeisung realisieren möchte. Die zuviel produzierte
> Leistung möchte ich im Akku speichern und nachts einspeisen.
> Das man es über UI machen kann weis ich aber beantwortet halt nicht
> meine Frage wie ich den Befehl senden muss.

Das erklärt aber nicht die Frage, warum du ihn begrenzen wolltest.
Was zuviel ist und der Akku nicht speichern kann für deine 
Nachteinspeisung geht halt zurück ins Netz.
Wem hilft es was wenn er dann ruhend gelegt wird, nur weil du es nicht 
mehr speichern kannst?
Die Regelung sollte doch dann an ganz anderer Stelle erfolgen und nicht 
am WR, der begrenzt wird.

[Heinz R. (heijz)]

Grisu schrieb:
> Das erklärt aber nicht die Frage, warum du ihn begrenzen wolltest.

vielleicht will er den WR nachts einfach am Akku anschließen?  Dann 
macht die Reduzierung evtl. Sinn

Es gibt allerdings die HM-300 aktuell für 75€ incl. Versand - da würde 
ich mir das Gekasper mit Umschaltung WR zwischen Akku und PV nicht antun

[Alexander H. (agentsmith1612)]

Martin M. schrieb:
> Gibt es eigentlich Protokoll-Erfahrung/Aufzeichnungen
> wie ein Firmware-Update eines Hoymiles Mikrowechselrichters abläuft
> (wenn dies überhaupt außerhalb der Fertigung möglich ist)?

Ich hab schon ein paar mal das "Netzprofil" an einem WR mit der original 
DTU neuaufgespielt bzw. ein leicht geändertes (der Hinweis was ich wie 
zu ändern habe kam von Hoymiles Support selber) Netzprofil aufgespielt.
Ansonsten habe ich dort keine andere Möglichkeit gesehen bis jetzt 
irgendwas zu aktualisieren.


Ganz andere Frage:
Wie viele WRs kann ich eigentlich an eine Ahoy DTU hängen?

[Christian B. (Gast)]

Ich habe soeben zwei Paneele samt einem HM-800 auf meinem Dach montiert, 
angesteckt und auf Anhieb Verbindung mit meinem AhoyDTU herstellen 
können. :

Deshalb möchte ich mich herzlich bei allen bedanken, die etwas zu diesem 
tollen Projekt beigetragen haben!

LG
Christian

[Daniel (smitna)]

Theoretisch 10 in der Konfiguration.

[Christian B. (Gast)]

Brauche Hilfe beim Kompilieren des Projekts

Guten Morgen

Ich möchte mir eine eigene Version mit einer kleinen Ergänzung 
kompilieren, da ich gerne die eingelesenen Daten direkt in eine MySQL-DB 
schicken möchte.

Da ich für einen MQTT-Broker keine weitere Verwendung hätte möchte ich 
den Umweg über MQTT gerne vermeiden.

Ich bin zwar Programmierer, allerdings seit Jahrzehnten verwende ich nur 
Pascal und kenne C/C++ nur aus der Schule und von kleinen 
Arduinoprojekten.

Nun habe ich mir Visual Studio Code heruntergeladen, PlatformIO 
installiert und alle Vorschläge, die mir dabei gemacht wurden befolgt 
(Gitclient installieren etc.)

Dann hab ich mir die ZIP-Datei von Github heruntergeladen, den Ordner 
src als Projekt geöffnet und auf "Build" gedrückt. (Bevor ich 
irgendwelche Änderungen vorrnehme wollte ich natürlich erst sehen ob es 
überhaupt funktioniert).

Naja. Was soll ich sagen?
Abgesehen davon, dass ich von der langen Kompilierdauer doch überrascht 
wurde, verlief der Versuch durchwegs negativ.

Erstens bin ich erschlagen vom Funktionsumfang der IDE und ich bekam nur 
eine recht lange Auflistung (siehe Anhang) der Fehler und Meldungen und 
steige da derzeit überhaupt nicht durch.

Könnte mir jemand die Entscheidenden Hinweise geben, damit ich weiß wie 
ich weiterkomme?

LG
Christian

[Lutz S. (lutzs)]

Christian B. schrieb:

> Dann hab ich mir die ZIP-Datei von Github heruntergeladen, den Ordner
> src als Projekt geöffnet und auf "Build" gedrückt. (Bevor ich
> irgendwelche Änderungen vorrnehme wollte ich natürlich erst sehen ob es
> überhaupt funktioniert).

Du musst das aus Github in Visual Studio Code clonen, nicht das zip 
herunterladen und entpacken.

https://github.com/tbnobody/OpenDTU#flashing-and-starting-up

'Clone this repository (you really have to clone it, don't just download 
the ZIP file.'

Hatte das vorher auch noch nie gemacht, habe es aber zum compilieren 
bekommen und zum Test mal eine geänderte Datei für das Display (aus dem 
Forum) mit einkompiliert, die die Temperatur des Wechselrichters mit 
ausgibt.

Die so erstellte Firmware funktionierte sofort.

[Christian B. (Gast)]

Danke sehr für den Hinweis.

Habe es jetzt mit clonen versucht (zuvor die Dateien des Downloads 
gelöscht, damit nicht irgendwo Artefakte zu Problemen führen können), 
ging auch soweit alles gut. Nur beim Build kommt wieder nix rum ... :(

Die Ausgabe hab ich wieder angehängt.

Unter dem Reiter "Problems" steht z.B. dass in  der Datei 
"DebugPrintMacros.h" millis() nicht deklariert sei.

???

Weiß wer Rat

PS: Ich möchte auch keineswegs den Thread hier kapern und wechsle wenn 
gewünscht gern in einen Neuen. Ich dachte nur, dass ich hier am ehesten 
Gehör finden werde ...

[Herbert K. (avr-herbi)]

@Christian B

Lutz S. schrieb:
> Du musst das aus Github in Visual Studio Code clonen, nicht das zip
> herunterladen und entpacken.
>
> https://github.com/tbnobody/OpenDTU#flashing-and-starting-up

Hallo Christian B, ich habe keine Ahnung von "C" und hab noch nie was 
mit platformio entwickelt. Ich habe das nur aus Interesse eben mal 
gemacht, wie beschrieben. Gültige "COM..."-Ports eingetragen wie 
beschrieben:

"...in Adjust the COM port in the file "platformio_override.ini" for 
your USB-to-serial-converter. It occurs twice:
    upload_port
    monitor_port
..."

Und nach ca. 3 Min warten hatte ich 3 Stk. _.bin Dateien im .pio 
Verzeichnis. Nur 1 Warning aus einer Fremd-LIB wegen einer data 
Variable.

Also ... funktioniert auch für Leute, die wenig Ahnung haben - wie ich.
Geflasht und auf Funktion geprüft habe ich die allerdings nicht.

Danke an Alle die weitergemacht haben, nachdem ich mich nach dem 
Zerfleddern des Protokolls mangels Zeit ausgeklinken musste.

[Heinz R. (heijz)]

Da hier die Experten sind, folgendes Problem:

Ein HM-300 wird nachts zur Unterstützung eines Victron-WR genutzt, um 
vom Akku von Sonnenuntergang bis Akku leer oder SOnnenaufgang ständig 
300W einzuspeisen

Geschaltet wird er AC-seitig mittels Smart-Steckdose

Jetzt zeigt mir Ahoy ständig Lasten zwischen 30 und 50W an obwohl er 
AC-seitig getrennt ist

Mit Zangenamperemeter gemessen - es fließt kein Strom

30W müsste man auch als Wärme am WR spüren - er bleibt kalt

Auch yield day ist falsch - mit 300W kann er kaum an einem Tag 21,4 kWh 
eingespeist haben

Hat das sonst noch jemand festgestellt?

Es ist die aktuelle Ahoy-Version - ob es bei der älteren auch so war - 
es ist mir zumindest nicht aufgefallen

[Christian B. (Gast)]

Herbert K. schrieb:
> Also ... funktioniert auch für Leute, die wenig Ahnung haben - wie ich.

Inzwischen zeigt die IDE nurmehr "Initializing PlatformIO Core" an wenn 
ich auf den Außerirdischen klicke und dann passiert gar nichts mehr ...
(Daran hat auch eine De- und Neuinstallation von VSC nichts geändert)

Anscheinend gibts halt doch Welche die noch weniger Ahnung haben ... :(

[Malte _. (malte)]

Christian B. schrieb:
> Inzwischen zeigt die IDE nurmehr "Initializing PlatformIO Core" an wenn
> ich auf den Außerirdischen klicke und dann passiert gar nichts mehr ...
> (Daran hat auch eine De- und Neuinstallation von VSC nichts geändert)

Hast du mal die Command Line Version probiert? Wenn du kein Linux hast, 
gegebenenfalls WSL installieren. Das sollte zumindest fürs erfolgreiche 
Compilieren reichen.

[Christian B. (Gast)]

Malte _. schrieb:
> Hast du mal die Command Line Version probiert?

Von VSC oder PlatformIO?

Ich muss zugeben, dass ich noch nicht wirklich durchschaue, was die 
tatsächliche Funktion der beiden Komponenten ist.

VSC ist nur der Editor?

Mit PlatformIO wurde automatisch C/C++ installiert.
Ich dachte das wäre der Compiler.
Es steht aber dabei "Intellisense, Code browsing ... "
"Code browsing" würde ich eher dem Editor zuordnen.

Entweder bin ich nur von meiner Pascal IDE so verwöhnt oder ich werde 
wirklich langsam zu alt.
Mir kommt das alles (völlig unnötig) kompliziert vor.

Linux verwende ich (aus ähnlichen Gründen) nicht, außer auf Raspberries, 
da bleibt mir nichts anderes übrig.

[Malte _. (malte)]

Christian B. schrieb:
> Von VSC oder PlatformIO?
PlatformIO. So habe ich das gebaut.

Ich gebe zu dass das ganze eine ziemliche Toolchain Download Orgie ist. 
Aber wenigstens funktionierte es alles wie beschrieben.

[Christian B. (Gast)]

Ich bin jetzt wieder einen Schritt weiter gekommen.

Auf einem anderen Computer bleibt PIO zumindest nicht beim 
initialisieren hängen.

Also wieder von Github geklont und diesmal statt das Häkchen für "Build" 
zu klicken, einen ESP32 angeschlossen und den Pfeil für "Upload".

Mir ja schon zuvor bei Build aufgefallen, dass der ganze Vorgang 
mehrmals durchlaufen wurde.
Nun ist mir auch klar warum: Es wird für alle möglichen Controller 
(ESP8266, ESP32 ...) eine Version kompiliert.

Und auch zum Controller hochgeladen.
Er scheint auch zu funktionieren (zumindest spannt er sofort das 
Default-Wlan auf).
Heißt das ich müsste irgendwie erst auswählen welchen Controller ich 
angeschlossen habe, um nur die richtige (und auch funktionierende) 
Version zu kompilieren? Wie und wo?

Denn nach (mehreren) erfolgreich hochgeladenen Versionen kommen dann 
noch die Fehlerhaften ...

[Christian B. (Gast)]

Das Bild zeigt auch welche funktionieren, und welche nicht ...

[Lutz S. (lutzs)]

In VSC gibt es unten eine Statuszeile, dort steht bei mir im vorletzten 
Eintrag rechts 'Switch Platform IO Project Environment' im Tooltip. Beim 
anklicken lassen sich verschiedene Optionen fpr diverse boards 
auswählen, steht bei mir allerdings auf 'Default (OpenDTU)'

Beim Build macht er exakt nur eine Variante:

'generic        SUCCESS   00:00:14.305'

In der Datei platformio.ini steht folgendes:

[platformio]
default_envs = generic
extra_configs =
    platformio_override.ini

und weiter unten

[env:generic]
board = esp32dev
build_flags = ${env.build_flags}
    -DHOYMILES_PIN_MISO=19
    -DHOYMILES_PIN_MOSI=23
    -DHOYMILES_PIN_SCLK=18
    -DHOYMILES_PIN_IRQ=16
    -DHOYMILES_PIN_CE=4
    -DHOYMILES_PIN_CS=5

Ich weiss aber nicht, ob das dafür die entscheidende Einstellung ist.

[Christian B. (Gast)]

Lutz S. schrieb:
> In VSC gibt es unten eine Statuszeile, dort steht bei mir im vorletzten
> Eintrag rechts 'Switch Platform IO Project Environment'

Hallo Lutz

Deiner ersten Antwort entnehme ich (inzwischen) dass Du OpenDTU 
verwendest und nicht AhoyDTU.
Aber Dein Tipp war dennoch goldrichtig. Switch Platform IO Project 
Environment" fuktioniert auch bei AhoyDTU genau wie gewünscht. Nur ist 
dummerweise ESP32 bei den nicht funktionierenden Kompilaten.

Aber ich werde mir jetzt einfach OpenDTU ansehen, da dieses (zumindest 
im Bezug auf "Out of the Box Kompilierbarkeit") anscheinend besser für 
mich geeignet ist.

Danke Dir
Christian

[H. T. (h_t)]

Der Thread ist inzwischen unerträglich lang geworden und das Laden 
dauert eine Ewigkeit :-(

Es würde mich freuen wenn einer der hier anwesenden Experten auf einer 
Webseite eine für Halbschlaue wie mich nachvollziehbare Anleitung 
schreiben könnte, die angibt wie man den Hoymiles mit preisgünstigen 
Komponenten auslesen und konfigurieren kann.

Vielen Dank!
H. Trickler

[Christian B. (Gast)]

H. T. schrieb:
> Es würde mich freuen wenn einer der hier anwesenden Experten auf einer
> Webseite eine für Halbschlaue wie mich nachvollziehbare Anleitung
> schreiben könnte, die angibt wie man den Hoymiles mit preisgünstigen
> Komponenten auslesen und konfigurieren kann.

https://ahoydtu.de

[Heinz R. (heijz)]

besser das hier:

https://github.com/lumapu/ahoy/blob/main/Getting_Started.md

[Micha H. (mlh)]

Hi,
kann mir bitte mal jemand in einfachen Worten erklären wie man Werte auf 
der Linux-Console zeitnah aus der DTU rauskriegt.
Ein "mosquitto_sub -t DTU/HM600/ch0/active_PowerLimit -C 1" braucht 30 
Sekunden! Das kann ja wohl nicht wahr sein. Selbst die die simple 
P_AC-Abfrage dauert bis zu 10 Sekunden. Da stimmt doch was nicht? Wozu 
braucht man dazu überhaupt einen Broker?
Meine Tasmotas liefern mit einem einfachen http get die Werte in 
Millisekunden zurück.
Geht sowas denn nicht mit AhoyDTU(0.6.9)? Mache ich was falsch?

[Heinz R. (heijz)]

Micha H. schrieb:
> Ein "mosquitto_sub -t DTU/HM600/ch0/active_PowerLimit -C 1" braucht 30
> Sekunden! Das kann ja wohl nicht wahr sein. Selbst die die simple
> P_AC-Abfrage dauert bis zu 10 Sekunden. Da stimmt doch was nicht? Wozu
> braucht man dazu überhaupt einen Broker?

Du hast die Funktion von MQTT noch nicht ganz verstanden

Der Broker ist ein Nachrichtenverteiler
Der von DIr gezeigte Befehl abonniert das Thema XY auf dem Broker - das 
heisst immer wenn ein Client, in dem Fall Ahoy oder OpenDTU - einen 
neuen Wert an den Broker schickt, weiss dieser wer alles das Thema 
abonniert hat und verteil den Wert an diese

Werte werden meist nur bei Änderungen geschickt, oder falls gleich alle 
30 oder 60 Sekunden

Installiere doch mal an deinem Rechner das Programm MQTT-Client - Du 
wirst sehen, die DTU sendet gar nicht öfter

Was Du suchst ist eher die REST API?

[Micha H. (mlh)]

Heinz R. schrieb:
> Micha H. schrieb:
>
> Du hast die Funktion von MQTT noch nicht ganz verstanden

Das habe ich dann gestern auch noch rausgefunden. Also für meinen Zweck 
völlig ungeeignet, weg damit.

> Was Du suchst ist eher die REST API?

Ist das so? Ein Beispiel wie man das benutzt? Nur ein Einziges?

[Heinz R. (heijz)]

Micha H. schrieb:
> Das habe ich dann gestern auch noch rausgefunden. Also für meinen Zweck
> völlig ungeeignet, weg damit.

was hast Du denn genau vor, welche Werte brauchst Du so schnell?

Ich nutze z.B. FHEM, dorthin loggt der WR, ich kann dann dort die Werte 
abholen

Aber wenn es direkt per Bash / über die API sein soll:
Nutzt Du OpenDTU oder AHOY?

Für OpenDTU ist es hier sehr ausführlich beschrieben:
https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md

AHOY:  in der Weboberfläche gibt es den Button REST API, dann siehst die 
möglichen Befehle
Beispiel:http://192.168.178.30/api/record/live

Du musst dann die Antwort "zerschneiden", so den gewünschten Wert parsen

Sag mal welche Software Du nutzt , welchen Wert du haben willst, dann 
schaue ich mal

[Micha H. (mlh)]

Heinz R. schrieb:

> was hast Du denn genau vor, welche Werte brauchst Du so schnell?
>
> Ich nutze z.B. FHEM, dorthin loggt der WR, ich kann dann dort die Werte
> abholen

Meine "Home Automation" läuft ausschließlich über ein umfangreiches 
bash-Skript, angezeigt und gestellt wird über meine Website. Die 
Schleife im Skript läuft in unter einer Sekunde durch; wenn ich da 
dutzende Sekunden auf einen einzelnen Wert warten muß hebelt das mein 
ganzes Konzept aus.

> Aber wenn es direkt per Bash / über die API sein soll:
> Nutzt Du OpenDTU oder AHOY?

Ahoy

> Für OpenDTU ist es hier sehr ausführlich beschrieben:
> https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md
>
> AHOY:  in der Weboberfläche gibt es den Button REST API, dann siehst die
> möglichen Befehle
> Beispiel:http://192.168.178.30/api/record/live
>
> Du musst dann die Antwort "zerschneiden", so den gewünschten Wert parsen

Genau darum geht's mir. jq ist ja schön und gut, aber auch dafür finde 
ich kein funktionierendes Beispiel auf dem ich aufbauen kann. jq nackt 
schreibt dagegen die ganze Lebensgeschichte des Wechselrichters, wenn 
ich da noch seitenweise mit cut, grep, awk und Konsorten drauf losgehen 
muß bringt's auch nichts.

> Sag mal welche Software Du nutzt , welchen Wert du haben willst, dann
> schaue ich mal

Nur das was auf der console so hat. Momentan will ich nur Leistung und 
Powersetting auslesen. Es wäre sehr nett von Dir wenn Du dafür ein 
Beispiel bringen könntest.

[Karl M. W. (charlie-w)]

Hallo Micha,
habe etwas ähnliches gebaut. Frage bei mir aber über eine Shelly ab. Im 
Prinzip das selbe Prozedere. Batch als Anhang. Dürfte selbsterklärend 
sein.
hth

[Micha H. (mlh)]

Karl M. W. schrieb:
> Batch als Anhang. Dürfte selbsterklärend  sein.

Danke, ist es. Ich hab mal die relevante Zeile händisch abgesetzt:

$ curl http://192.168.178.52/status | jq -r '.meters[].power' 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

Ich krieg das Haareraufen. Den Endpoint gibt's bei mir nicht.
http://192.168.178.52/api zeigt mir das:

{
  "avail_endpoints": {
    "system": "http://192.168.178.52/api/system",
    "statistics": "http://192.168.178.52/api/statistics",
    "inverter/list": "http://192.168.178.52/api/inverter/list",
    "index": "http://192.168.178.52/api/index",
    "setup": "http://192.168.178.52/api/setup",
    "live": "http://192.168.178.52/api/live",
    "record/info": "http://192.168.178.52/api/record/info",
    "record/alarm": "http://192.168.178.52/api/record/alarm",
    "record/config": "http://192.168.178.52/api/record/config",
    "record/live": "http://192.168.178.52/api/record/live"
  }
}

Was läuft da schief bei mir?

[Lutz S. (lutzs)]

Er fragt eine Shelly ab.

[Heinz R. (heijz)]

Micha H. schrieb:
> Ich krieg das Haareraufen. Den Endpoint gibt's bei mir nicht.
> http://192.168.178.52/api zeigt mir das:

das ist eine Übersicht über die möglichen Abfragen

Ich bastel Dir nachher was in Bash

ABer such doch gerne schon mal raus wo die richtigen Werte stehen?

Schau DIr alle Links durch - vermutlich der Letzte:
http://192.168.178.52/api/record/live

[Karl M. W. (charlie-w)]

@ Micha H.

Erst mal:

curl http://192.168.178.52/api/record/live | jq -r '.inverter[]'

Dann suchst Du Dir den Wert raus, den Du haben willst. Und dann:

curl http://192.168.178.52/api/record/live | jq -r '.inverter[] | .[1] | 
.val'

In [] die entsprechende Ziffer/Zahl eintragen.

hth

[Micha H. (mlh)]

> ABer such doch gerne schon mal raus wo die richtigen Werte stehen?

Leistung steht hier:
/api/record/live/P_AC
Das Limit steht hier:
/api/record/config/active_PowerLimit

Ich bin völlig am Ende. Ich finde im ganzen Netz auf und ab keine 
Erklärung wie man das extrahiert.

[Karl M. W. (charlie-w)]

P_AC ist der 14. Eintrag in der json_liste (Zählung beginnt bei 0).
Also [14].
Das Übrige äquivalent.
hth

[Micha H. (mlh)]

Karl M. W. schrieb:
> P_AC ist der 14. Eintrag in der json_liste (Zählung beginnt bei 0).
> Also [14].

Jetzt habe ich es verstanden, es funktioniert.

Sowas extrem unübersichtliches ist mir ja noch nie begegnet, das bleibt 
hoffentlich die einzige Begegnung mit Json.  Warum man sowas macht oder 
haben will ist mir ein Rätsel.

Jedenfalls vielen Dank an alle die Geduld mit mir hatten!
Ich brauche jetzt erstmal ein Beruhigungsbier. Prosit!

[Heinz R. (heijz)]

Micha H. schrieb:
> Sowas extrem unübersichtliches ist mir ja noch nie begegnet, das bleibt
> hoffentlich die einzige Begegnung mit Json.  Warum man sowas macht oder
> haben will ist mir ein Rätsel.

Das Problem ist hier weder Json noch Du, sondern AHOY :-)

Ich habe es mir gerade auch noch mal angeschaut
- es gibt - zumindest auf die Schnelle gesehen - nicht die 
Gesamtleistung, sondern nur pro WR einzeln

- es macht in meinen Augen auch wenig Sinn in der JSON alle Kanäle 
gleich zu benennen - sinnvoller wären hier Angaben wie P_AC_Ch0 usw


Ich habe hier sowohl Ahoy als auch OpenDTU am laufen - mein Favorit ist 
- gerade wegen solcher Themen - OpenDTU

Auch wenn man siech mal die Issues in Github anschaut - da tauchen von 
Update zu Update immer wieder neue Probleme auf die eigentlich schon mal 
funktioniert haben

[Alexander H. (agentsmith1612)]

Heute wurde meine Solaranlage erweitert.
Weitere 6kwp mit 4x HM-1500 insgesamt dann jetzt 6x HM 1500.

Leider gibt mit der Ahoy Stress.
Mit einem WR und MQTT aktiv auf 0.6.9 liefen zwei Stück problemlos.

Nun habe ich in jeder Ahoy DTU 3 WRs drin und die Dinger stürzen 
andauernd ab oder brauchen ewig zum laden.

Oft kommt: "Every n/a seconds the values are updated" unter "Live" und 
dann passiert nichts mehr.

Habe auch schon neu geflashed komplett und alles neu eingegeben kein 
Unterschied.

Wie gesagt mit einem WR und MQTT klappt das super.

Kondensator ist auch verbaut.
Manchmal startet sie auch einfach neu nach dem ich zugreifen wollte.

Weiß einer wo das Problem sein könnte?

[Heinz R. (heijz)]

versuch es mal mit OpenDTU?

[Lutz S. (lutzs)]

Hallo,

hatte gerade bei einem Freund eine Weile gesucht, weil die neue OpenDTU 
keine Verbindung zu seinem Wechselrichter aufnehmen wollte. Hier bei mir 
funktionierte es problemlos.

Seriennummer stimmte, mehrfach überprüft.

Nun bin ich wieder zu mir zurück und teste mit meinem WR: ist es 
richtig, dass das erst funktioniert wenn die Verbindung zum WLAN steht?

Solange ich über den AP der DTU zugreife findet er den Wechselrichter 
nicht, ist er im WLAN klappt es sofort.

[Alexander H. (agentsmith1612)]

Heinz R. schrieb:
> versuch es mal mit OpenDTU?
Ich hatte nun auf Github einen Issue eröffnet und nun kam raus es liegt 
am Speicher. Bei mehr als 4 Wechselrichtern reicht der Speicher des ESP 
8266 nicht mehr aus.
Ich hab mir jetzt einen ESP 32 bestellt ;-)

[Herbert K. (avr-herbi)]

OpenDTU API JSON
Hallo, wofür steht Bitte das "d:" und was haben die Zahlen dahinter für 
eine Bewandnis? Danke schon einmal im voraus.

[Sebastian M. (sebastian_m785)]

Hallo,


ich hab seit längerem ein AhoyDTU am laufen, und ich hab eine Frage. Ist 
es möglich ein Relais direkt zuschalten ab einer gewissen Einspeisung?

Also ohne Mqtt, ich möchte dazu kein extra Server aufbauen.

Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt 
mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt 
Einspeisung.

Ich würde es gerne so einfach wie möglich halten.

Danke

[Heinz R. (heijz)]

Sebastian M. schrieb:
> Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt
> mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt
> Einspeisung.
>
> Ich würde es gerne so einfach wie möglich halten.

Die willst dann einfach hart ein- und ausschalten? Da freut sie sich

Und unter 400W gibt es nur noch eine kalte Dusche?

Du solltest Dein Vorhaben noch mal überlegen
Du musst bei PV-Überschuss die Soll-Temperatur hoch ziehen, nicht alles 
komplett an/aus

[Sebastian M. (sebastian_m785)]

Nein ich hab noch ein Wärmetauscher, die  Wärmepumpe soll  unter 400 
Watt  nicht laufen. Man bräuchte noch ein 2. Relais um die Heizung 
aktivieren.

Alles andere ist mir zu aufwendig,  da der Sicherungskasten zu weit weg 
ist
Smarthome gibt es leider nicht.

[Grisu (krisu)]

Wenn du dir einen freien Ausgang entsprechend reinprogrammierst, der das 
macht, ist es sicher kein Problem dort ein Relais (ggf. über Transistor) 
anzuhängen.

[Heinz R. (heijz)]

Sebastian M. schrieb:
> Alles andere ist mir zu aufwendig,  da der Sicherungskasten zu weit weg
> ist
> Smarthome gibt es leider nicht.

Es ist ja nicht so das ein "Home2 "smart" ist oder nicht

Auch im sogenannten Smart Home, das sind halt Steuerungen - ,mal mehr, 
mal weniger

In Deinem Fall würde ich aber auf alle Fälle was sinnvolles bauen - 
nicht die WP hart an- / ausschalten

Was ist es denn für eine WP? wie kann die gesteuert werden?

Ich würde hier trotzdem MQTT nutzen, wegen mir auch einen öffentlichen 
Server, kann Dir auch meinen zur Verfügung stellen

[Andreas (dicc)]

Sebastian M. schrieb:
> Hallo,
>
>
> ich hab seit längerem ein AhoyDTU am laufen, und ich hab eine Frage. Ist
> es möglich ein Relais direkt zuschalten ab einer gewissen Einspeisung?
>
> Also ohne Mqtt, ich möchte dazu kein extra Server aufbauen.
>
> Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt
> mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt
> Einspeisung.
>
> Ich würde es gerne so einfach wie möglich halten.
>
> Danke

Moin,

ich versuche sowas mit dem IOBroker und Alexa zu realiseren. Man kann 
eine Alexa Adapter installieren und dann z.b. Steckdosen schalten!

Grüsse

AD

[Heinz R. (heijz)]

Andreas schrieb:
> ich versuche sowas mit dem IOBroker und Alexa zu realiseren. Man kann
> eine Alexa Adapter installieren und dann z.b. Steckdosen schalten!

von hinten durch die Brust ins Auge...

[Ray (lukesky333)]

Hi,

ich bin ganz neu hier und schaffe mir gerade ein kleines Balkonkraftwerk 
an.

Nun stellt sich mir die Frage:
Wie hoch ist denn die Wahrscheinlichkeit, dass OpenDTU auch den 
E-Star Energy HERF-800 unterstützen wird.
Scheinbar soll es sich da weitestgehend um Hoymiles-Technik handeln, 
braucht aber statt einer DTU eine DCU, die wohl technisch nicht 
kompatibel sind.

[Grisu (krisu)]

Denke die Chance zumindest in absehbarer Zeit geht dann gegen Null (ohne 
es zu wissen). Warum nimmst dir dann nicht eine Hoymiles?

[Arne M. (arne_m976)]

Moin,
ich habe einen ESP32 (Box) mit Opendtu seit ca. März zu laufen.
(da hängen 2x WR am Balkonkraftwerk dran)
Alles hübsch und Verbindung zum Iobroker.
Ich habe die Box momentan im Wohnzimmer zu stehen.
Wenn die Box startet ist nur mein AP im Hausflur online.
Später dann ab 10:00 schaltet sich ein Repeater im Wohnzimmer dazu.
(heute testweise ca. 8:30 manuell betätigt)
Die Box wird sich wohl dann irgendwann mit dem Repeater verbinden, weil 
der Empfang doch stärker ist als vom AP im Hausflur.
In dieser Zeit habe ich immer einen kompletten Abbruch von ca. 5min.
Ist das normal - startet dann die DTU komplett neu?

Danke für die Antwort.

[Dirk S. (fusebit)]

Den kompatiblen HM-300 gibt es momentan bei Reichelt für 69€, falls 
jemand Interesse hat.

https://www.reichelt.de/microinverter-hoymiles-hm-300-betterie-bc01-buchse-ho-hm-300-bet-p354755.html?&trstct=pos_1&nbc=1

[Knut B. (Firma: TravelRec.) (travelrec)]

Hallo und vielen Dank für diese wertvolle Arbeit!
Habe gerade brandneu das System aus ESP32 und NRF24L01+ Modulen 
zusammengesteckt und die aktuelle Firmware geflasht. Die Funkstrecke zum 
HM-600 ist eine Zimmerdecke, alles funktionierte auf Anhieb! Großartig! 
Die Einbindung der Daten in meine Heimsteueranlage ist dann nur noch 
eine Frage der Zeit.

[CE (oxylog)]

Hallo in die Runde!
Ich habe mir wieder ein paar Platinen fertigen lassen.
Dieses Mal mit Integration für ESP32 (38 Pin) mit NRF24l01+ und 
E49-900M20S sowie I2C-Display; Ebenfalls geht die "klassische" 
Bestückung mittels Wemos + NRF (dann ohne Display).
https://www.kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoydtu-und-opendtu-projekt-auf-esp32-und-esp8266/2490730186-168-9361

[Malte _. (malte)]

CE schrieb:
> Ich habe mir wieder ein paar Platinen fertigen lassen.

Genau nach so einer suche ich :)
Gibt es irgendwo den Schaltplan deiner Platine? Auf den Bildern ist die 
Beschriftung der Lötbrücken doch etwas schwierig zu erahnen.

[Max (minimum)]

Hallo Ahoy-Leute,
 ich habe mich ein wenig eingelesen und komme aber eher vom Arduino.
Der Arduino-Teil scheint weniger entwickelt, bitte hier um Hilfe.
Muss ich das NRF24_SendRcv als mehrere Bibliothek definieren ?
Sonst kann ich die Befehle wohl nicht nutzen.
Und ich sehe den Power-Limit Befehl in Arduino-Projekt umgesetzt.
Bitte hier um etwas Hilfe, denn mit GUIs, IO Broker und fertig flashern 
kann ich nichts anfangen.
Ich hätte gern lieber eine einfache Lib für die Arduino IDE, mit einem 
Befehl die Leistung auszulesen und ein volatile Power-Limit zu setzen.
So konnte ich es mit meinen Griedtie Invertern bisher über RS465 tun, 
aber ich hätte nun gern etwas mit mehr VDE-Normen dran.
Gruß,
 Max

[Max (minimum)]

Nun habe ich schon mal raus gefunden das im man nicht im "nano" 
Verzeichnis nachsehen darf, sondern in der tool/main im NRF24_SendRcv 
ein .ino findet.

Ich denke in diesem Abschnitt bekommt man die Daten des WR:

    for (uint8_t i = 0; i < ANZAHL_VALUES; i++) {
      //outChannel(i);
      Serial.print(getChannelName(i)); Serial.print(':'); Serial.print(VALUES[i]); Serial.println(BLANK);  // Schnittstelle bei Arduino
    }

Nur eine Umsetzung des Powerlimit sehe ich im Arduino leider nicht.
Ich habe nur im github von Stefan123 das hier gesehen:
Und hier das Power Limit setzen

51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B
^^------------------------------------------------ MainCmd 0x51 DEVCONTROL_ALL
   ^^^^^^^^--------------------------------------- WR Serial ID
            ^^^^^^^^------------------------------ DTU Serial ID
                     ^^--------------------------- SingleFrameID
                        ^^------------------------ SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr
                        ^^^^---------------------- Control Mode
                             ^^^^----------------- PowerPFDev.SetValut 0x012C = 30.0 W
                                  ^^^^------------ PowerPFDev.Desc 0x0000 oder 0x0001 ?
                                       ^^^^------- CRC16 / CRC-Modbus über die Daten, excl. Frame ID!
                                            ^^---- CRC8

Gibt es da schon eine Umsetzung  am Arduino oder habe ich die im Code 
überlesen ?

[Frank W. (Firma: DB1FW) (frankw)]

Dieser Riesen-Thread hat zu der genialen OpenDTU geführt.
Ich habe zwei davon in Einsatz - super. Danke an alle.

Ich habe mir für einem M5Stack eine WLAN Anzeige mit Logging und 
eingebautem MQTT Broker geschrieben. Damit ist ein MQTT Broker im 
Hausnetz nicht mehr Voraussetzung um im ganzen Haus die Solardaten 
anzeigen zu können.

Wer Interesse hat -

https://www.gadgetpool.eu/product_info.php?products_id=104

Ja, ist ein Shop. Aber unten findet sich auch der Download für die 
Software.
Wenn jemand also eine M5Stack und einen OpenDTU hat und eine WLAN 
Anzeige im Haus haben möchte - einfach ausprobieren.

Gruss Frank

[Heinz R. (heijz)]

Frank W. schrieb:
> Wenn jemand also eine M5Stack und einen OpenDTU hat und eine WLAN
> Anzeige im Haus haben möchte - einfach ausprobieren.

sehr gut gemacht :-)

Aber braucht es wirklich einen M5-Stack?
Die Teile kosten 100€

Einfach einen ESP32 mit irgendeinem Display?

[Frank W. (Firma: DB1FW) (frankw)]

Heinz R. schrieb:
>
> Aber braucht es wirklich einen M5-Stack?
> Die Teile kosten 100€
>
> Einfach einen ESP32 mit irgendeinem Display?

Geht sicher.
Habe dem M5 Stack genommen wegen WAF, Fertiges Gehäuse mit Taster, 
Batterie.

Bis ich das selbst gebastelt habe wird es wahrscheinlich auch nicht 
fürchterlich viel billiger.

Aber gehen wird das sicher

[Heinz R. (heijz)]

Die Teile sind halt - meine Meinung - unglaublich hässlich und preislich 
total überzogen

[Knut B. (Firma: TravelRec.) (travelrec)]

Heinz R. schrieb:
> Frank W. schrieb:
> Einfach einen ESP32 mit irgendeinem Display?

Der ESP an der Wechselrichter-zu-WLAN-Brücke spuckt doch alles per UART 
aus. Da kann man sich dranstricken, was man braucht. Bei mir werkelt da 
noch ein 433MHz Umsetzer dran, der die Daten in den Keller schickt, wo 
ich sie in eine eigene Steueranlage einspeise. Bisschen 
Programmierarbeit für Funkprotokoll und Absicherung und 10 Minuten 
löten, dann war´s fertig.

[Grisu (krisu)]

HMS und HMT Wechselrichter von Hoymiles dürften nun durch Tausch des 
Funkmoduls ebenfalls unterstützt werden.
Gute Nachricht für mich, da ich vorhabe alles umzurüsten.

[Rolf E. (rolf_e)]

Hallo,
gibt es einen Befehl für den Hoymiles-400/800 mit dem man den MPPT 
Tracker abschalten kann.
Verwende openDTU zu Steuerung.
Der HM-400 hängt an einer Batterie, und da ist der MPPT Tracker eher 
schlecht.

Super wenn es das schon gibt.

Rolf

[Heinz R. (heijz)]

Mir ist nichts bekannt

Wieviel Volt hat Dein Akku?
Bei 48V funktioniert das auch so problemlos

[Frank W. (Firma: DB1FW) (frankw)]

OpenDTU sagt, dass nach der Limitierung auf einen Absolutwert bis zu 4 
Minuten vergehen können bis die Anzeige aktualisiert wird.
Bei Limitierung auf relativen Wert scheint das nicht so zu sein.
Kennt jemand den Grund dafür?

Danke

[Alexander H. (agentsmith1612)]

Grisu schrieb:
> HMS und HMT Wechselrichter von Hoymiles dürften nun durch Tausch des
> Funkmoduls ebenfalls unterstützt werden.
> Gute Nachricht für mich, da ich vorhabe alles umzurüsten.

Möchtest du uns mitteilen warum die umrüstest.

Natürlich sind HMS und HMT gegenüber HM überlegen, gerade wenn es um 
direkte Erzeugung von 3-Phasen geht.

Im Vergleich zur HM Serie aber gerade bei den kleineren (Einphasigen) 
doch noch relativ teuer und was ich richtig schlecht finde ist diese 
Busbar die man braucht. Für einen nicht intelligente "Klemme"/"Stecker" 
find ich den Preis etwas überzogen.

Für Installateure die eh 10 oder mehr davon bei einer Fläche einstecken 
verkabeln müssen sehr ich den Vorteil aber bei Privatpersonen?

Oder gibt es noch weitere Vorteile, die ich noch nicht kenne?

[Stefan K. (stefan5)]

Hallo Zusammen,
ich habe eine kleine Frage zu unser aller Hobby :-)
Mein AHOY läuft seit 5 Monaten super, Version 0.6.9.
Seit dem 24.08. kommen bei Bedarf aber keine 600 W mehr aus dem Hoymiles 
HM-600 raus, nur noch so 280W. Gleichzeitig zeigt die Efficiency nur 
noch 50% an. Ich betreiben den Wechselrichter direkt an einer 8S 
Batterie. Wenn ich die Solarzellen direkt anstecke, kommt aus dem CH1 
nix raus. Mit Batterie zeigt CH1 aber halbwegs plausible Werte an.
Hat jemand schonmal beim Hoymiles ein Chanel abgeschossen?
Gibts da eine Sicherung o.ä.?
Ein Update auf die neuste SW bringt vermutlich nichts, ich denke es 
liegt ein HW-Fehler vor.

Ich wünsche euch einen sonnigen Tag :-)
viele Grüße, stefan

[Grisu (krisu)]

Alexander H. schrieb:
> Möchtest du uns mitteilen warum die umrüstest.
>
> Natürlich sind HMS und HMT gegenüber HM überlegen, gerade wenn es um
> direkte Erzeugung von 3-Phasen geht.
>
> Im Vergleich zur HM Serie aber gerade bei den kleineren (Einphasigen)
> doch noch relativ teuer und was ich richtig schlecht finde ist diese
> Busbar die man braucht. Für einen nicht intelligente "Klemme"/"Stecker"
> find ich den Preis etwas überzogen.
>
> Für Installateure die eh 10 oder mehr davon bei einer Fläche einstecken
> verkabeln müssen sehr ich den Vorteil aber bei Privatpersonen?
>
> Oder gibt es noch weitere Vorteile, die ich noch nicht kenne?

Also Umrüstung von (etwas großspurigem) Balkonkraftwerk auf "richtige" 
PV.

Da ich aber den Vorzug alles selbst zu machen sehr schätze und die 
Hochspannung am Dach vermeiden möchte installiere ich nun das Maximum 6x 
HMT-2250. Soviel geht sich grad aus mir 460W-Panelen.
Die T-Connetor Stecker waren bei meinem holländischen Anbieter debei 
(ohne Aufpreis).
Also die für mich etscheidenden riesigen Vorteile:
1.) KEINE Hochspannung, keine Sicherheitsabschaltung nötig und null 
Probleme mit der Feuerwehr.
2.) Wenn was hin ist dann höchstens ein WR der sich wegschaltet oder man 
leicht abstecken kann.
Tausch/Reparatur kann dann irgendwann erfolgen wenns wieder schön ist.
Die restlichen 5 produzieren munter weiter.
3.) Verschattung ist kein Thema, da alle Module einzeln angeschlossen 
werden. Es wird somit immer voll produziert.
4.) Mit openDTU volle Kontrolle über das System, selbst wenn Hoymiles in 
ein paar Jahren ihre Plattform vielleicht dicht macht (ist ja seit 
Jahren nur Beta)
5.) Ganz leicht erweiterbar, oder auch reduzierbar
6.) Preis ist denk ich sehr gut und sofort lieferbar. 2,2kWp um unter 
500€ (inkl. MWSt bei uns), also 13,5kWp um 3.000€, glaub da gibts 
teurere Angebote.

Nachteil: Man kann nicht einfach die Module miteinander verbinden 
sondern muß jedes einzeln zum WR verkabeln. Aber in Eigenbau ist das 
eben eine Zeitfrage, bei einer Firma würde das teuer werden.

[Alexander H. (agentsmith1612)]

Grisu schrieb:
> Also Umrüstung von (etwas großspurigem) Balkonkraftwerk auf "richtige"
> PV. [...]

Danke für deine Ausführungen.
Genauso ging es mir auch.
Ich kam auch von einem Balkonkraftwerk und habe dann alles selber mit 
den Modul WRs gebaut.
Genau wie aus deinen genannten Gründen.

Vieleicht noch ein Nachteil den man bedenken sollte:
Einen Akku nachrüsten ist nicht ganz einfach und auch nicht günstig, da 
man für den Akku dann wieder einen WR braucht.
Aber das ist ja ein anderes Thema.

Meine Frage war eher halt dahin gehend,  warum HMS und nicht HM? Da ist 
zumindest ein Preisunterschied in Summe dann.?

[Grisu (krisu)]

Alexander H. schrieb:
> Meine Frage war eher halt dahin gehend,  warum HMS und nicht HM? Da ist
> zumindest ein Preisunterschied in Summe dann.?

Habe HMT genommen, da 3-phasig (und neuer obendrein) im Gegensatz zu den 
einphasigen (älteren) HMS und auch HM. Ist halt doch wesentlich 
einfacher nur ein Starkstromkabel zu brauchen dafür und das 
Verbindugngssystem zum Anhängen und Serisieren/Erweitern ist ja auch 
recht einfach.
Größere PV genehmigen sie auf einzelnen Phasen ja gar nicht.
Da wirds dann mit HMS mühsam, wenn die nicht alle ident produzieren.

[Alexander H. (agentsmith1612)]

Grisu schrieb:
> Größere PV genehmigen sie auf einzelnen Phasen ja gar nicht.
> Da wirds dann mit HMS mühsam, wenn die nicht alle ident produzieren.

Gebe ich dir zu 100% recht.

Ich babe bei mir 8x HM unterschiedlicher Größe, 5x den HM-1500. Habe 3 
Dachseiten (Ost, Süd, West) teilweise bestückt und jede Dachseite auf 
eine Phase aufgeteilt.
War aber in der Tat etwas mehr Arbeit an Verdrahtung und Kabel.

[Helmut H. (der_andere)]

Ich habe mal was mit Virtuino IOT gebaut, macht aus den HoymilesDTU Json 
Daten eine Anzeige.
Wenn Virtuino noch Curl oä für die Leistungsbegrenzung per Http könnte, 
ein Traum ;-)
https://youtu.be/CwgmrcxG7hQ und 
https://www.youtube.com/watch?v=n8syQqeMyiw

[Pavel (pali)]

Hallo,
ich habe gerade updatet (von 0.6.9 zu 0.7.36).
Soweit alles gut, nur ein Problemchen ist gleich aufgetaucht:
  Nach jedem Neustart aktualisiert sich die ESP-System-Zeit nicht mehr 
automatisch, wie das vorher war. Ich muss manuell auf "sync from 
browser" klicken.
Wenn die Systemzeit nicht eingestellt ist, verbindet sich auch MQTT 
nicht. Und das ist nicht gut.
Die Einstellungen sind gleich (NTP-Server) wie in meiner vorheriger ver. 
0.6.9
Gibt es da etwas, was ich noch einstellen muss? Sonst muss ich zurück zu 
v0.6.9

Vielen Dank im Voraus

[Grisu (krisu)]

Funktioniert hier seit Anbeginn (begonnen mit v0.5.16) einwandfrei.
Hast du DHCP aktiviert?
NTP Einstellung bei mir wie folgt:
Server: pool.ntp.org
Port: 123
Intervall: 720s (5 Min.)

[Pavel (pali)]

die NTP Einstellungen habe ich gleich wie bei dir (sind default). Das 
war auch in der ver 0.6.9 gleich.
DHCP habe ich nicht aktiviert, habe feste IP für Ahoy folgend 
konfiguriert:
IP Address:192.168.178.46
Submask:255.255.255.0
DNS 1: (leer gelassen)
DNS 2: (leer gelassen)
Gateway:192.168.178.1

So hat das bis jetzt auch problemlos funktioniert (in ver 0.6.9). Ob die 
feste IP so richtig konfiguriert ist, bin ich nicht ganz sicher :-)

  Ich habe jetzt aber eine neue Inverter-Einstellung gefunden (in ver 
0.7.36), welche in der ver 0.6.9 nicht vorhanden war:
  "Start without time sync"
Wenn ich das erlaube, dann funktioniert der Neustart (reboot) wie 
vorher. ESP-SystemZeit wird auch gleich automatisch eingestellt und MQTT 
startet auch. Woher die richtige Zeit genommen wird, keine Ahnung :-)

[Sven K. (svenk)]

Hallo,
setze mal den Dns 192.168.178.1 wie dein Gateway - dann sollte es 
funktionieren
Gruß Sven

[Daniel (smitna)]

Sven K. schrieb:
> Hallo,
> setze mal den Dns 192.168.178.1 wie dein Gateway - dann sollte es
> funktionieren
> Gruß Sven

Interessante Aussage!
Wie kommst Du zu der Erkenntnis, dass beim Fragesteller auf dem GW 
192.168.178.1 ein DNS-Server oder Forwarder läuft?
Bitte bei Unkenntnis keine Tipps geben.

Ggf. wäre es zielführender, statt z.B. pool.ntp.org die passende 
IP-Adresse einzutragen und dann nochmal zu testen.

[Heinz R. (heijz)]

Daniel schrieb:
> Bitte bei Unkenntnis keine Tipps geben

mit dem linken Bein aufgestanden heute?

[Grisu (krisu)]

Ist schon einigermaßen naheliegend, daß sein Modem 192.168.178.1 hat und 
DNS anbietet fürs Heimnetz.

Daher hätte ich auch DHCP vorgeschlagen gehabt, damit auch der DNS 
mitübergeben wird.
Fixe IP-Vergabe vorzugsweise im Modem einstellen für die gewünschten 
Geräte, dadurch erspart man sich genau diese Probleme den Aufwand, die 
überall manuell eingeben zu müssen - und erhalten dennoch immer die 
selbe gewünschte IP.

[Pavel (pali)]

Danke,
jetzt funktioniert es.
Wie von Grisu vorgeschlagen, habe ich in Ahoy-DTU alle Network-Parameter 
leer gelassen um DHCP zu aktivieren.
Die Inverter-Einstellung "Start without time sync" habe ich auch wieder 
deaktiviert.
In meiner FritzBox habe ich für dieses Gerät Fixe IP eingestellt.
Jetzt funktioniert nach dem reboot alles normal.

Auch wenn meine andere ESP8266 Geräte gut funktionieren, werde ich das 
wahrscheinlich überall so einstellen ... es ist so wahrscheinlich 
vernünftiger ... obwohl ich nicht verstehe, warum :-)   Ist aber egal, 
ich muss nicht alles verstehen :-)

PS: ja, mein Modem/FritzBox hat 192.168.178.1

[Grisu (krisu)]

Weil du keinen DNS angegeben hattest, der den Namen des ntp-Servers 
hätte auflösen können auf eine IP-Adresse.
Mit DHCP wird auch der DNS an den Client kundgetan.
Vereinfacht halt die ganze Verwaltung wenn man es zentral am Modem 
einträgt für alle gewünschten Clients und die einfach auf DHCP läßt.

[Daniel (smitna)]

Heinz R. schrieb:
> Daniel schrieb:
>> Bitte bei Unkenntnis keine Tipps geben
>
> mit dem linken Bein aufgestanden heute?

Das kommt immer auf den Tag und das Bein an.
Hast Du auch fachlich etwas beizutragen?

[Pavel (pali)]

Hallo,
was bedeutet dieser Wert in den Inverter Einstellungen?:
  "Yield Effiency (should be between 0.95 and 0.96)"

Ich habe dort 1 (defaul).
Werden mit diesem Faktor die Yield-Zähler korrigiert (Yield Day, Yield 
Total)?

Danke.

[Grisu (krisu)]

Ich nehme an das sind einfach nur die Leistungsverluste des WR zw. 
DC-Einspeisung und AC-Abgabe.
Yield ist der Ertrag (erzeugte Energie also).

[Heinz R. (heijz)]

Ich habe hier 2 x OpenDTU
- der eine liest  3 x HMS-2000 aus
- der andere 4 x HM-1200

was mich jetzt wundert:

Schaue ich abends nach Sonnuntergang ins Webinterface:

Bei den HM-1200 steht der Tagesertrag
Bei den HMS-2000 ist nach Sonnenuntergang der Tagesertrag auf Null 
gesetzt

die OpenDTU für die HMS-2000 läuft auf Firmware 23.6.28
Die HM-1200- noch Version 23.5.9

Ich hatte mal Ahoy installiert - dort konnte man einstellen wann was 
resetet wird - bei OpenDTU finde ich hier keine Einstellung?

Würde gerne abends beim Geierabendbier sehen was die Anlagen jeweils 
gebracht haben - was mache ich falsch?

Grüße

[Grisu (krisu)]

Ich habe sowohl eine Ahoy als auch eine OpenDTU in Betrieb.
Beide zeigen auch nach dem Sonnenuntergang noch den Vortageswert an bis 
zum Morgen. Ahoy grau unterlegt, OpenDTU ganz normal wie auch untertags.

Solltest vielleicht doch einmal überlegen die aktuelle Version zu 
verwenden. ;-)
Und ich habe bei Wechselrichter Senden/Empfangen nur "Daten abrufen" 
aktiviert und bei NTP die "bürgerliche Dämmerung" eingestellt, sollte 
aber ohne Bedeutung sein.

[Heinz R. (heijz)]

Grisu schrieb:
> Beide zeigen auch nach dem Sonnenuntergang noch den Vortageswert an bis
> zum Morgen. Ahoy grau unterlegt, OpenDTU ganz normal wie auch untertags.

Hast Du HM oder HMS-Wechselrichter?

Bei mir sind bei beiden die Einstellungen gleich

[Grisu (krisu)]

Auf Ahoy sind HM (da nur ESP8266) und auf der OpenDTU hängen HMT.

Nur, warum machst nicht erstmal ein Update auf gleiche Stände, um nur 
irgendwas sinnvoll vergleichen zu können?

[Heinz R. (heijz)]

Grisu schrieb:
> Nur, warum machst nicht erstmal ein Update auf gleiche Stände, um nur
> irgendwas sinnvoll vergleichen zu können?

der für die Abends nichts anzeigenden HMS-WR zuständige hatte ich 
bereits upgedatet

Aber bin jetzt deinem Ratschlag gefolgt, beide ESPs sind auf Version 
v23.9.18

Das leider ernüchternde Resultat:
- OpenDTU mit 4 x HM-1200 zeigt auch jetzt bei Dunkelheit den 
Tagesertrag an
- OpenDTU mit 3 x HMS-2000 zeigt jetzt bei Tagesertrag null an

Unterschiede in den Einstellungen finde ich keine

Gibt es sonst jemand mit HMS-WR?  Was wird hier abends angezeigt?

[Heinz R. (heijz)]

Heinz R. schrieb:
> Gibt es sonst jemand mit HMS-WR?  Was wird hier abends angezeigt?

es wird immer merkwürdiger

aktuell zeigen nach Sonnenuntergang 2 der 3 HMS-WR den Tagesertrag an, 
bei einem steht der auf Null?

[Grisu (krisu)]

Vielleicht schlechter Empfang zu dem und aufgrund aussetzender Werte 
dann das Bild ...
Oder was mir noch einfiele dazu.
Vielleicht schaltet der wegen Überspannung auf der Phase im Netz ab bzw. 
weil er der hinterste in der Reihe ist mit der folglich höchsten 
Spannung die grad schon das Abschalten bewirkt, dann ist für ihn ja ein 
neuer Tag wo er noch nichts produziert hat.
Beobachte ihn halt mal einen ganzen Tag lang bzw. sie dir die 
MQTT-Einträge an.

[Heinz R. (heijz)]

nein, es muss ein anderes Problem sein

Jetzt ist die Snne seit 4 Stunen weg
2 von 3 HMS zeigen beim Tagesertrag je ca. 9 kWh an - das passt und wird 
so in der Gesamt-Tagessumme auch angezeigt
Der 3. HMS zeigt beim Tagesertrag 0 an

Die 4 HM zeigen jetzt alle beim Tagesertrag realistische Werte an

[Grisu (krisu)]

Hängt sich ein ESP32 und openDTU mit der Zeit auf?
Lief eigentlich klaglos, jedoch nach dem letzten Update vor einigen 
Tagen auf v23.9.18 hat er heute keine Werte mehr übertragen bekommen vom 
WR. Neustart änderte nichts daran, dachte schon der WR wäre über Nacht 
ausgefallen.
Kurz die DTU vom Strom genommen und nun geht es wieder.

Passiert das anderen hier auch oder Einzelfallproblem?

[Lutz S. (lutzs)]

Hier läuft das seit Monaten problemlos mit Version 23.4.25.

[Cpt. H. (cpt_h)]

Moin Leute,
hatte mir den AhoyDTU für meinem Hoymiles HM-600 gebaut und das lieft 
auch schon ein paar Wochen ganz gut.
Gestern habe ich den Standort vom AhoyDTU geändert und da er dadurch 
näher an meinem zweiten Router gekommen ist auch den WLAN Zugang 
angepasst.
Jetzt sehe ich nur noch eine abgespeckte Version des Menue mit den 
Punkten
-AhoyDTU
-Rest API
-Documentation
-About

alles andere wird nicht mehr angezeigt. Auch der Punkt settings nicht, 
um das wieder rückgägngig machen zu können.
Seltsamerweise werden die Daten offensichtlich weiterhin in 
HomeAssistant eingespeist, da kommt es im Energiedashboard jedenfalls 
an.
Für einen schnellen Blick ist mir die weboberfläche von AhoyDTU aber 
lieber.
Was könnte ich tun?

Danke
Hardy

[Grisu (krisu)]

Na dann hast wohl auch ein FW-Update gemacht und mußt vorher am Ahoy 
anmelden (Login).

[Barny F. (barny)]

Grisu schrieb:
> Hängt sich ein ESP32 und openDTU mit der Zeit auf?
> Lief eigentlich klaglos, jedoch nach dem letzten Update vor einigen
> Tagen auf v23.9.18 hat er heute keine Werte mehr übertragen bekommen vom
> WR. Neustart änderte nichts daran, dachte schon der WR wäre über Nacht
> ausgefallen.
> Kurz die DTU vom Strom genommen und nun geht es wieder.
>
> Passiert das anderen hier auch oder Einzelfallproblem?

Das passiert bei mir auch seit ein paar Firmware-Versionen.
(Also die Aktuelle v23.10.9, v23.9.18 und v23_9_13)
Ich habs so gelöst dass ich den ESP ein oder zwei mal in der Woche in 
der Nacht kurz vom Strom nehme.

Ich habe schon einen 3,3V / 1,5A Festspannungsregler extern 
angeschlossen weil ich vermutet habe dass der kleine Onboard-Regler 
kurzzeitig überlastet ist und der ESP in Brown-out geht.
Der hat das Problem aber nicht behoben.
(Das Netzteil war erst ein 25W Handyladegerät, jetzt ist es ein 9V, 30VA 
Trafo)

Ich hab schon überlegt einen externen Watchdog anzuschließen der das 
Aus-/ Einstecken für mich übernimmt.

[Grisu (krisu)]

Danke für deine Rückmeldung, dann besteht ja zumindest die Hoffnung, daß 
jemand den Fehler entdeckt und dieser behoben werden kann.

[Helmut H. (der_andere)]

Mir ist es mit Annex ESP32Basic gelungen so ein AZ-Wanddisplay zur 
Anzeige von Hoymiles Wechselrichter mit OpenDTU zu programmieren.
Inzwischen kann ich auch die Leistung über ESP32 Annex Basic einstellen.
Also nicht über MQTT sondern per in Annex ESP32Basic übersetztem Curl 
Befehl.
Wenn man also z.B. einen Shelly EM per Json abfragt, könnte man ohne 
andere Server (z.B. MQTT-Broker, Openhab, Symcon o.ä. die 
Nulleinspeisung in diesem ESP32 per ESP32 Annex Basic regeln.
Guggst Du https://cicciocb.com/forum/viewtopic.php?p=5404#p5404

[Heinz R. (heijz)]

so was bekommst auch mit ESPEasy sehr einfach hin, eagl ob jetzt per 
MQTT oder direkt
Selbst Touch ist dort rel. einfach umzusetzen

[Helmut H. (der_andere)]

wlog WPOST$("http://admin:password@192.168.x.x/api/limit/config";, 
|data={"serial":"1234567890", "limit_type":1, "limit_value":50}|, 0, 
"application/x-www-form-urlencoded")
Das ist der Befehl in ESP32 Annex Basic um die Leistung zu stellen.
Vorher status Abfrage machen.
Ganz ohne MQTT Brokker oder andere Geschichten.
@Heinz
zeige mir den Befehl in ESPeasy, der das Gleiche macht. Und wenn das 
nicht klappt wenigstens die Parameter und Listings für die 
Displaydarstellung.

[Heinz R. (heijz)]

Helmut H. schrieb:
> @Heinz
> zeige mir den Befehl in ESPeasy, der das Gleiche macht. Und wenn das
> nicht klappt wenigstens die Parameter und Listings für die
> Displaydarstellung.

mit Leistungslimits habe ich mich zugegeben nie beschäftigt, ich habe 
hier eine offiziell Angemeldete Anlage die auch einspeisen darf

Aber laut 
https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md

curl -u "admin:password" http://192.168.10.10/api/limit/config -d 
'data={"serial":"11418180xxxx", "limit_type":1, "limit_value":50}'

Ein ganz normales HTTP Post..
Klar, curl gibt es in ESPEasy nicht :-)

Parameter und Listings? Ich habe für meinen Herrn Papa eine kleine 
7Segment-Anzeige gebastelt die sich den Wert von OpenDTU holt

Wenn es unbedingt kein MQTT sein darf legst halt in ESPEasy ein 
Dummy-Device an, holst Dir alle paar Sekunden den Wert aus OpenDTU, das 
ist ja gut dokumentiert

das Display kannst z.B. so beschreiben:

on wasacuhimmer#abc do
 tft,rf,10,10,300,60,red,red
 tft,txtfull,110,55,3,white,black,rot
endon

Aber irgendwann wirst merken das so ein MQTT-Server durchaus seinen SInn 
hat - macht vieles einfacher, und es gibt auch öffentliche..

[Matthias S. (mat-sche)]

Ein mächtiges Hallo in die Runde!
Ersteinmal vielen Dank für Eure Arbeit zum OpenDTU!
Nun zu meiner Frage, ist es möglich auch ein anderes SPI-Display mit der 
Auflösung 128x64 pixel zu nutzen? Das Display besitzt einen Sitronix 
ST7565R-G Controller und den habe ich erfolgreich mit der u8glib mit den 
ESPs in Betrieb. Und wenn ich das richtig heraus gelesen habe, wird ja 
in dem Code für die OPEN DTU auch die Lib benutzt.
Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display 
einbinden kann?
Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und 
C++ Programme gearbeitet, wie kann ich dann den Code compelieren?
Ein Tip und Hilfe würde ich mich sehr freuen.
Grüße MAT

[Daniel (smitna)]

Matthias S. schrieb:
> Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display
> einbinden kann?
> Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und
> C++ Programme gearbeitet, wie kann ich dann den Code compelieren?

Zur ersten Frage kann ich nichts antworten, aber diese wäre sicher 
besser in den "Discussions" auf https://github.com/tbnobody/OpenDTU/ 
aufgehoben. Eine Anleitung zum Kompilieren findest Du unter "Flashing 
and starting up" ebenfalls auf GitHub.

[Matthias S. (mat-sche)]

Daniel schrieb:
> Matthias S. schrieb:
>> Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display
>> einbinden kann?
>> Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und
>> C++ Programme gearbeitet, wie kann ich dann den Code compelieren?
>
> Zur ersten Frage kann ich nichts antworten, aber diese wäre sicher
> besser in den "Discussions" auf https://github.com/tbnobody/OpenDTU/
> aufgehoben. Eine Anleitung zum Kompilieren findest Du unter "Flashing
> and starting up" ebenfalls auf GitHub.

Hallo Daniel, danke für adeinen Hinweis, habe dort auch schon die Frage 
platziert. Dachte bei der Regen Teilnahme hier, dass es ein Hinweis 
geben könnte.
MAT

[Peter S. (cbscpe)]

> Grisu schrieb:
>
> Vieleicht noch ein Nachteil den man bedenken sollte:
> Einen Akku nachrüsten ist nicht ganz einfach und auch nicht günstig, da
> man für den Akku dann wieder einen WR braucht.
> Aber das ist ja ein anderes Thema.
>
Das ist gar nicht so teuer. Und vor allem ganz einfach. Ein Multiplus II 
reicht. Gibt es ab 500€. Der kann alles was man zu einem AC gekoppelten 
Speicher braucht, dazu braucht es noch eine Steuerung. Wenn man nicht zu 
viel Basteln will nimmt man ein Cerbo GX (das -S hat kein CAN BUS für 
Batterien) für etwa 200€ und Bastelafine nehmen dafür einen Raspi. Im 
youtube gibt es einige Kanäle, wie etwa Schatten PV, Kleines Zuhause und 
andere die genau zu diesem Punkt Thema Videos gemacht haben. Der 
Multiplus wird mit AC Out einfach an den Verteiler angeschlossen und 
Batterie dran. Fertig ist. Das ist natürlich nicht Schwarzstart fähig, 
aber das wird denke ich überbewertet. Wer will kann am AC In noch eine 
Notsromsteckdose anschliessen die Strom abgibt so lange der Akku Saft 
hat.

[Alexander H. (agentsmith1612)]

Was sagt ihr dazu?
Hat jemand mehr Details?
https://www.cleanthinking.de/bnetza-hoymiles-hm-800-wechselrichter/

[Daniel (smitna)]

Alexander H. schrieb:
> Was sagt ihr dazu?
> Hat jemand mehr Details?
> https://www.cleanthinking.de/bnetza-hoymiles-hm-800-wechselrichter/

Da hier wohl keine Antwort erfolgt und das auch nicht wirklich der 
richtige Platz ist, zumindest ein Link mit weiteren Infos und 
Stellungnahmen:

https://www.photovoltaikforum.com/thread/226815-hm-800-von-der-bundesnetzagentur-vom-markt-genommen/

Ergo:
Betrieb der WR weiter kein Problem, Vertrieb aber (vorläufig) 
eingestellt.

[Tim T. (tim_taylor)]

Nabend,

da der Thread, zumindest für mich, mittlerweile ziemlich unübersichtlich 
geworden ist und ich keine Lust habe die nächste Woche damit zu 
verbringen alle Beiträge durchzulesen, kann mir eventuell jemand sagen 
wo ich die aktuelle Version für einen Arduino finde.
Also ich suche nichts für einen ESP sondern einfach nur das Protokoll 
für die Kommunikation über SPI. Hintergrund ist, das ich noch einen 
ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP 
nicht brauche und auch nicht will. Es reicht mir wenn das mein 
Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino 
empfängt und entsprechend aufarbeitet.

[Heinz R. (heijz)]

Tim T. schrieb:
> Hintergrund ist, das ich noch einen
> ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP
> nicht brauche und auch nicht will. Es reicht mir wenn das mein
> Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino
> empfängt und entsprechend aufarbeitet.

um damit 2€ zu sparen?

Merkwürdige Vorstellung....

[Tim T. (tim_taylor)]

Heinz R. schrieb:
> Tim T. schrieb:
>> Hintergrund ist, das ich noch einen
>> ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP
>> nicht brauche und auch nicht will. Es reicht mir wenn das mein
>> Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino
>> empfängt und entsprechend aufarbeitet.
>
> um damit 2€ zu sparen?
>
> Merkwürdige Vorstellung....

Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die 
Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen 
Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler 
mit einem Vollwertigen System machen kann, was die Daten sehr einfach 
exakt so aufbereitet wie ich es will?

[Daniel (smitna)]

> Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die
> Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen
> Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler
> mit einem Vollwertigen System machen kann, was die Daten sehr einfach
> exakt so aufbereitet wie ich es will?

Ja, das verstehe ich. Die Community um AhoyDTU und OpenDTU mit ihren 
instabilen ESPs können nur irren. Ein vollwertiges System mit einem 
Arduino ist da ohne Alternativen.

[Tim T. (tim_taylor)]

Daniel schrieb:
>> Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die
>> Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen
>> Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler
>> mit einem Vollwertigen System machen kann, was die Daten sehr einfach
>> exakt so aufbereitet wie ich es will?
>
> Ja, das verstehe ich. Die Community um AhoyDTU und OpenDTU mit ihren
> instabilen ESPs können nur irren. Ein vollwertiges System mit einem
> Arduino ist da ohne Alternativen.

Und schon wieder absolut unnötiges Geblubber. Was die AhoyDTU oder die 
OpenDTU kann oder nicht, ist mir absolut egal, weil ich es weder will 
noch brauche. Fakt ist nunmal das die ESP sehr wählerisch bei der 
Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist, 
hängen sie sich auf. Dazu kommt dann irgendwelche überfrachtete Software 
die alles andere als ausentwickelt ist und weitere Probleme macht, wobei 
ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und 
der ganze Rest nur unnötiger Raffel ist. Dazu kommt das es natürlich 
sehr sinnvoll ist, im gleichen Frequenzbereich die Daten weiter zu 
schicken in dem man sie empfängt. Letztlich soll mir der Arduino nur als 
Umsetzer von Nordic auf USB dienen und sonst möglichst garnix machen. 
Wer das nicht verstehen will, dem kann ich auch nicht helfen.

[Heinz R. (heijz)]

Tim T. schrieb:
> Und schon wieder absolut unnötiges Geblubber
sorry, in meinen Augen nicht so - es wurde halt was vernünftig mit 
aktuellen Prozessoren umgesetzt

Tim T. schrieb:
> Fakt ist nunmal das die ESP sehr wählerisch bei der
> Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist,
> hängen sie sich auf.

Wie kommst Du auf solche Ausssagen?

Tim T. schrieb:
> Dazu kommt dann irgendwelche überfrachtete Software
> die alles andere als ausentwickelt ist und weitere Probleme macht, wobei
> ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und
> der ganze Rest nur unnötiger Raffel ist.

Ziemlich freche Aussage - warum bettelst hier und programmierst nicht 
selber kurz was?

Tim T. schrieb:
> Wer das nicht verstehen will, dem kann ich auch nicht helfen.

Du hast sicher auch nur 3beinige Tische daheim - das 4. Bein ist 
unnützer Ballast? :-)

[Tim T. (tim_taylor)]

Heinz R. schrieb:
> Tim T. schrieb:
>> Und schon wieder absolut unnötiges Geblubber
> sorry, in meinen Augen nicht so - es wurde halt was vernünftig mit
> aktuellen Prozessoren umgesetzt

Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm 
ab:
1. Brauche ich eine komplexere HMI-Schnittstelle (Display, 
Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC
2. Einfache Sachen aber mit WLAN: ESP32
3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32
4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum: 
ATtiny
5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino.

Und das hat genau garnix mit dem Thema zu tun.

>
> Tim T. schrieb:
>> Fakt ist nunmal das die ESP sehr wählerisch bei der
>> Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist,
>> hängen sie sich auf.
>
> Wie kommst Du auf solche Ausssagen?

Betreibe seit längerer Zeit mehrere ESP32, unter anderem zum auslesen 
meines Stromzählers. IR-Diode Seriell auslesen und als UDP-Paket an 
meinen Server wo dann etwas Nachbearbeitung erfolgt und in eine MySql 
Tabelle geschrieben wird. Oder auch in meinem APRS Tracker für 
Wetterballons.

>
> Tim T. schrieb:
>> Dazu kommt dann irgendwelche überfrachtete Software
>> die alles andere als ausentwickelt ist und weitere Probleme macht, wobei
>> ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und
>> der ganze Rest nur unnötiger Raffel ist.
>
> Ziemlich freche Aussage - warum bettelst hier und programmierst nicht
> selber kurz was?

Genau darum geht es ja, ich suche nur das Protokoll. Aber bin schon 
dran, wollte es mir nur einfacher machen bevor ich jetzt wieder Zeit 
damit verschwende entsprechende Informationen aus dem Quelltext der 
AhoyDTU zu extrahieren.

>
> Tim T. schrieb:
>> Wer das nicht verstehen will, dem kann ich auch nicht helfen.
>
> Du hast sicher auch nur 3beinige Tische daheim - das 4. Bein ist
> unnützer Ballast? :-)

Ja, ich habe (auch) 3 Beinige Tische zuhause, unter Anderem wegen der 
(eventuell nicht dir) bekannten Vorteile.

[Heinz R. (heijz)]

Tim T. schrieb:
> Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm
> ab:
> 1. Brauche ich eine komplexere HMI-Schnittstelle (Display,
> Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC
> 2. Einfache Sachen aber mit WLAN: ESP32
> 3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32
> 4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum:
> ATtiny
> 5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino.
>
> Und das hat genau garnix mit dem Thema zu tun.

dann mach das doch gerne so - aber nicht beleidigt sein wenn hier 99% 
anders denken

Du hast wahrscheinlich auch 2 Autos, eins mit, eins ohne Servo - vor der 
Fahrt wird Einsatzenstsprechend gewählt?

[Tim T. (tim_taylor)]

Heinz R. schrieb:
> Tim T. schrieb:
>> Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm
>> ab:
>> 1. Brauche ich eine komplexere HMI-Schnittstelle (Display,
>> Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC
>> 2. Einfache Sachen aber mit WLAN: ESP32
>> 3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32
>> 4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum:
>> ATtiny
>> 5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino.
>>
>> Und das hat genau garnix mit dem Thema zu tun.
>
> dann mach das doch gerne so - aber nicht beleidigt sein wenn hier 99%
> anders denken

Ob es wirklich 99% sind wage ich zu bezweifeln, aber selbst wenn, was 
hat das schon für eine Bedeutung? Eine Mehrheit, egal bei welchem Thema, 
sagt noch überhaupt nichts über die Qualität der Aussage aus.

> Du hast wahrscheinlich auch 2 Autos, eins mit, eins ohne Servo - vor der
> Fahrt wird Einsatzenstsprechend gewählt?

Fast, es sind zwei Autos, Kleinwagen und Kombi und ja, es wird 
entsprechend vor dem Einsatz gewählt. Aber im Jahr 2024 haben beide 
schon Servolenkung...

[Christian B. (Gast)]

Tim T. schrieb:
> Betreibe seit längerer Zeit mehrere ESP32, unter anderem zum auslesen
> meines Stromzählers.

Habe ich auch (allerdings über MBus). Der ESP hat inzwischen einen 
Arduino Nano als externen Watchdog, weil er sich ~ 1x am Tag aus 
unerfindlichen Gründen aufgehängt hat ...

PS.:
Was Du hier (sicher nicht zum ersten Mal) erlebst ist leider inzwischen 
für die meisten Foren typisch.
Es wird unheimlich viel Energie aufgewendet, Dir die Herangehensweise 
des Antwortenden näherzubringen, weil Derjenige annimmt, wenn Du das, 
was Du fragst nicht weißt, wirst Du wohl überhaupt ein Trottel sein, und 
er muss Dich bel(k)ehren.
Dass es durchaus Vorteile haben kann etwas Älteres  Einfacheres  
Bekanntes zu verwenden, erschließt sich allerdings den Meisten in ihrer 
Schlichtheit nicht!

[Lars B. (docbmuc)]

@Tim Taylor (DER Heimwerkerking? ;-) ):
Ich sehe da kein Problem mit dem Arduino-Interface und ich weiss nicht, 
warum hier so emotionale Diskussionen entstehen. ;-)
=> Im entsprechenden github Repository https://github.com/lumapu/ahoy
findest Du Doku über das Protokoll, die Sourcen und auch Hardware, etc. 
Damit sollte es easy sein, die Parameter Deines WR auszulesen.

@Heinz R:
Die Anfrage von Tim ist doch kein Grund, missionarisch zu werden. ;-)
Die ESPs sind nicht schlecht, haben aber auch durchaus ihre Schwächen. 
Ich verstehe seinen Ansatz, einfach einen Arduino als kleinen 
Protokollwandler/Interface für einen Rechner o.ä. einsetzen zu wollen.

Und jetzt vertragen wir uns alle mal wieder. ;-) :-)

Cheers!

[Tim T. (tim_taylor)]

Christian B. schrieb:
> Tim T. schrieb:
>> Betreibe seit längerer Zeit mehrere ESP32, unter anderem zum auslesen
>> meines Stromzählers.
>
> Habe ich auch (allerdings über MBus). Der ESP hat inzwischen einen
> Arduino Nano als externen Watchdog, weil er sich ~ 1x am Tag aus
> unerfindlichen Gründen aufgehängt hat ...

Das gleiche hatte ich auch und meine (vorübergehende) Lösung war eine 
elektronische Zeitschaltuhr die irgendwann mitten in der Nacht für 1 
Minute die Spannungsversorgung unterbrochen hat. Die Finale Lösung war 
dann aber das Steckernetzteil von einem alten Amazon Fire TV-Stick, das 
hat zwar auch nur 5W aber irgendwie kommt der ESP damit besser klar als 
mit allen Netzteilen zuvor, egal ob von Apple oder sonst einem 
Hersteller mit 10W.

> PS.:
> Was Du hier (sicher nicht zum ersten Mal) erlebst ist leider inzwischen
> für die meisten Foren typisch.

Gefühlt ist es in den letzten Jahren hier deutlich schlimmer geworden.

> Es wird unheimlich viel Energie aufgewendet, Dir die Herangehensweise
> des Antwortenden näherzubringen, weil Derjenige annimmt, wenn Du das,
> was Du fragst nicht weißt, wirst Du wohl überhaupt ein Trottel sein, und
> er muss Dich bel(k)ehren.

Ja, und das von Leuten die nicht die geringste Ahnung vom Background des 
jeweiligen Fragestellers haben.

> Dass es durchaus Vorteile haben kann etwas Älteres / Einfacheres /
> Bekanntes zu verwenden, erschließt sich allerdings den Meisten in ihrer
> Schlichtheit nicht!

Ja, nicht jeder versteht das KISS Prinzip.


Lars B. schrieb:
> @Tim Taylor (DER Heimwerkerking? ;-) ):

Ja, so in etwa^^.

> Ich sehe da kein Problem mit dem Arduino-Interface und ich weiss nicht,
> warum hier so emotionale Diskussionen entstehen. ;-)
> => Im entsprechenden github Repository https://github.com/lumapu/ahoy
> findest Du Doku über das Protokoll, die Sourcen und auch Hardware, etc.
> Damit sollte es easy sein, die Parameter Deines WR auszulesen.

Ja, hatte das Repo mittlerweile auch gefunden, nur fälschlicherweise 
zuerst den nano Ordner unter tools genommen bevor ich dann beim 
NRF24_SendRcv gelandet bin. Aber auch das Zeug darin ist nicht wirklich 
brauchbar.
Ich denke aber, das ich jetzt mit den Infos aus dem doc Ordner und den 
Quelltexten der AhoyDTU eigentlich alles zusammen habe.
Das Einzige was mir immer noch unklar ist, ist die Kanalwahl und das 
Hopping Schema...

[Heinz R. (heijz)]

Zum Thema ESPxx - Abstürze

Man hat hier mit den tollen Ahoy / OpenDTU Projekten viele zig tausend 
Testuser - die Foren sind bemerkenswerter Weise nicht voll mit "stürzt 
ständig ab" usw

Ich bin gespannt auf Deine Arduino-Implementierung - ich hoffe Du 
veröffentlichst die dann auch im Sinne der Projekte entsprechend - es 
ist ja dann ein gewaltiger Schritt nach vorne - wesentlich mehr 
Zuverlässigkeit - wobei Du von den Erkenntnissen und Forschungen anderer 
profitierst

Nicht böse gemeint - aber Dein Beizrag kommt irgendwie rüber wie "schön 
das Ihr da was gebastelt habt - gebt mal den Code rüber, dann mache ich 
es richtig"

[Daniel (smitna)]

@Tim Taylor

Du nimmst wohl an, dass alle anderen wenig Ahnung von der Materie haben,
was Deine Aussagen unterstreichen wie
"Ja, nicht jeder versteht das KISS Prinzip."
Du diffamierst eine Entwicklergruppe mit ihrem Projekt pauschal mit
Zitat: "irgendwelche überfrachtete Software, die alles andere als 
ausentwickelt ist und weitere Probleme macht".
Aber dann sagst Du wieder, Projekte bei
"Einfache Sachen aber mit WLAN: ESP32" umzusetzen, was nicht wirklich 
zusammenpasst.
Nebenbei: Ich bin Informatiker und kenne das "KISS-Prinzip" seit vielen 
Jahren und habe Projekte mit unterschiedlichen
Mikrocontrollern umgesetzt.
Also bitte keine derartigen  unbelegten Thesen in einem Fachforum.

Ich habe selbst mehrere Projekte mit dem ESP32 auf Basis AhoyDTP 
(mehrere Mikrowechselrichter der HM-Serie) und OpenDTU (HMS-Serie)
umgesetzt.
Diese ESP laufen störungsfrei ununterbrochen seit vielen Monaten.
Deine genannten "Instabilitäten" sind daher lediglich eine Behauptung, 
die ohne Nennung einer bestimmten (evtl. problematischen) 
Hardwarekonstellation keine Grundlage hat.
Bei den ESP8266 stimme ich Dir unter bestimmten Bedingungen zu, aber das 
war ja nicht Dein Thema.

Auch nebenbei: Projekte wie "Tasmota" sind praktisch die Open 
Source-Referenz im ESP-Bereich.
ESPs auf dieser Basis laufen (auch bei mir) problemlos seit Jahren ohne 
Ausfall.
Vorschlag:
Wende Dich doch mit Deinem Problem und genau mit Deinen bisherigen 
Aussagen direkt an die Hauptentwickler der beiden Projekte auf GitHub.
Mich würde dann aber interessieren, wie das dann dort ankommt und wie 
Dir geholfen wird.

[Tim T. (tim_taylor)]

Daniel schrieb:
> @Tim Taylor
>
> Du nimmst wohl an, dass alle anderen wenig Ahnung von der Materie haben,
> was Deine Aussagen unterstreichen wie
> "Ja, nicht jeder versteht das KISS Prinzip."
> Du diffamierst eine Entwicklergruppe mit ihrem Projekt pauschal mit

Nein, nicht die Entwicklergruppe, nur diejenigen, die immer noch nicht 
verstehen (wollen), was ich eigentlich haben will und mich weiter 
bekehren wollen. Wer eine Ahoy DTU haben will, soll sie benutzen, auf 
meinen Usecase trifft sie jedoch nicht zu.

> Zitat: "irgendwelche überfrachtete Software, die alles andere als
> ausentwickelt ist und weitere Probleme macht".

Schau dir die Issues an. Ich will ein System das ich einmal anwerfe und 
woran ich im besten Fall nie wieder denken muss. Kombiniert mit kleiner 
Energieaufnahme.

> Aber dann sagst Du wieder, Projekte bei
> "Einfache Sachen aber mit WLAN: ESP32" umzusetzen, was nicht wirklich
> zusammenpasst.

Sag mal begreifst du es echt nicht? ES SOLL KEIN WLAN BENUTZT WERDEN!

1. Der WR kommuniziert über Nordic mit dem NRF24L01+
2. Der NRF24L01+ kommuniziert über SPI mit dem Arduino
3. Der Arduino kommuniziert über RS232 mit dem FTDI
4. Der FTDI kommuniziert über USB mit dem Server
5. Der Server kümmert sich um den Rest

Der Arduino haut dabei nur stumpf die Requests an den WR raus und leitet 
die Antworten, bei denen die CRC stimmt, an den Server weiter. Mehr 
nicht, keine Auswertung, keine tollen Menüs, nichts.

Ansonsten bedeutet "Einfache Sachen" für mich in dem Zusammenhang auch 
das keine besonderen Anforderungen an die Zuverlässigkeit bestehen.

> Nebenbei: Ich bin Informatiker und kenne das "KISS-Prinzip" seit vielen
> Jahren und habe Projekte mit unterschiedlichen
> Mikrocontrollern umgesetzt.

Ja, und ich bin (Software)entwickler für Eingebettete Systeme und 
verdiene mein Geld hauptberuflich mit Softwareentwicklung auf STM32 und 
PIC im Automobilbereich. So what?

> Also bitte keine derartigen  unbelegten Thesen in einem Fachforum.

Kennen und verstehen sind zwei Paar Stiefel.

> Ich habe selbst mehrere Projekte mit dem ESP32 auf Basis AhoyDTP
> (mehrere Mikrowechselrichter der HM-Serie) und OpenDTU (HMS-Serie)
> umgesetzt.
> Diese ESP laufen störungsfrei ununterbrochen seit vielen Monaten.
> Deine genannten "Instabilitäten" sind daher lediglich eine Behauptung,
> die ohne Nennung einer bestimmten (evtl. problematischen)
> Hardwarekonstellation keine Grundlage hat.
> Bei den ESP8266 stimme ich Dir unter bestimmten Bedingungen zu, aber das
> war ja nicht Dein Thema.

Schön für dich und richtig, der ESP ist immer noch nicht mein Thema.

> Auch nebenbei: Projekte wie "Tasmota" sind praktisch die Open
> Source-Referenz im ESP-Bereich.
> ESPs auf dieser Basis laufen (auch bei mir) problemlos seit Jahren ohne
> Ausfall.

Schön das es für deinen Usecase passt.

> Vorschlag:
> Wende Dich doch mit Deinem Problem und genau mit Deinen bisherigen
> Aussagen direkt an die Hauptentwickler der beiden Projekte auf GitHub.
> Mich würde dann aber interessieren, wie das dann dort ankommt und wie
> Dir geholfen wird.

Warum? Glaubst du ernsthaft ich investiere weiter Zeit mit ungewissem 
Ausgang anstatt das jetzt mit den zugegeben dürftigen Informationen 
selber zusammen zu knüppeln?
Und bevor wieder die Keule mit den unbelegten Thesen kommt:

Wo steht was die CMDs 0x03, 0x83 und 0x84 machen?
Nach welchem Schema läuft das Channelhopping ab?
Gibt es für den HM-1500 irgendwo bessere Informationen als das 
hm4chAssignment[] in 
https://github.com/lumapu/ahoy/blob/main/src/hm/hmDefines.h?

Und da ich diese bislang im Repo nicht gefunden habe, bezweifel ich 
stark, das sich irgendwer die Mühe macht diese extra für mich zusammen 
zu schreiben.

[Martin M. (mcmaier)]

Tim T. schrieb:
> Nach welchem Schema läuft das Channelhopping ab?

Hallo Tim,
ich war ganz am Anfang des Threads an der Protokollanalyse beteiligt, 
unter anderem auch als es um das Channelhopping ging. Dabei wurde mal 
das Gazelle Protokoll von nRF in den Raum geworfen. Das Thema wurde dann 
aber nicht weiter verfolgt, weil man mit dem nRF24L01 das Hopping ja 
irgendwie nachbilden konnte - aber um es nochmal aufzugreifen:

Das Channelhopping dürfte nach dem "Gazelle Link Layer" von nRF 
aufgebaut sein (der nRF24L01 als pures RF Interface unterstützt dies 
nicht!):
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/gazell/gzll.html

Dabei ist der Wechselrichter der Host, der in definierten Timeslots auf 
gewissen Kanälen horcht und dann auf den nächsten wechselt (bei Hoymiles 
waren das 3, 23, 40, 61, 75).
Mit einigen SoCs von nRF kann das GZLL implementiert werden, z.B. mit 
dem nRF51822, der abwärtskompatibel mit dem Funkprotokoll des nRF24L01 
bzw. dem in der Original DTU verwendeten nRF24LE1 ist.

Wenn du also sowieso nochmal vorne anfängst, wäre es vielleicht eine 
Überlegung das mit einem nRF51822 zu versuchen. Da dieser ein SoC 
(Cortex M0) ist, könntest du sogar direkt serielle Daten rausgeben ohne 
Arduino.
Den nRF51822 gibt es ähnlich günstig wie den nRF24L01 - nur leider nicht 
mit PA/LNA, was der Reichweite zugute kommen würde...

[Tim T. (tim_taylor)]

So, habe mich jetzt durch 2/3 der Posts dieses Threads gelesen und muss 
sagen, ich könnte im Strahl kotzen...

Der Thread besteht nur etwa aus 5% Protokollanalyse, 15% Lobhuddelei wie 
toll doch alles ist, 20% Informationen über die verdammte Ahoy DTU, die 
nichts mit dem Protokoll zu tun haben, 20% blödem Geschwätz von Leuten 
die zwar überhaupt keinen Plan haben aber ach so gerne helfen wollen, 
20% Fragen zu anderen WR als der HM Serie und 20% Fragen von Leuten die 
wahlweise das Bin nicht finden, die Leitungen nicht angeklemmt bekommen 
oder irgendwelche anderen Sachfremden Fragen (MQTT, etc.) haben.

Dazu kommt eine erbärmliche und falsche Protokollbeschreibung im Github 
Repo die kaum im Ansatz weiterhilft und ein Code der so weit mit 
Zusatzfeatures vollgepflastert wurde, dass es auch ewig dauert daraus 
das Protokoll zu destillieren.

Glücklicherweise gibt es jedoch 3-4 Lichtgestalten in diesem Thread die 
das ganze Thema überhaupt voran gebracht haben und damit meine ich 
explizit nicht diejenigen die das ganze auf den ESP mit dem ganzen 
Beiwerk geklempnert haben sondern diejenigen die am Protokoll geforscht 
haben.

Aber dank der ganzen Störfeuer wäre wohl auch diese Arbeit irgendwann 
untergegangen wenn nicht einer zufällig den Quelltext der DTU-Pro auf 
gitee gefunden hätte, der traurigerweise zielführender war als das 
meiste was hier geschrieben wurde.

Falls irgendwer von euch nochmal so etwas vorhat, bitte bitte, verkneift 
euch irgendwelche, von absoluten DAUs benutzbaren Lösungen, während es 
noch ein PoC ist, sonst dreht sich hinterher wieder die Mehrheit der 
Posts nicht um das Protokoll und dessen Entschlüsselung sondern um 
DAU-Support und anderen damit zusammenhängenden Problemen.

PS: Ja, schön runtervoten, dann weiß ich auch das es die Richtigen 
gelesen haben.

[Heinz R. (heijz)]

Lieber Tim,

wäre es nicht besser für Dich , für die Menschheit generell wenn Du Dich 
einfach aus solchen Dingen komplett raus hälst?

Entwickle gerne Deine eigene Steuerung - aber Deine Überheblichkeit und 
Besserwisserei - unglaublich

Ja, es gibt sicher sehr viele gute Ingenieure die wesentlich bessere 
Lösungen gefunden haben - ganz ohne Bedürfniss diese in Github usw 
teilen zu müssen, sie einfach für sich einsetzen

Aber Deine Reaktion ist mir zugegeben sehr unverständlich

[Tim T. (tim_taylor)]

Heinz R. schrieb:
> Lieber Tim,
>
> wäre es nicht besser für Dich , für die Menschheit generell wenn Du Dich
> einfach aus solchen Dingen komplett raus hälst?

Nein, ganz im Gegenteil.

> Entwickle gerne Deine eigene Steuerung - aber Deine Überheblichkeit und
> Besserwisserei - unglaublich

Meine Steuerung läuft und die von dir genannte Überheblichkeit und 
Besserwisserei sind nur Fakten.

> Ja, es gibt sicher sehr viele gute Ingenieure die wesentlich bessere
> Lösungen gefunden haben - ganz ohne Bedürfniss diese in Github usw
> teilen zu müssen, sie einfach für sich einsetzen

Jop, aber das ist nicht der Punkt. Es hätte hier im Thread nicht um eine 
Steuerung gehen sollen, sondern um das Protokoll dafür und das wurde 
hier gründlich vergeigt.

> Aber Deine Reaktion ist mir zugegeben sehr unverständlich

Das glaube ich dir sogar. Du verstehst eben nicht den den Vorteil eines 
sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer 
gearteten, Implementierung einer Steuerung dafür.

[John P. (brushlesspower)]

Tim T. schrieb:
> Jop, aber das ist nicht der Punkt. Es hätte hier im Thread nicht um eine
> Steuerung gehen sollen, sondern um das Protokoll dafür und das wurde
> hier gründlich vergeigt.

Tim T. schrieb:
> Meine Steuerung läuft und die von dir genannte Überheblichkeit und
> Besserwisserei sind nur Fakten.

Tim T. schrieb:
> Das glaube ich dir sogar. Du verstehst eben nicht den den Vorteil eines
> sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer
> gearteten, Implementierung einer Steuerung dafür.

Dann bitte, mach es besser.
Sollten wir von dir keine saubere Dokumentation bekommen ist alles von 
dir nur erbärmlich.

[Heinz R. (heijz)]

Tim T. schrieb:
> Du verstehst eben nicht den den Vorteil eines
> sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer
> gearteten, Implementierung einer Steuerung dafür.

Dir ist aber schon klar das hier nicht ein"Protokoll neu entwickelt 
wurde sondern ein von Hoymiles strikt geheim gehaltenes Protokoll 
geknackt wurde?

Klar ist das für DIch jetzt einfach - mit dem Wissen und der Forschung 
anderer das auf Deinen bevorzugten Microcontroller zu adaptieren

Wenn alles so einfach ist - warum fragst dann überhaupt hier?  Hättest 
doch alles für Dich entwickeln können

Mit selbst entwickeln meine ich DU hast den WR , evtl. eine DTU, sonst 
nichts - leg los....

[Tim T. (tim_taylor)]

Heinz R. schrieb:
> Tim T. schrieb:
>> Du verstehst eben nicht den den Vorteil eines
>> sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer
>> gearteten, Implementierung einer Steuerung dafür.
>
> Dir ist aber schon klar das hier nicht ein"Protokoll neu entwickelt
> wurde sondern ein von Hoymiles strikt geheim gehaltenes Protokoll
> geknackt wurde?

Natürlich ist mir das klar und genau das wurde nicht vernünftig 
dokumentiert sondern ist nur irgendwie in die Ahoy DTU gewandert.

> Klar ist das für DIch jetzt einfach - mit dem Wissen und der Forschung
> anderer das auf Deinen bevorzugten Microcontroller zu adaptieren

GENAU DAS IST ES JA, DIE "FORSCHUNG" WURDE ERBÄRMLICH DOKUMENTIERT UND 
IST NUR IRGENDWIE IN DER AHOYDTU VERWURSTET WORDEN.

> Wenn alles so einfach ist - warum fragst dann überhaupt hier?  Hättest
> doch alles für Dich entwickeln können

Ich hatte nach dem Protokoll gefragt und genau das habe ich auch nicht 
bekommen, jedenfalls nicht aus diesem Thread oder der "Doku" im Github 
Repo.
Ich habe es für mich letztlich aus den China Quelltexten auf gitee 
heraus implementiert.

> Mit selbst entwickeln meine ich DU hast den WR , evtl. eine DTU, sonst
> nichts - leg los....

Ja, das wäre letztlich die Variante gewesen die ich gewählt hätte wenn 
es nirgends Informationen gegeben hätte, gibt es aber. Zum Teil in 
homöopathischen Dosen hier im Thread oder geballt im Quelltext auf 
gitee. Aber klar, es ist natürlich super toll, wenn man die Erkenntnisse 
nirgends in brauchbarer Form aufschreibt und direkt tief in irgendeinem 
anderen Quelltext verbuddelt damit der nächste sich am besten gar nicht 
die Mühe macht was eigenes zu entwickeln.

[Daniel (smitna)]

Tim T. schrieb:

Ich zitiere nicht Deine bisherigen Beiträge, diese stehen für sich und 
waren teilweise sogar noch schärfer formuliert, bevor Du sie selbst 
nochmals bearbeitet hast. Inhaltliche Kritik ist ja in Ordnung, aber das 
geht eindeutig zu weit.
Gut gemeinter Rat:
Arbeite bitte intensiv an Deiner Sprache und an Deiner sozialen 
Kompetenz. Es könnte Dir im Alltag nützlich sein.
Daneben stimme ich den Vorpostern zu. Bringe Dein Fachwissen doch hier 
positiv zum Thema ein, Du nimmst dieses ja für Dich in Anspruch.

[Heinz R. (heijz)]

Lieber Tim,

was ist das was Du hier abziehst?

Ein Versuch wie KI funktioniert?

Ein Versuch - wie weit kann ich Forumsteilnehmer treiben?

Hinter Deinem Geschwätz kann auf keinen Fall ein normaler Mensch mit 
gesundem Menschenverstand stehen
Dir geht es nicht um Hoymiles-WR sondern um irgend was ganz Anderes?

[Udo (sulmfish)]

Hallo!

Jemand, der (wie ich) möglichst einfach die Livedaten von einem Hoymiles 
HM... Wechselrichter abrufen will, wird vielleicht hier fündig: 
https://github.com/sulmfish/pico_nrf_hm. Ist Micropython-Code und läuft 
(z. B.) auf einem Raspberry Pi Pico mit NRF24L01+-Modul.

[Fritz G. (fritz65)]

Entschuldigung, dass ich diesen schon recht alten Thread wieder 
ausgrabe, aber ich beschäftige mich gerade mit der Kommunikation eines 
HM- Wechselrichters über das enhanced Shockburst Protokoll. Ziel ist 
eine intelligente Steuerung der Einspeiseleistung, die über die 
klassische Nulleinspeisung hinausgeht. Das Ahoy-Wiki 
https://github.com/lumapu/ahoy/wiki/Protocol habe ich gelesen, werde 
aber nicht richtig schlau daraus. Es würde mir sehr viel weiterhelfen, 
wenn mir jemand hier folgende 3 Fragen beantworten könnte:

1. Nutzt das Protokoll die Auto-Ack-Funktion mit automatischer 
Sendewiederholung?
2. Manche Pakete sind mit 0x7E und 0x7F eingerahmt, andere nicht. 
Welches Format ist richtig?
3. Offenbar wird ein Channel-Hopping über 5 Kanäle genutzt. Laut Wiki 
ist der Sendekanal des nrf24l01+ auf 40 = 2040 MHz festgelegt und es 
wird nur der Empfangskanal gewechselt. Ist das so OK? Wann wird der 
Kanal gewechselt? Nur, wenn keine Antwort kommt oder regelmäßig nach 
jeder Abfrage?

Vielen Dank!

[Udo (sulmfish)]

Hallo Fritz!

Es ist schon fast ein Jahr her, dass ich mich mit den Einzelheiten 
befasst habe, deshalb alles ohne Gewähr:

zu 1. Ich glaube ja (ob das auch bei meinem Micropython-Code 
funktioniert, weiß ich nicht).

zu 2. Ich glaube 0x7e (start of frame, sof) und 0x7f (end of frame, eof) 
ist in den Daten, die man schickt bzw. erhält nicht enthalten; die sieht 
man nur, wenn man den Funkverkehr abhört (mit Sniffer?).

zu 3. Ein Zitat aus dem wiki: "zu den genutzten Frequenzen. Bei meinem 
HM-600 ist es immer so: Wenn ich ein 80 Telegramm sende
auf 2403, dann antwortet der WR mit den Antworten 01,02,83 auf den 
möglichen Frequenzen
2423,2440,2461 MHz. also bei TX 2403, Antworten auf 2423,2440,2461 bei 
TX 2423, Antworten auf
2403,2440,2475 bei TX 2440, Antworten auf 2403,2423,2475 bei TX 2461, 
Antworten auf
2403,2423,2475 bei TX 2475, Antworten auf 2403,2423,2440 Wenn man die 
möglichen Frequenzen
scannt nach dem Senden, dann empfängt man alle Antworten. Andere 
Antworten als 01,02,83 habe ich
bisher nie empfangen."

Heißt also: Man kann auf allen 5 Kanälen senden, die Antwort kommt dann 
auf einem von drei anderen Kanälen. Auf welchem ist meines Wissens 
zufällig. Also z.B. Senden auf Kanal 3 ergibt eine Antwort auf Kanal 23 
oder 40 oder 61.

Viel Erfolg!

[Martin M. (mcmaier)]

Fritz G. schrieb:
> 3. Offenbar wird ein Channel-Hopping über 5 Kanäle genutzt. Laut Wiki
> ist der Sendekanal des nrf24l01+ auf 40 = 2040 MHz festgelegt und es
> wird nur der Empfangskanal gewechselt. Ist das so OK? Wann wird der
> Kanal gewechselt? Nur, wenn keine Antwort kommt oder regelmäßig nach
> jeder Abfrage?

Hallo Fritz,
ich hatte weiter oben schon mal spekuliert, dass das Channel Hopping dem 
Gazelle Link Layer von nRF entspricht und mit dem nRF24L01 nur 
pseudomäßig nachgebildet werden kann. Siehe hier:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Vielleicht hilft dir das weiter?

[Bri (bri)]

Ich habe für ein privates Projekt die Daten von meinem Wechselrichter 
mit einem Raspberry PI ausgelesen. Falls jemand das gleiche Anliegen 
hat, hier ist der Sourcecode:

https://github.com/bri1234/Hoymiles-HM-RaspberryPI

Es ist in Python (mit typehints) programmiert mit Schwerpunkt auf 
einfacher Verwendung, guter Lesbarkeit und guter Dokumentation des 
Sourcecodes.

[Max (minimum)]

So, schon 2,5 Jahre später habe ich ein Licht am Ende des Tunnels.
Ich kann nun mit einem Arduino und dem NRF zusammen Hoymiles Powerlimits 
setzen.
Ack klappt nicht, ich hoffe in weniger als 2,5 Jahren kann ich das auch 
noch posten :)

#include <RF24.h>
#include <SPI.h>

#define CE_PIN    9
#define CSN_PIN   10

RF24 radio(CE_PIN, CSN_PIN);

uint8_t invAddr[] = {0x71, 0x60, 0x33, 0x25}; 
uint8_t dtuAddr[] = {0x87, 0x29, 0x87, 0x48};
uint8_t channels[] = {3, 23, 40, 61, 75};

void setup() {
    Serial.begin(9600);
    if (!radio.begin()) { Serial.println(F("NRF24 Fail")); while (1); }

    radio.setDataRate(RF24_250KBPS);
    radio.setPALevel(RF24_PA_MAX);
    radio.setAddressWidth(5);
    radio.enableDynamicPayloads();
    radio.setCRCLength(RF24_CRC_16);
    radio.setAutoAck(false);

    // Adresse LSB zuerst + 0x01 Prefix
    uint8_t rxAddr[5] = {0x01, invAddr[3], invAddr[2], invAddr[1], invAddr[0]};
    radio.openReadingPipe(1, rxAddr);
    
    Serial.println(F("Bereit. Watt eingeben:"));
}

// CRC16 für den Payload-Teil (Modbus RTU Style)
uint16_t hoymiles_crc16(uint8_t *data, uint8_t len) {
    uint16_t crc = 0xFFFF;
    for (uint8_t i = 0; i < len; i++) {
        crc ^= (uint16_t)data[i];
        for (uint8_t j = 0; j < 8; j++) {
            if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; }
            else crc >>= 1;
        }
    }
    return crc;
}

// CRC8 für das gesamte Paket
uint8_t hoymiles_crc8(uint8_t *data, uint8_t len) {
    uint8_t crc = 0;
    for (uint8_t i = 0; i < len; i++) {
        crc ^= data[i];
        for (uint8_t j = 8; j; j--) {
            crc = (crc & 0x80) ? (crc << 1) ^ 0x01 : (crc << 1);
        }
    }
    return crc;
}

void sendLimit(uint16_t watts) {
    uint8_t buf[19];
    buf[0] = 0x51; // Control Frame
    memcpy(&buf[1], invAddr, 4);
    memcpy(&buf[5], dtuAddr, 4);
    buf[9] = 0x81; // Sequence (fest für diesen Test)
    buf[10] = 0x0B; // CMD: Set Limit
    buf[11] = 0x00;
    
    uint16_t val = watts * 10; // Inverter erwartet Zehntel-Watt oder Promille
    buf[12] = (val >> 8) & 0xFF;
    buf[13] = (val & 0xFF);
    
    buf[14] = 0x00; // Relative / Permanent
    buf[15] = 0x00;
    
    // 1. Payload CRC16 (über Byte 10 bis 15)
    uint16_t c16 = hoymiles_crc16(&buf[10], 6);
    buf[16] = (c16 >> 8) & 0xFF;
    buf[17] = (c16 & 0xFF);
    
    // 2. Global CRC8 (über Byte 0 bis 17)
    buf[18] = hoymiles_crc8(buf, 18);

    // Sende-Loop
    for (uint8_t i = 0; i < 5; i++) {
        radio.stopListening();
        radio.setChannel(channels[i]);
        radio.write(buf, 19);
        radio.startListening();
        
        Serial.print(F("Sende ")); Serial.print(watts);
        Serial.print(F("W auf CH ")); Serial.println(channels[i]);
        
        unsigned long start = millis();
        while (millis() - start < 200) {
            if (radio.available()) {
                uint8_t len = radio.getDynamicPayloadSize();
                uint8_t packet[32];
                radio.read(packet, len);
                if (packet[0] == 0xD1) {
                    Serial.println(F("--> ACK EMPFANGEN!"));
                    return;
                }
            }
        }
    }
    Serial.println(F("Kein ACK."));
}

void loop() {
    if (Serial.available()) {
        int w = Serial.parseInt();
        if (w > 0) sendLimit(w);
    }
}