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
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)
```
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 =^}
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 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 :)
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 :)
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?
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
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
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.
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!
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?
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.
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.
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.
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 ...
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
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 ?
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 ?
@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.
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
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...
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.
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"
DPRINTLN(DBG_WARN,F("time not set, can't request inverter!"));
3
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
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?
@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...???
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 ;-)
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. 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
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
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?
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
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
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...
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
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
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)
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 :)
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
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.
:-)
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
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.
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
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.
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
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
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.
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:>
1
>if(0!=len){
2
>Inverter<>*iv=mSys->findInverter(&p->packet[1]);
3
>if(NULL!=iv){
4
// paket ID in byte 10, d.h. packet[9]
5
>uint8_t*pid=&p->packet[9];
6
// die paket ID muß < 5 sein, wenn man 0x80 abzieht bzw. sich alle unteren Bits ansieht.
7
>if((*pid&0x7F)<5){
8
// 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)
9
>memcpy(mPayload[iv->id].data[(*pid&0x7F)-
10
>1],&p->packet[10],len-11);
11
// Berechne die Länge der Payload des Paketes, analog zur Länge davor
12
>mPayload[iv->id].len[(*pid&0x7F)-1]=
13
>len-11;
14
>}
15
>
16
// Wenn die Paket ID das höchstwertige Bit 0x80 gesetzt hat bzw. > 0x80 ist == Letztes Paket oder Antwort auf ein Retransmit
17
>if((*pid&0x80)==0x80){
18
// wenn die Paket ID > die maxPackId ist.
19
>if((*pid&0x7f)>
20
>mPayload[iv->id].maxPackId){
21
// setze die maxPackId gleich der aktuellen Paket ID
22
>mPayload[iv->id].maxPackId=(*pid&
23
>0x7f);
24
// falls die Paket ID > 0x81 ist, also 0x82 ... 0x85
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:
> &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)
> 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.
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)
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.
1
88635003166350031600030000000000008B
2
896350031663500316012F0005095D1386009707CC01605E
Die 0x88 ist der Status, hier die 03 ist der Modulstatus (verbunden und
aktiv)
Die 0x89 sind die Werte:
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:
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:
1
if(0!=len){
2
Inverter<>*iv=mSys->findInverter(&p->packet[1]);
3
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.
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 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.
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
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
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 ?
@ 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.
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.
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.
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?>
>> 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.
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
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
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
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?
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
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
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.
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.
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 =^!
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:
1
CMD (data )<value>
2
Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e
3
Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e
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.
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
@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.
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.
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?
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ß
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
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 ?
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
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 ?
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...
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?
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
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. ^^
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.
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....
Ä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]
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.
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
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:
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:
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:
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
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
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 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 :)
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.
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:
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 ?
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.
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! :)
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)
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
@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..
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?)
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.
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?
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.
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.
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
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
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
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.
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ß
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
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. ;)
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.
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.
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 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 :)
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 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.
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
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
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.
@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.
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 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.
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 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 :)
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.
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.
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...
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 !
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.
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 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?
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ß
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
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.
@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.
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 :)
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
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.
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
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
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.
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 ^^
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.
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.
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:
1
HM_Abstract.cpp:
2
3
payload->mainCmd=0x09;
4
payload->subCmd=0x00;
5
payload->timeout=2000;
6
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:
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:
Leider komme ich mit dem Empfang der Payload nicht weiter.
Log:
1
Fetchinverter:17872974971670
2
TX9605331678563412027
3
RXPeriodEnd
4
Allmissing
5
Nothingreceived,resendwholerequest
6
TX9605331678563412027
7
RXPeriodEnd
8
Allmissing
9
Nothingreceived,resendwholerequest
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.
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:
1
constuint8_tMI_2CH::getPayload()
2
{
3
mainCmd=0x09;//Ch0 request
4
mainCmd=0x11;//Ch1 request
5
PayloadID=0x88;//Event Ch0
6
PayloadID=0x89;//PV-DATA Ch0
7
PayloadID=0x91;//PV-DATA Ch1
8
PayloadID=0x92;//Event Ch1
9
}
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.
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.
>
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:>
1
>Fetchinverter:17872974971670
2
>TX9605331678563412027
3
>RXPeriodEnd
4
>Allmissing
5
>Nothingreceived,resendwholerequest
6
>TX9605331678563412027
7
>RXPeriodEnd
8
>Allmissing
9
>Nothingreceived,resendwholerequest
10
>
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.
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 :)
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?
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.
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;-).
@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.
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 ?
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.
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
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
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?
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?
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ß