Forum: Mikrocontroller und Digitale Elektronik Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Günter H. (gnter_h534)


Angehängte Dateien:

Lesenswert?

Sylvester D. schrieb:
> Nun, der NRF und der ESP32 könnten wirklich weiter auseinander sein.
> Sieht wirklich so aus als wäre die Funkverbindung bzw. insbesondere der
> Empfang nicht sonderlich stabil, oder anderweitig gestört.

> Morgen probiere ich mal einen größeren Abstand zwischen den beiden
> Modulen (ESP und NRF). Kann gut sein dass das das Problem ist.
> Wenn ich rausfinde was es war lasse ich es Euch natürlich wissen.

Das Thema Abstand ESP-Board <---> nRF24L01+-Modul sollte aus meiner 
Sicht nicht überbewertet werden:

- In der Original-DTU ist der Abstand auch nicht riesig groß,
- ein realisiertes Muster von mir läuft stabil (grindylow /
ahoy, Firmware 0.4.25) und, solange der Wechselrichter aktiv ist, 
praktisch ohne "Receive fail". Auch ein nFR24L01+-Modul mit 
Print-Antenne ist problemlos einsetzbar. Die Bausteine sind gesteckt, um 
bei Bedarf verschiedene Ausführungen testen zu können, somit ist auch 
der USB-Anschluss prinzipiell zugänglich.

Leider ist die "Streubreite" der Qualität der nRF24L01+-Klone wohl sehr 
groß - siehe z. B. hier:
Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"

Bei einem früheren Aufbau war ein Stecker des Dupont-Kabels 
"ausgeleiert" und verursachte so eine Instabilität.

von Gerald R. (visitor)


Lesenswert?

isnoAhoy schrieb:
> # FAQ Häufig gestellte Fragen
> https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

Sehr schön, Danke an alle!

Sollte jemand einen Tester für die Leistungsbegrenzung brauchen, ich und 
mein HM800 sind bereit. :-D

von Ralla66 (Gast)


Lesenswert?

Wäre es möglich im FAQ mal mit aufzunehmen wie man ein Kommando an den 
WR sendet. Habe hier die Kombi Arduino / Esp 8266 mit NRF Plus, WR 
HM600.
Wie wird die Anfrage gesendet ? Beispiel Hterm sendet per Serial TX an 
Arduino der nach NRF ? Ist das richtig so.
Kleines Beispiel wäre nett wie man sendet.

Würde gerne mittesten da ich eine Leistungsreduzierung von Vorteil sehe
und von der Leistungsreduzierung AE Conversion nach Hoymiles wechseln 
möchte.
Wünschenswert wäre halt wie beim AE ein Request aus IoBroker an den HM 
senden zu können damit die Energie aus der Batterie gezielt abgegeben 
werden kann.

von Canon.Fritz (Gast)


Lesenswert?

Hallo,
erst einmal ein großes Dankeschön für dieses tolle Projekt.
Ihr habt da etwas großartiges auf die Beine gestellt :)

Gerald R. schrieb:
> Sollte jemand einen Tester für die Leistungsbegrenzung brauchen, ich und
> mein HM800 sind bereit. :-D

Ich wäre mit meinem HM600 auch am Start um die Leistungsbegrenzung zu 
testen :)

von DerJens (Gast)


Lesenswert?

Hubi schrieb:
> Die SW HoyDtuSim aus meiner Repo
> [[https://github.com/hm-soft/Hoymiles-DTU-Simulation/ ]] sollte es jetzt
> auch mit mehreren WR können. Kann das aber leider nicht testen.

Soeben ausprobiert:
Mit einem WR klappts, da bekomme ich nach jedem Send... eine Antwort.
1
18:32:03.082 -> Send... CH3
2
18:32:03.129 -> Request cmd=1
3
18:32:03.129 -> Send... CH23
4
18:32:04.160 -> rcv CH:40 00 1234567801 ...
5
18:32:04.160 -> rcv CH:61 00 1234567801 ...
6
18:32:06.930 -> Send... CH40
7
18:32:07.024 -> rcv CH:75 00 1234567801 ...
8
18:32:07.024 -> rcv CH:61 00 1234567801 ...
9
18:32:16.923 -> Send... CH61
10
18:32:17.016 -> rcv CH:23 00 1234567801 ...
11
18:32:17.016 -> rcv CH:3 00 1234567801 ...
12
18:32:26.958 -> Send... CH75

Mit 3 WR kommt sehr lange erstmal nicht.
1
18:36:50.507 -> Send... CH3
2
18:36:50.553 -> Send... CH23
3
18:36:50.599 -> Send... CH40
4
18:36:53.407 -> Send... CH61
5
18:36:56.406 -> Send... CH75
6
18:36:59.396 -> Send... CH3
7
18:37:02.392 -> Send... CH23
8
18:37:05.395 -> Send... CH40
9
18:37:08.413 -> Send... CH61
10
18:37:11.415 -> Send... CH75
11
18:37:14.400 -> Send... CH3
12
18:37:17.377 -> Send... CH23
13
18:37:20.386 -> Send... CH40
14
18:37:23.397 -> Send... CH61
15
18:37:26.398 -> Send... CH75
16
18:37:29.413 -> Send... CH3
17
18:37:32.399 -> Send... CH23
18
18:37:35.385 -> Send... CH40
19
18:37:38.412 -> Send... CH61
20
18:37:41.412 -> Send... CH75
21
18:37:44.387 -> Send... CH3
22
18:37:47.416 -> Send... CH23
23
18:37:50.412 -> Send... CH40
24
18:37:53.381 -> Send... CH61
25
18:37:56.423 -> Send... CH75
26
18:37:59.415 -> Send... CH3
27
18:38:02.385 -> Send... CH23
28
18:38:05.393 -> Send... CH40

Irgendwann kommen dann selten Antworten von allen 3 WR, dazwischen 
liegen aber zum Teil mehrere Minuten.

von locke987 (Gast)


Lesenswert?

Canon.Fritz schrieb:
> Ich wäre mit meinem HM600 auch am Start um die Leistungsbegrenzung zu
> testen :)

Wäre mit einem HM-1500 und iobroker/mqtt auch beim Testen dabei...

von locke987 (Gast)


Lesenswert?

Günter H. schrieb:
> ein realisiertes Muster von mir läuft stabil

Kann man das Carrier Board käuflich erwerben, und wenn ja wo? Schaut gut 
aus!
Gruß Stefan

von IsnoAhoy (Gast)


Lesenswert?


von Tobias G. (tobias_g841)


Lesenswert?

Für das Logbuch: Leerzeichen in der WR Bezeichnung innerhalb AHOY wird 
dadurch bestraft, dass zB keine Entitäten (über MQTT) autom. in Home 
Assistant erkannt werden.
Leerzeichen entfernt, schwupps, alles da.

: Bearbeitet durch User
von MaLa (Gast)


Lesenswert?

Noch ein Beitrag für das Logbuch:
Die Verbindung zum NTP Zeitgeber muss möglich sein. In den fertigen 
Binaries ist "pool.ntp.org" eingetragen.
Im Code lässt sich das natürlich anpassen (z.B. auf einen lokalen 
Zeitgeber im Heimnetz), womit aber selbst compiliert werden muss.


Da ich in meiner FritzBox den Geräten der Hausautomatisierung keinen 
Zugriff auf das Internet erlaube, bin ich da leider ein paar Stunden 
hängegeblieben - nun läuft aber alles.

Super Forum, vielen Dank an alle kreativen Köpfe!!!!!

von dtuuser (Gast)


Lesenswert?

Mein Cloud MQTT (HiveMQ) Broker verwendet TLS-Verschlüsselung auf Port 
8883, kann AhoyDTU dies unterstützen?

von Steffen D. (steffen_d)



Lesenswert?

Hallo, die Ahoy Esp8266 Version 0.4.25 verbindet sich ja gut mit meinem 
HassIO MQTT Broker. HassIO zeigt mit auch alle Entitäten. OpenDTU mit 
einem ESp32 läuft Rauch top und verbindet sich auch mit dem MQTT Broker 
aber HassIO zeigt mir keine Entitäten oder das Gerät an. Wo liegt da der 
Hund begraben?

: Bearbeitet durch User
von Sylvester D. (sylvester_d)


Lesenswert?

Problem gefunden

Wie bereits zuletzt berichtet lief die HW & SW bei mir zumindest einmal 
kurzzeitig am Abend. Jetzt ist mir auch klar wo das Problem lag, nachdem 
gestern Morgen das System, ohne irgendeiner weiteren Änderung und für 
mich völlig überraschend, problemlos und dann den ganzen Tag anstandslos 
lief.

Die Ursache? Die Uhrzeit zu denen ich Zeit hatte zu testen......nämlich 
entweder sehr sehr spät Abends oder früh am Morgen. Tagsüber habe ich es 
nicht laufen lassen und auch nicht mitgeloggt.
Es schien einfach zu wenig Licht auf das eine am HM-600 angeschlossenen 
Panel. Das Panel steht testweise noch am Boden an eine Südwand gelehnt. 
Sobald einige Watt Leistung auf dem Panel zusammen kommen läuft die 
Kommunikation einwandfrei. Bei 5W ganz sicher, teilweise sogar noch im 
Bereich von ~1W.

Ich hatte zwar gelesen dass die Kommunikation nur geht wenn Strom vom 
Panel erzeugt wird, deshalb ja auch die Tests am Morgen, aber das war 
einfach noch zu wenig Licht obwohl man als Mensch schon den Eindruck von 
hell, Morgendämmerung hat und farbig sieht.

Als es am Abend kurzzeitig lief, hatte ich ausnahmsweise einmal deutlich 
früher am Abend getestet.....und gestern Morgen später als sonst......

Gestern Abend war dann die letzte Meldung mit 0,7W und heute Morgen lief 
es dann wiederum problemlos.

Obwohl der HM-600 am 230V Netz angeschlossen ist, scheint er, ohne 
ausreichende Energieversorgung durch zumindest ein Panel, nicht auf den 
DTU zu antworten, was ja schon mal hier im Thread angesprochen wurde. 
Allerdings braucht es unter Umständen einfach mehr als Dämmerlicht. Ich 
hoffe diese Erfahrung hilft anderen, nicht den gleichen Fehler zu 
wiederholen.

Sylvester

von Canon.Fritz (Gast)


Lesenswert?

Tobias G. schrieb:
> Leerzeichen in der WR Bezeichnung innerhalb AHOY wird
> dadurch bestraft, dass zB keine Entitäten (über MQTT) autom. in Home
> Assistant erkannt werden.
> Leerzeichen entfernt, schwupps, alles da.

Ich versuche das ganze in FHEM zu integrieren. Mit meinem Mosquitto MQTT 
Server hat er sich auch laut AHOY Software verbunden.

Wie muss ich das Topic denn jetzt zusammen bauen ?
Leider werde ich auch aus dieser Anleitung nicht ganz schlau :
Power Limit via mqtt https://github.com/grindylow/ahoy/pull/109

Es wäre toll wenn mir jemand anschaulich erklärt wie ich das Topic 
zusammenbauen muss :) z.b. so Device Name/Inverter_0_Name/Topic

von Daniel M. (daniel_m821)


Lesenswert?

Canon.Fritz schrieb:

> Es wäre toll wenn mir jemand anschaulich erklärt wie ich das Topic
> zusammenbauen muss :) z.b. so Device Name/Inverter_0_Name/Topic

In den Einstellungen hast du ein Base Topic. In OpenDTU schaut es 
folgenermaßen aus:
BaseTopic/INV_Serial/Channel/Abzufragender_Wert

Beispiel: solar/116181101507/0/power
Channel 0 ist AC, Channel 1 und folgende (max. 4) sind die DC-Eingänge.

Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was 
alles kommt und wie es bei dir genau aussieht.

Für die DTU sieht es so aus:
solar/dtu/name
solar/dtu/uptime
solar/dtu/ip

von Claus T. (Gast)


Lesenswert?

Canon.Fritz schrieb:
>
> Ich versuche das ganze in FHEM zu integrieren. Mit meinem Mosquitto MQTT
> Server hat er sich auch laut AHOY Software verbunden.
>
Ich habe das MTTQ2 Modul von FHEM definiert, also keinen extra mosquito 
installiert und der MTTQ2 hat bei mir dann automatisch ein MTTQ-Device 
mit allen readings angelegt.

von Ralla66 (Gast)


Lesenswert?

Test über Nacht,
Kombi WemosD1 mit Ahoi 0.4.25
Morgens Spannung der Module da
Spannung sichtbar mit Sonoff Dual R3
Keine Daten empfangen, gesendet werden 6 gleiche Pakete Transmit 27 | 15
Last Frame missing
usw mit anderem Zeitstempel
Reboot keine Besserung
Wemos Stromlos
Keine Daten empfangen, gesendet werden 1 mal 6 gleiche Pakete Transmit 
27 | 15
Last Frame missing
Keine Daten empfangen, gesendet wird 1 Pakete Transmit 27 | 15 danach 
95er
Pakete unterschiedlicher Anzahl,
Last Frame missing
Pakete 27 | 15 mit 95er werden 5 mal angezeigt
Danach Daten Receive mit Transmit 11 | 15
Transmit 11 | 15
81 86 77 21 78 56 34 12 82 CE 95
81 86 77 21 81 86 77 21 02 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 
BE AF 95
81 86 77 21 81 86 77 21 02 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 
BE AF
I: Payload (42): 00 01 01 03 00 4D 00 C7 00 08 00 02 00 00 00 00 2B 16 
00 00 00 00 00 3F 00 00 09 1A 13 84 00 BE 00 00 00 08 03 E8 01 0C 04 30

Soweit der Übernachttest

von Hubi (Gast)


Lesenswert?

DerJens schrieb:
> Soeben ausprobiert:
> Mit einem WR klappts, da bekomme ich nach jedem Send... eine
> Antwort.18:32:03.082 -> Send... CH3
> 18:32:03.129 -> Request cmd=1
> 18:32:03.129 -> Send... CH23
> 18:32:04.160 -> rcv CH:40 00 1234567801 ...
> 18:32:04.160 -> rcv CH:61 00 1234567801 ...
> 18:32:06.930 -> Send... CH40
> 18:32:07.024 -> rcv CH:75 00 1234567801 ...
> 18:32:07.024 -> rcv CH:61 00 1234567801 ...
> 18:32:16.923 -> Send... CH61
> 18:32:17.016 -> rcv CH:23 00 1234567801 ...
> 18:32:17.016 -> rcv CH:3 00 1234567801 ...
> 18:32:26.958 -> Send... CH75
>
> Mit 3 WR kommt sehr lange erstmal nicht.18:36:50.507 -> Send... CH3
> 18:36:50.553 -> Send... CH23
> 18:36:50.599 -> Send... CH40

Probier mal in der Settings.h andere Einstellungen, zB
#define PA_LEVEL    RF24_PA_MAX oder RF24_PA_HIGH.
Außerdem wird die Wartezeit (WAIT_TILL_NEXT_SEND) bis zum nächsten 
Senden auf dir WRs aufgeteilt, also bei 3 WR wird lediglich 3 Sekunden 
gewartet.
setze mal fest WAIT_TILL_NEXT_SEND=10 am Ende von setupInverters()

von oxylog (Gast)


Angehängte Dateien:

Lesenswert?

Günter H. schrieb:
> Das Thema Abstand ESP-Board <---> nRF24L01+-Modul sollte aus meiner
> Sicht nicht überbewertet werden:

Selbiges hier
- Läuft auf beiden Platinen fehlerfrei, auch unter 04.22
- Ebenfalls steckbar. Auch hatte ich einen Wemos D1mini-Clone, der 
fehlerhaft war.

von Joni N. (hal_9000)


Lesenswert?

Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen. 
3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann 
einfach email mit Postanschrift an derbuchner@gmail.com

Es ist dieses Fritzing File hier: 
https://github.com/tbnobody/OpenDTU/tree/master/docs

P.S:
Ich seh das ganze als "Pay It Forward" Aktion :-)

von Joni N. (hal_9000)


Lesenswert?

Joni N. schrieb:
> Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen.
> 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann
> einfach email mit Postanschrift an derbuchner@gmail.com
>
> Es ist dieses Fritzing File hier:
> https://github.com/tbnobody/OpenDTU/tree/master/docs
>
> P.S:
> Ich seh das ganze als "Pay It Forward" Aktion :-)

Ging schnell ... sind jetzt alle weg :-D

von Steffen D. (steffen_d)


Lesenswert?

Joni N. schrieb:
> Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen.
> 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann
> einfach email mit Postanschrift an derbuchner@gmail.com
>
> Es ist dieses Fritzing File hier:
> https://github.com/tbnobody/OpenDTU/tree/master/docs
>
> P.S:
> Ich seh das ganze als "Pay It Forward" Aktion :-)

Wo hast Du die machen lassen? Würde die mit deiner Erlaubnis (Datei) 
fertigen lassen.

von DerJens (Gast)


Lesenswert?

Hubi schrieb:
> Probier mal in der Settings.h andere Einstellungen, zB
> #define PA_LEVEL    RF24_PA_MAX oder RF24_PA_HIGH.
> Außerdem wird die Wartezeit (WAIT_TILL_NEXT_SEND) bis zum nächsten
> Senden auf dir WRs aufgeteilt, also bei 3 WR wird lediglich 3 Sekunden
> gewartet.
> setze mal fest WAIT_TILL_NEXT_SEND=10 am Ende von setupInverters()

Soeben ausprobiert:
- bei PA_LEVEL auf HIGH ändert sich nichts
- bei WAIT_TILL_NEXT_SEND=10 dauert es länger bis ein Send... kommt, es 
kommt aber trotzdem nicht schneller eine Antwort. Zum Teil nur von einem 
WR, von den anderen kommen gar keine Antworten.

Ich habe mal jeden WR einzeln mit MAX_ANZ_INV 1 angesprochen, da kommt 
bei jedem innerhalb der ersten 1-2 Send... eine Antwort. Ich habe den 
Eindruck, dass mit mehreren WR die Antworten irgendwie nicht mehr 
erwischt werden...?

von Joni N. (hal_9000)


Lesenswert?

Steffen D. schrieb:

> Wo hast Du die machen lassen? Würde die mit deiner Erlaubnis (Datei)
> fertigen lassen.

Die Datei ist ja nicht von mir, sondern von tbnobody ;-)
https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz

Fertigen habe ich sie bei JLCPCB lassen. Ging super einfach.

Hier die Anleitung wie du aus dem .fzz ein Gerber File machst:
https://support.jlcpcb.com/article/171-how-to-generate-gerber-and-drill-files-in-fritzing

von Holger F. (holger_f)


Lesenswert?

Hallo, bin schwer beeindruckt, was ihr hier geschafft habt!

Kennt jemand folgendes Verhalten?

Es sieht aus, als würde mein HM-600 erst genau 1800 Sekunden (30 
Minuten) nach seinem Start antworten, also nachdem DC Spannung vom 
Labornetzteil am Wechselrichter-Eingang vorhanden ist.
Die ersten 30 Minuten schweigt er einfach ("All missing" im Log), danach 
antwortet er ziemlich zuverlässig ("Interrupt received" im Log).

All meine vorangegangenen Fehlversuche mit Kondensatoren, anderen 
Antennen, Abstand, anderen NRF-Modulen, ESP-Neustarts usw. hatten gar 
keinen Einfluss. Es waren schlicht die 30 Minuten Wartezeit. Das könnte 
auch die Probleme manch anderer Forenteilnehmer beim RX erklären.

Versuchsaufbau: OpenDTU auf ESP32 mit NRF24L01+, HM-600 mit 
Labornetzteil am DC-Eingang

(War da nicht auch was mit Epoch-Zeitstempeln in den Nachrichten? Nur 
mal gesponnen, vielleicht ja irgendein Schutz vor Replay-Attacken 
basierend auf Zeitstempeln?)

von Steffen D. (steffen_d)


Lesenswert?

Joni N. schrieb:

> https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz
> Fertigen habe ich sie bei JLCPCB lassen. Ging super einfach.
> Hier die Anleitung wie du aus dem .fzz ein Gerber File machst:
> 
https://support.jlcpcb.com/article/171-how-to-generate-gerber-and-drill-files-in-fritzing

Okay wie ich sehe ist es nur die Platine mit Lötaugen für den ESP32 und 
den NRF+ ohne Leiterbahnen!?

Du kannst mir gerne auch das Gerber File zukommen lassen. Ich muss mich 
erstmal mit Fritzing und autoroute beschäftigen.

: Bearbeitet durch User
von Horst G. (horstg-57)


Lesenswert?

Habe hier inzwischen einen WimosD1 mit Ahoi 0.4.25 in Dauerbetrieb 
laufen.
Großartige Leistung von allen die die Software bis hier vorangetrieben 
haben.

Bei mir bringt der Ahoi sehr zuverlässig seine Daten und überträgt die 
auch zuverlässig zu einem Mosquito MQTT Server, auch über den 
Tageswechsel.

Es sollte aber sichergestellt sein, das der Abstand zwischen HM ( hier 
ein HM400) und dem Aufbau nicht zu groß ist und ein mehr oder weniger 
freies Funkfeld besteht. Bei 2,4 GHz wirken sich gemauerte Wände doch 
schon erheblich    aus.

Was mir allerdings aufgefallen ist, wenn man zwei Ahoi's betreibt
( einen Produktiv und einen zur Fehlersuche des MQTT reconnect Problems 
; auch mit unterschiedlichen Device-Namen im Setup )
stören sich diese beim versenden der MQTT Daten.
Ursache ist, das beim MQTT anmelden nicht der Device-Name wie im Setup 
eingetragen genommen wird, sondern der im Source-Code voreingestellte.
Nachdem ich hier eine Erweiterung in der App.cpp und MQTT.h eingebaut 
habe, so das auch hier der Devicename aus dem Setup genommen wird, 
stören sich die beiden Ahoi's nicht mehr.

Ausserdem habe ich eine kleine Anpassung eingebaut, so das nach jeder 
erfolgreicher Datenaufbereitung, mit einer Verzögerung von 2 Sekunden, 
die neuen Daten per MQTT übertragen bekomme, indem ich den MQTT 
Intervall Zähler auf "MQTT-Intervallzeit - 2" setze.

von Hubi (Gast)


Lesenswert?

DerJens schrieb:
> Ich habe mal jeden WR einzeln mit MAX_ANZ_INV 1 angesprochen, da kommt
> bei jedem innerhalb der ersten 1-2 Send... eine Antwort. Ich habe den
> Eindruck, dass mit mehreren WR die Antworten irgendwie nicht mehr
> erwischt werden...?

Ich konnte testweise einen 2. WR simulieren, indem ich meinen einzigen 
WR 2x lade, mit je richtigen und falschen SerialNo beim Senden und 
Empfang warten.
Und es funzt jetzt. Update ist im Repo.
@DerJens: Wenn's bei dir immer noch Probleme gibt, schreib per Mail an 
hubi.mora(at)gmail.com

von Klaus H. (klahi)


Lesenswert?

Hallo, ich bin auf der Auswahl eines Mikrowechselrichters auf dieses 
Forum gestoßen. Ich möchte bei dem zukünftigen Modell keinem Cloud-Zwang 
unterworfen sein und die Ausgangsleistung des Wechselrichters begrenzen 
können. Das aber nur zur Einordnung.

Zu Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" : Aus Interesse 
habe ich mir das gitee-Repository zur DTU-PRO geladen. Ein Repository 
vergisst nichts :-)  Vor dem Commit mit dem Text "Document" mit der 
Commit-Kennung 2d24e2b7a261282501b44da26a5693d5033e8ba6 finden sich 
viele gelöschte Dokumente, unter anderem auch RF通讯协议-V6.6.xlsx 
(übersetzt RFprotocol-V6.6.xslx). Vielleicht finden sich dort aktuellere 
Informationen als in V6.5.
Ansonsten finden sich in den älteren Commits sehr viele gelöschte 
Verzeichnisse und Dateien. Ich forsche mal noch weiter ...
Dieses Forum und die Teilnehmer machen Lust darauf sich zu beteiligen. 
Danke für die bisher geleistete Arbeit.

von Klaus H. (klahi)


Lesenswert?

Ergänzend: Es gibt zwei Repositories bei gitee zum gleichen Thema:
https://gitee.com/iotloves/hoymiles-DTU-PRO
https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO

Das Erstere ist jünger. Ich habe mich daraus bedient.

von guilligan71 (Gast)


Lesenswert?

Hi, ich reihe mich ein in die vielen Danksagungen.
Ich habe mit die fertige 0.4.25 hier aus board runtergeladen. auf github 
(unter actions) finde ich Sie jedoch nicht.
Gibt es eine Möglichkeit das Abfrageintervall MQTT von 90s zu 
reduzieren, damit die Daten ein bissl aktueller sind?

VG

von Canon.Fritz (Gast)


Lesenswert?

Daniel M. schrieb:
> Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was
> alles kommt und wie es bei dir genau aussieht.


Ich konnte die Topics mittels MQTT Explorer raussuchen.
Besten dank für den Tipp :)

Nun funktionierte auch bei mir die Integration in Fhem.

Jetzt stellt sich mir nur noch die Frage wie ich den Topic für die 
Leistungslimitierung formen muss.

Ich verwende die Ahoy 0.4.25.bin hier aus dem Forum, da mir VS Code 
immer 70 Fehler beim kompilieren rauswirft und ich mir daher keine 
eigene .bin exportieren kann ;(  Ich hoffe es geht auch schon in dieser 
Version.

von guilligan71 (Gast)


Lesenswert?

guilligan71 schrieb:
> Hi, ich reihe mich ein in die vielen Danksagungen.
> Ich habe mit die fertige 0.4.25 hier aus board runtergeladen. auf github
> (unter actions) finde ich Sie jedoch nicht.
> Gibt es eine Möglichkeit das Abfrageintervall MQTT von 90s zu
> reduzieren, damit die Daten ein bissl aktueller sind?
>
> VG

Das geht wohl schon über die config.h. aber so tief bin ich noch nicht 
in der Materie drin. Dann warte ich wohl noch ein bissl und versuche 
mich schlau zu machen wie man selbst compilen kann. Dazu habe ich leider 
noch keine (ausführliche) Anleitung für Anfänger gefunden. Weiter so 
*daumenHOCH

von Gerald R. (visitor)


Angehängte Dateien:

Lesenswert?

Ich habe mich nochmal als Programmierer versucht und in die aktuelle 
Ahoy Version von grindy https://github.com/grindylow/ahoy.git die 
SD-Karte eingepflegt.
Dieses mal an - und abwählbar mit einstellbarem Intervall im setup.html.

Der CS pin für die SD kommt auf D0.

Ich würde gerne die Firmware hier zur Verfügung stellen, bin mir aber 
nicht ganz sicher welche der beiden die Richtige ist.
Selsamer Weise flasht PlatformIO meine D1 mini 2x.
zuerst /build/d1_mini/firmware.bin
sofort danach mit /build/node_mcu_v2/firmware.bin
Ich nehme an beide sind ident sonst würde ja mein D1 mini mit der 
node_mcu_v2 firmware nicht funktionieren.

von Gerald R. (visitor)


Angehängte Dateien:

Lesenswert?

Tja, wer lesen kann ...
Stehen ja beide in der platform.ini.

Also hier die Firmware dazu für diejenigen die sie nicht selber bauen 
können oder wollen.

von Gerald R. (visitor)


Angehängte Dateien:

Lesenswert?

Habe testweise mal in Ahoy MIN_MQTT_INTERVAL auf 10 gesetzt.
Könnt ihr ja testen.
Ist die Version mit SD-Karte, die muss man ja nicht nutzen.

Keine Ahnung ob das dann auch funktioniert.

von Sven K. (svenk)


Lesenswert?

Gerald R. schrieb:
> Ich habe mich nochmal als Programmierer versucht und in die aktuelle
> Ahoy Version von grindy https://github.com/grindylow/ahoy.git die
> SD-Karte eingepflegt.
> Dieses mal an - und abwählbar mit einstellbarem Intervall im setup.html.
>
> Der CS pin für die SD kommt auf D0.
>
> Ich würde gerne die Firmware hier zur Verfügung stellen, bin mir aber
> nicht ganz sicher welche der beiden die Richtige ist.
> Selsamer Weise flasht PlatformIO meine D1 mini 2x.
> zuerst /build/d1_mini/firmware.bin
> sofort danach mit /build/node_mcu_v2/firmware.bin
> Ich nehme an beide sind ident sonst würde ja mein D1 mini mit der
> node_mcu_v2 firmware nicht funktionieren.

Hallo Gerald,
ich habe noch mal schnell das diff File überflogen:
Kann es sein das die SD Karte initialisiert wird ohne das Flag
zu prüfen ob die SD Karte ein oder ausgeschaltet ist?
Zeile mit Code

„if (!SD.begin(chipSelect)) {„

Könnte ja sein das jemand gerne
den Code übernimmt aber noch keine
SD Karte angeschlossen hat ?

Gruß Sven

von Holger S. (skusi)


Lesenswert?

Wie ich schon auf Discord bekannt gegeben hab, sind 30 Platinen von mir 
unterwegs. Kommen wohl nächste Woche. Ich gebe die gerne für 3 € das Stk 
ab. Oder auf Wunsch auch fertige Geräte.

von Steffen D. (steffen_d)


Lesenswert?

Holger S. schrieb:
> Wie ich schon auf Discord bekannt gegeben hab, sind 30 Platinen von mir
> unterwegs. Kommen wohl nächste Woche. Ich gebe die gerne für 3 € das Stk
> ab. Oder auf Wunsch auch fertige Geräte.

Top, sind die für den Wemos oder den Esp32?

von Gerald R. (visitor)


Lesenswert?

Sven K. schrieb:
> Kann es sein das die SD Karte initialisiert wird ohne das Flag
> zu prüfen ob die SD Karte ein oder ausgeschaltet ist?
> Zeile mit Code
>
> „if (!SD.begin(chipSelect)) {„
>
> Könnte ja sein das jemand gerne
> den Code übernimmt aber noch keine
> SD Karte angeschlossen hat ?
>
> Gruß Sven

Hallo Sven!

Ja, das hast du richtig gesehen.
Beim jedem Start wird überprüft ob eine SD vorhanden ist.
Da könnte man noch nachbessern, danke für den Hinweis!

Hatte aber in meinen Tests ohne SD keinen negativen Einfluss und es wird 
nicht versucht zu schreiben nach dem die Meldung:
I: SD card failed, or not present
kommt.
Das habe ich mit einer LED am CS pin überprüft.

Werde das morgen nochmal probieren, denn ohne Sonne wird nichts 
geschrieben ;-)

von Tobias G. (tobias_g841)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
hat jemand eine Idee, was man gegen "MQTT: not connected" tun kann?
Mal läuft es bei mir einen Tag durch, dann alle 30 Minuten der 
Verbindungsabbruch. Es hilft dann nur ein Reboot.
0.4.25 ist installiert, AHOY befindet sich ca 1,5m direkt neben den 
Hoymiles.

von oxylog (Gast)


Lesenswert?

Hallo allerseits,
ich hatte mir auch ein paar Platinen fertigen lassen.
Falls Bedarf besteht gebe ich von diesen gerne welche ab.
https://www.ebay-kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoy-dtu-esp8266/2171544569-168-9361

von Horst G. (horstg-57)


Lesenswert?

Also bei mir läuft MQTT ansich sehr stabiel ( bei mir ein Mosquito MQTT 
Server auf Debian 11 ).  Mir ist nur mal aufgefallen, wenn der Ahoi zu 
dicht am WLAN Access Point dran ist, wird der Empfänger für die 
Verbindung zum HM400 hin und wieder gestört ( Zustop effeckt ).Das kann 
natürlich auch anders herum vorkommen. Beide senden im gleichen 
Frequenzband.

Ein Problem ergibt sich noch , sobald der MQTT Client von Ahoi ( 0.4.25 
) die Verbindung zum MQTT Server verliert.
Die Reconnect Procedure in der mqtt.h wird sauber aufgerufen, nur 
bekomme der TCP_Client der unter der MQTT Verbindung liegt, die 
Verbindung nicht wieder aufgebaut ( Soweit konnte ich das bis jetzt 
nochvollziehen ).
Nach einer Verbindungsunterbrechung bringt
der MQTT Client sauber den Status -3 ( LOSS CONNECTION ) und
der TCP-Client bringt den Status 0.
Danach bekommt der TCP Client bzw. der MQTT Client die Verbindung nicht 
wieder aufgebaut. Ich habe es hier schon mit einem Disconnect probiert ( 
nachdem festgestellt wurde das die MQTT Verbindung abgebrochen ist ) 
bzw. mit einer Verzögerung vom bis zu 60 Sekunden bevor ein neuer 
connect Versuch unternommen wird. Auch ein "flush" und ein "stop" der 
TCP Verbindung haben keine Verbesserung der Situation gebracht.

von Tobias G. (tobias_g841)


Lesenswert?

Danke für Deinen Hinweis @Horst
ich selbst kann damit aber nur wenig anfangen. Ich hoffe auf eine neuere 
Firmware, die das Problem behebt, da es ja mehrere User haben.

von Holger S. (skusi)



Lesenswert?

Hallo, das soll jetzt keine Werbe Veranstaltung werden, aber wen es 
interessiert, hier mal ein paar Bilder von meinem Platinen Layout das 
ich entworfen und bestellt habe.

Ich würde 3,- pro Platine + 1,60 Versand nehmen.
Wer nicht löten kann oder will, kann auch ein fertiges Gerät für 45,- 
inc Versand bekommen.

Nur ein Angebot... Keine Profitabsichten ;-) Ich hab das eigentlich für 
mich und meinem Kumpel gemacht, und weil ich mit KiCad umgehen lernen 
wollte. Nun kann und soll aber auch gerne die Community was davon haben.

von Eike (Gast)


Lesenswert?

Hi,
ich bekomme keine Connect hin zum Wechselrichter.
ich habe nicht in den DTU settings eingetragen muss da was rein ?

Wlan klappt zu dem Modul....nur eben nicht zum Wechselrichter

ideen ?

eike

von Gerald R. (visitor)


Angehängte Dateien:

Lesenswert?

Betreffend SD init.

So wird die SD Karte nur dann initialisiert wenn man das Loggen im Setup 
aktiviert.
1
    if(mSDValues == true)
2
        {
3
        if (!SD.begin(chipSelect)) {
4
            DPRINTLN(DBG_INFO, String("SD card failed, or not present"));
5
            // don't do anything more:
6
            return;
7
        }
8
        DPRINTLN(DBG_INFO, String("SD card initialized."));
9
    }

Ob das notwendig ist, keine Ahnung.
Ich habe wie bereits erwähnt keine Nachteile durch eine nicht vorhandene 
SD bemerkt.

Aber trotzdem nochmal ein bin und ein diff für diese Version.

von Gerald R. (visitor)


Lesenswert?

Eike schrieb:
> ich habe nicht in den DTU settings eingetragen muss da was rein ?
>
> Wlan klappt zu dem Modul....nur eben nicht zum Wechselrichter

Du musst die Seriennummer deines Wechselrichters im Setup eintragen 
damit sich dein DTU damit verbinden kann.
Die Seriennummer findest du auf einem Aufkleber am Wechselrichter.

von Eike (Gast)


Lesenswert?

ja in inverter settings aber doch nicht in dtu settings oder ?

von Gerald R. (visitor)


Lesenswert?

Ich nehme an es geht um OpenDTU?

Das habe ich gerade nicht in Betrieb, aber da sollte eine Seriennummer 
für den DTU bereits eingetragen sein.

Funktionierte bei mir auf Anhieb.

Verkabelung OK?
Der verwendete NRF24 ist auch sicher ein NRF24L01+?

von Eike (Gast)


Lesenswert?

Jau da war auch eine drin die habe ich bei ersten Male gelöscht weil ich 
dachte ich muss da meine serial eintragen

von Gerald R. (visitor)


Lesenswert?

Die ist standardmäßig drinnen
99978563412

von Eike (Gast)


Lesenswert?

Eingetragen...klappt nicht wie nah muss das Teil beim Umrichter sein?

von Holger F. (holger_f)


Lesenswert?

@Eike Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist, 
d.h. DC-seitig Spannung hat und die LED blinkt. Ursache unbekannt. Kann 
es daran liegen?

von Eike (Gast)


Lesenswert?

ich habe noch einen tasmota powr r2 dran der misst schon die ganze zeit 
also power hat die kiste und alles klappt.......ich verstehe es 
nicht......ich kann sonst morgen mal ein foto von meinem Gehäuse machen

von Eike (Gast)


Lesenswert?

Gerald R. schrieb:
> Verkabelung OK?
> Der verwendete NRF24 ist auch sicher ein NRF24L01+?

System Info
Firmware Information
Hostname  OpenDTU-%06X
SDK Version  v4.4.1-1-gb8050b365e
Firmware Version  0.1.18
Git Hash  12df602
Reset Reason CPU 0  Vbat power on reset
Reset Reason CPU 1  for APP CPU, reseted by PRO CPU
Config save count  14
Uptime  0 days 00:28:17
Hardware Information
Chip Model  ESP32-D0WDQ6
Chip Revision  1
Chip Cores  2
CPU Frequency  240 MHz
Memory Information
Type  Usage  Free  Used  Size
Heap
31%
211 KByte  95 KByte  306 KByte
LittleFs
4%
308 KByte  12 KByte  320 KByte
Sketch
78%
335 KByte  1201 KByte  1536 KByte

von Gerald R. (visitor)


Lesenswert?

Da sehe ich das nicht, schau mal hier:
Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"

von Eike (Gast)


Lesenswert?


von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

@Eike
einmal Serial Log ansehen

von Eike (Gast)


Lesenswert?

und wie digga?

von Maik R. (bastelbarney)


Lesenswert?

locke987 schrieb:
> Wäre mit einem HM-1500 und iobroker/mqtt auch beim Testen dabei...

Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein 
einfaches Tutorium empfehlen, wie ich in ioBroker ein 
Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin 
MQTT-Neuling, aber sehr interessiert.

von Maik R. (bastelbarney)



Lesenswert?

Zur Diskussion mit den Abständen zwischen ESP8266 und nRF24 kann ich nur 
sagen: ich kann Eure Probleme nicht nachvollziehen, mit einem HM-1500 in 
10m Entfernung hinter einer Hausecke.

Ich habe meine Breadboard-Lösung (Bild rechts) mit 10 cm Kabel zwischen 
ESP und nRF heute zerlegen müssen (Breadbord wurde gebraucht) und den 
ESP auf eine 50-polige SCSI-Buchsenleiste (für 
Flachband-Schneidklemm-Montage) gesteckt, den nRF kurz dahinter und 
alles per hand "gecrimpt". Abstand zwischen WLAN-Antenne und nRF-Modul 
nur noch ca. 10 MILLIMETER, und zwar die WiFi-Antenne direkt neben dem 
nRF (Bild links).

Läuft hinreichend stabil! Ja, nur jedes 3 Frame ist ein Receive success. 
Aber da sabbelt ja auch noch ein original DTU-Pro dazwischen.

: Bearbeitet durch User
von Maik R. (bastelbarney)


Lesenswert?

Holger F. schrieb:
> Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist

Mein HM-1500 scheint erst zu antworten, sobald er in Summe 2 Watt von 
den Modulen bekommt, jedenfalls ist das der kleinste Wert, den ich Life 
sehe. Ich weiss nicht, ob er dabei die MPP Kurve durchprobiert oder 
einfach nur ein paar Minuten lang angeschlossene Module stabil sehen 
will. Wäre das ein Hinweis für Dich?

30 Minuten sind es mit dem 1500er eher nie. Na, vielleicht an 
Schlechtwettertagen. Aber beobachtet habe ich bislang eher wenige 
einstellige Minuten. Habe Ahoy gerade in ioBroker eingebunden, dann kann 
man es vllt. genauer nachvollziehen.

B.T.W:
An die Cloud senden der DTU-Pro und der DTU-W die Info zudem nur, wenn 
die Ports von vorne beginnend bestückt sind. Hatte zwei Tage mal A1 und 
A2 ab, da hat Ahoy kein Problem mit, aber die Cloud-DTUs sehen das als 
Störung und melden auch die Leistung nicht weiter, obwohl die Anlage 
auch laut 230V Zähler schön produziert.

Das soll jetzt keine Aufforderung sein, die Macke in Ahoy nachzubilden
=:-)

von Maik R. (bastelbarney)


Angehängte Dateien:

Lesenswert?

Eike schrieb:
> ich bekomme keine Connect hin zum Wechselrichter.
> ich habe nicht in den DTU settings eingetragen muss da was rein ?

schau mal in den angehängten Screenshot

von isnoAhoy (Gast)


Lesenswert?

von Klaus H. (klahi)
> Zu Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" : Aus 
Interesse
> habe ich mir das gitee-Repository zur DTU-PRO geladen. Ein Repository
> vergisst nichts :-)  Vor dem Commit mit dem Text "Document" mit der
> Commit-Kennung 2d24e2b7a261282501b44da26a5693d5033e8ba6 finden sich
> viele gelöschte Dokumente, unter anderem auch RF通讯协议-V6.6.xlsx
> (übersetzt RFprotocol-V6.6.xslx). Vielleicht finden sich dort aktuellere
> Informationen als in V6.5.
> Ansonsten finden sich in den älteren Commits sehr viele gelöschte
> Verzeichnisse und Dateien. Ich forsche mal noch weiter ...

Das ist interessant, muß das mal extrahieren und durch den Translator 
schicken

von Maik R. (bastelbarney)
> An die Cloud senden der DTU-Pro und der DTU-W die Info zudem nur, wenn
> die Ports von vorne beginnend bestückt sind. Hatte zwei Tage mal A1 und
> A2 ab, da hat Ahoy kein Problem mit, aber die Cloud-DTUs sehen das als
> Störung und melden auch die Leistung nicht weiter, obwohl die Anlage
> auch laut 230V Zähler schön produziert.

Ja das kann ich aus dem Source Code in UsartNrf3_Process_DevRunReality 
aka UsartNrf3_Process_DevRunDebug bestätigen. Dort werden die Werte 
immer überprüft bevor sie übernommen werden. Wenn er 0 Werte findet 
springt er aus der Parser Routine.

Auch das Bild mit den Angaben zur Konfiguration ist prima, werde es 
demnächst mal in die FAQ übernehmen.


PS: Ich habe die FAQ aktualisiert. Jetzt sind Dank @klahus1 einige 
DevInform Kommandos und deren Antworten dazugekommen. Vielleicht kann / 
wollen das einige implementieren, da man damit auch die FW / HW Version 
der Wechselrichter auslesen könnte.

https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

von isnoAhoy (Gast)


Lesenswert?

Hallo Klaus H.,
kannst Du eventuell den Link zum Git Commit / Dokument angeben ?
Ich habe nur 6.4 und 6.3 gefunden und die bereits bekannte aktuellste 
6.5.
Ich würde mir gerne mal die 6.6 ansehen wenn ich Sie zu lesen bekomme.

von isnoAhoy (Gast)


Angehängte Dateien:

Lesenswert?

Found it: RF通讯协议-V6.6.xlsx last entry from 2020.03.10

von Ha F. (harry_f)


Angehängte Dateien:

Lesenswert?

Zu dem Problem, dass keine Daten kommen, kann ich folgendes hinzufügen.

Mein Steckbrett liegt seit Wochen an einem "geeigneten" Ort, 
mittlerweile habe ich die Sendeleistung auf MIN eingestellt und es 
funktioniert. Abstand 20m, eine Ziegelwand.

ABER ich hatte es auch schon, dass nach einem OTA erstmal keine Daten 
geliefert wurden. Erst nach einem längerem Zeitfenster konnte des ESP 
Daten liefern. Evlt. ein Problem mit fehlerhaften Zeitstempeln in den 
Abfragen?
Sprich nach dem Neustart ist das Datum/Uhrzeit des ESP im Vergleich zum 
WR in der Vergangenheit und deshalb können keine Daten geliefert werden? 
Nur eine Vermutung.

Im Anhang eine Grafik wie die Produktion am Morgen beginnt.

von Eike (Gast)


Lesenswert?

Maik R. schrieb:
> schau mal in den angehängten Screenshot

Ich kann da gar nichts eintragen, da ich opendtu habe :(


Eike

von HM (Gast)


Lesenswert?

Hat schon mal jemand versucht ein Scanner zu bauen für Wechselrichter, 
deren Seriennummer nicht bekannt ist?
Gibt es eine Broadcast Seriennummer auf die alle antworten oder 
Bruteforce?

von Tom K. (mrfloppy)


Angehängte Dateien:

Lesenswert?

Hallo
Mein Ahoy läuft ganz gut soweit.
Habe einen Shelly auch drauf hängen, siehe Screenshot.
Mqtt in Richtung IoBroker funzt auch gut.
Nur welcher Wert ist nun der richtig von dem was ich Einspeise in mein 
Haus?
P_AC oder P_DC ?
Der Shelly misst und zeigt immer gleich mit P_DC.
Welchen soll ich in IoBroker loggen zum auswerten?

Danke für die tolle Arbeit.
LG Thomas

von Steffen D. (steffen_d)


Lesenswert?

Tom K. schrieb:
> Hallo
> Mein Ahoy läuft ganz gut soweit.
> Habe einen Shelly auch drauf hängen, siehe Screenshot.
> Mqtt in Richtung IoBroker funzt auch gut.
> Nur welcher Wert ist nun der richtig von dem was ich Einspeise in mein
> Haus?
> P_AC oder P_DC ?
> Der Shelly misst und zeigt immer gleich mit P_DC.
> Welchen soll ich in IoBroker loggen zum auswerten?
>
> Danke für die tolle Arbeit.
> LG Thomas

P_AC logge ich mit. Der Shelly ist zu ungenau. Meiner zeigt zuwenig an. 
P_DC ist Leistung des Moduls (Gleichspannung).

von Ha F. (harry_f)


Lesenswert?

ACHTUNG: Laienerklärung:

P_DC --> Power DC  ist die erzeugte Leistung der Module in Gleichstrom
P_AC --> Power AC  ist die erzeugte Leistung in Wechselstrom des WR aus 
dem gelieferten Gleichstrom.

Die Differenz ist der bei der Umwandlung entstehende Verlust bei der 
Umwandlung. Bzw. der Wirkungsgrad.


PV1_P_DC + PV2_P_DC = HM-800_P_DC

Efficiency 95.26%  ==   P_DC / P_AC *100  ->  Wirkungsgrad

von Holger F. (holger_f)


Lesenswert?

Maik R. schrieb:
> Holger F. schrieb:
>> Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist
>
> Mein HM-1500 scheint erst zu antworten, sobald er in Summe 2 Watt von
> den Modulen bekommt, jedenfalls ist das der kleinste Wert, den ich Life
> sehe. ... Wäre das ein Hinweis für Dich?

Danke, aber die 30 Minuten Wartezeit scheinen noch was anderes zu sein. 
Vom Labornetzteil habe ich sofort 30 V mit max. 2 A, also max. 60 Watt. 
Ohne Verbindung zum AC-Stromnetz nimmt sich mein HM-600 1.1 Watt zum 
Betrieb; ab da lebt (blinkt) er.

Habe jetzt nochmal ganz genau gemessen:

Es dauerte genau 29 Minuten 50 Sekunden zwischen Anschalten meines 
Labornetzteils auf der DC-Eingangsseite bis zum ersten erfolgreichen 
Datenempfang in OpenDTU. Ab dann stabiler Empfang.

Das ist unabhängig von
- DC an String 1 oder 2
- AC-Seite mit Stromnetz verbunden oder nicht
- erfolgreicher Datenlieferung vor WR-Neustart (vor DC aus-ein) oder 
nicht
- OpenDTU Neustarts

=> Jeder neue WR-Start bringt wieder die 30 Minuten Zwangspause.

Ha F. schrieb:
> ABER ich hatte es auch schon, dass nach einem OTA erstmal keine Daten
> geliefert wurden. Erst nach einem längerem Zeitfenster konnte des ESP
> Daten liefern. Evlt. ein Problem mit fehlerhaften Zeitstempeln in den
> Abfragen?

Ich habe auch irgendeine Logik auf Basis der Zeitstempel im Verdacht. 
OpenDTU sendet aber erst nach erfolgreichem NTP-Sync Abfragen zum WR, 
das habe ich im Code so gesehen und mit ein paar Debug-Ausgaben 
überprüft. Der erste für Abfragen verwendete Zeitstempel war bereits 
korrekt und Rücksprünge konnte ich nicht sehen.

Hat der HM-600 eine gepufferte Uhr?

von Ralla66 (Gast)


Lesenswert?

Bei meinem HM-600 mit ESP8266 mit Ahoi ist seriell zu sehen das nur 
Transmit 27 / 15 gesendet wird mit der Fehlermeldung das ein Frame 
fehlt. Erst nach Stromtrennung des ESP wird dann Transmit 11 / 15 
gesendet worauf der Payload angezeigt wird.Zeitstempel sind aber ok.

von Eike (Gast)


Lesenswert?

Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot und ich 
erreiche das Teil gar nicht mehr.
Wie bekomme ich eine bin von dem ayoli zeig her ?


Eike

von Oswald S. (obmaroszi)


Angehängte Dateien:

Lesenswert?

Also das OpenDTU Mist ist kann ich nicht behaupten. (würde ich auch 
nicht blos wenns mal wo klemmt)
ich würde wenns schon nicht funktioniert einfach noch mal von vorne 
beginnen.
Habe beide Systeme laufen und derzeit läuft bei mir OpenDTU stabiler und 
länger trotz deutlich größerem Abstand zum WR.

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Merkwürdig.
OpenDTU läuft bei mir seit Wochen einwandfrei.
Ich würde sagen, der Fehler sitzt selber vor dem Teil,....

von locke987 (Gast)


Lesenswert?

Maik R. schrieb:
> Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein
> einfaches Tutorium empfehlen, wie ich in ioBroker ein
> Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin
> MQTT-Neuling, aber sehr interessiert.

Ich mache das mit dem influxdb adapter der die Objekte bzw. geloggten 
Daten in eine influxdb schreibt und mittels Grafana mache ich dann die 
Auswertung. Tutorial habe ich leider keines. Beides habe ich als 
container in unraid laufen, hat keine halbe Stunde gedauert bis ich die 
ersten Graphen zusammen hatte.

von Ha F. (harry_f)


Lesenswert?

Eike schrieb:
> Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot
> und ich
> erreiche das Teil gar nicht mehr.
> Wie bekomme ich eine bin von dem ayoli zeig her ?
>
> Eike

Hallo,

steht schon mehrfach immer wieder mal weiter oben:
https://github.com/grindylow/ahoy/actions

Man muss angemeldet sein!


Hier die FAQ:
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu

von Oswald S. (obmaroszi)


Angehängte Dateien:

Lesenswert?

Ich mache es mit Openhabian da ich mit IObroker generell nicht zurecht 
kam
Mit Openhabian hat bei mit super funktioniert. (auch E2 Boxen, Smart 
Steckdosen, temp Messung)
Anbei Vergleich Bild Gosund / WR Leistung

von Joachim (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen, zunächst einen großen Dank an alle, die das Projekt hier 
zustande gebracht haben! Ich bin eher 'erfahrener Anfänger' und habe 
hier mal eine kleine Anleitung einschl. der PIN-Belegung für den D1 mini 
angehängt. Das erspart dem einen oder anderen vielleicht eine längere 
Suche im Forum oder woanders - jedenfalls ging es mir so.

Und: falls jemand mal wieder Platinen bestellen sollte - ich hätte noch 
Bedarf für eine Platine :-)

von Canon.Fritz (Gast)


Lesenswert?

Könnte einer von euch nochmal das Mqtt Topic für die Leistungsbegrenzung 
posten?

Ich habe die Ahoi Version mit der 0.4.25.bin hier aus dem Forum am 
laufen. WR ist der HM600

Danke ;)

von Daniel M. (daniel_m821)


Lesenswert?

Holger F. schrieb:
> @Eike Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist,
> d.h. DC-seitig Spannung hat und die LED blinkt. Ursache unbekannt. Kann
> es daran liegen?

Hallo Holger und Eike,

das Problem ist bekannt, offenbar fehlt noch ein Resetbefehl für die 
Kommunikation.
Wir analysieren das demnächst, muss aber das Dauerlogging vorbereiten.

lg

von Eike (Gast)


Lesenswert?

Danke, ich Jan schon gedacht ich bin bescheuert. Sieht ja alles Klasse 
aus soweit nur ich würde gern sehen ob ich alles richtig installiert 
habe. Ich kann das ja nicht testen und sehen das alle Module dran sind.


Danke

Eike

von Stefan T. (isnoahoy)


Angehängte Dateien:

Lesenswert?

Hier eine Neuigkeit aus der Welt der AlarmData Events dank der 
Aufzeichnungen von @klahus1:

Anscheinend wandern die Events aus dem AlarmData langsam nach oben raus.
Ich habe nur 15 Einträge in den beiden o.g. Antworten des 
Wechselrichters finden können:
1
$ sdiff -w $COLUMNS AlarmData1.txt AlarmData2.txt 
2
0001                                   |    0001
3
B001 0006 8D99 8D99 0000 0000          |    B001 0006 8D93 8D93 0000 0000
4
B002 2783 5EC0 5EC0 FFFF E3E7          |    B002 2784 5EF2 5EF2 0000 1C19
5
B002 2784 5EF8 5EF8 0000 1C19          |    B002 2785 5EF6 5EF6 FFFF E3E7
6
B002 2785 5EFC 5EFC FFFF E3E7          |    B002 2786 5F10 5F10 0000 1C19
7
B002 2786 5F16 5F16 0000 1C19          |    B002 2787 5F14 5F14 FFFF E3E7
8
B002 2787 5F1A 5F1A FFFF E3E7          |    B002 2788 5F4C 5F4C 0000 1C19
9
B002 2788 5F52 5F52 0000 1C19          |    B002 2789 5F50 5F50 FFFF E3E7
10
B002 2789 5F56 5F56 FFFF E3E7          |    B002 278A 5F6A 5F6A 0000 1C19
11
B002 278A 5F70 5F70 0000 1C19          |    B002 278B 5F6E 5F6E FFFF E3E7
12
B002 278B 5F74 5F74 FFFF E3E7          |    B002 278C 5F88 5F88 0000 1C19
13
B002 278C 5F8E 5F8E 0000 1C19          |    B002 278D 5F8C 5F8C FFFF E3E7
14
B002 278D 5F92 5F92 FFFF E3E7          |    B002 278E 6031 6031 FFFF FFFB
15
B002 278E 6037 6037 FFFF FFFB          |    B002 278F 6036 6036 0000 0005
16
B002 278F 603C 603C 0000 0005          |    B002 2790 71AE 71AE FFFF FFFB
17
B002 2790 71B4 71B4 FFFF FFFB          |    B002 2791 7380 7380 0000 0005
18
D6EC                                   |    6E24

Was mir dabei aufgefallen ist:
* der ESP schickt fast immer den selben Zeitstempel mit (praktisch immer 
62E98701)
* die Zeitstempel in den beiden o.g. AlarmData Ausgaben differieren um 
ein paar Sekunden:
  - Event 2790 um 71B4 und beim zweiten Aufruf um 71AE. Das sind ca. 6 
Sekunden.
  - 22:20:21.978 .. 22:20:27.649 sind 5,671 Sekunden.
Ich vermute daher der WR aktualisiert seine interne RTC nachdem er immer 
die selbe Zeit vom ESP bekommt.

Es ist also wichtig bei Retransmits und anderen Angaben immer die RTC 
der DTU in den Zeitstempel einfließen zu lassen, sonst gibt es die oben 
beobachteten Zeitverschiebungen.

von Olli (Gast)


Lesenswert?

Hallo,

ich habe hier nach Anleitung auch mal alles in Betrieb genommen und 
erhalte grundsätzlich auch Daten vom Wechselrichter.
Diese sind aber bisher alls andere als zuverlässig.

Ich erhalte zumr Zeit 3 Arten von Datensätzen.
Zum einen, die richten Werte die man auch erwarten würde.
Hier passen die Werte, z.B. 500W P_AC, YieldDay passt z.B. auch.

Einige Sekunden später werden dann mal wieder alle Werte als 0 
angegeben.
Und bei der nächsten Abfrage sind es utopische Werte. z.B. 4000V U_DC, 
oder 9500W P_AC.

Das Verhalten ist mit unterschiedlichen WR so.
Das Modul befindet sich testweise in der Nähe des WR.

Amplifier Power Level Einstellungen machen hier keinen Unterschied.

Hatte das schon mal jem. von euch?

Danke schon mal.

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

@Olli
Das hat man normal, wenn parallel eine original DTU mitläuft.

von Dirk (Gast)


Lesenswert?

Hi zusammen, ich hab seit etwa 1 Woche 3x1500ter am Start mit der hier 
beschriebenen Konfiguration. Hat bis gestern alles super funktioniert. 
Aber seit gestern 18 Uhr erreiche ich einen gar nicht mehr. DTU wird 
jede Nacht ( wegen MQTT-Verbindungsverlust) neu gestartet. WR war die 
Nacht auch Stromlos (auch 230V).
Was kann ich tun jemand ne Idee ?

von Tobias G. (tobias_g841)


Lesenswert?

Dirk schrieb:
> Hi zusammen, ich hab seit etwa 1 Woche 3x1500ter am Start mit der hier
> beschriebenen Konfiguration. Hat bis gestern alles super funktioniert.
> Aber seit gestern 18 Uhr erreiche ich einen gar nicht mehr. DTU wird
> jede Nacht ( wegen MQTT-Verbindungsverlust) neu gestartet. WR war die
> Nacht auch Stromlos (auch 230V).
> Was kann ich tun jemand ne Idee ?

Ich habe heute früh auch schon bestimmt 10x reboot gemacht, weil immer 
wieder MQTT not connected erscheint - irgendwie ist heute der Wurm 
drinnen.
Sonst passiert es nur 2-3x pro Tag.

von Olli (Gast)


Lesenswert?

Rene M. schrieb:
> @Olli
> Das hat man normal, wenn parallel eine original DTU mitläuft.

Hey,

vielen Dank für die Info.
Das ist bei mir nicht der Fall. Weitere Ideen?

Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht 
funktionieren würden?

von Highlander (Gast)


Lesenswert?

Olli schrieb:
> Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht
> funktionieren würden?

Es kann nur einen geben;-)

von Olli (Gast)


Lesenswert?

Highlander schrieb:
> Es kann nur einen geben;-)

Warum ist das so?
Ich ging davon aus, dass die WR Ihre Daten einfach in die Welt raus 
schreien und die DTUs diese empfangen.

von Stefan T. (isnoahoy)


Lesenswert?

Hallo Zusammen,

der RECV_CHANNEL 0x61 ist m.W. der mit dem er loslegt. Es wurde bei 
ersten Tests herausgefunden, dass bei TX auf Kanal 0x61 die nächste 
Antwort auf Kanal 0x03 relativ gut empfange wurde, d.h. zwei Kanäle 
Unterschied. Ob das am Timing zwischen Senden und Empfangsbereitschaft 
des Ahoy DTU Codes ist, oder etwas anderes weiß ich nicht.

Die Originalaufzeichnungen mit Hack RF und anderen Geräten von martin 
(Gast), B. G. (golf2010) und Oliver F. (of22) auf Seite 1 & 2 des Forums 
hatten gezeigt, daß auch der Wechselrichter alle 2-5 Antwortpakete die 
Frequenz wechselt.

Dafür gibt (bzw. gab da in der Zwischenzeit immer aktiv) es das sog. 
Channel Hopping das die mRxChList[4]={03, 23, 40, 61, 75} der Reihe nach 
durchgeht. Für die mTxChLst[0]=40 gibt es das bisher noch nicht. Wer 
also Probleme mit dem Funk hat könnte sich daran machen auch für das 
Senden ein Channel Hop einzubauen und vor allem die beiden irgendwie 
sinnvoll miteinander zu koordinieren, damit er auch den nächsten 
Empfangskanal des Wechselrichters möglichst gut errät. Dazu muß man sich 
wie gesagt die o.g. Hack RF Aufnahmen ansehen und einen geschickten 
Algorithmus finden.

Hier noch die Links zum Source Code für die mTxChLst und mRxChLst:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L59-L69

Allgemeine Beobachtung von Oliver F. die aber den Spezifikationen in der 
FCC Application Note für die HMS-100 widersprechen. Dort sind 
tatsächlich nur die o.g. Kanäle (2403, 2423, 2440, 2461, 2475MHz) 
beantragt und werden m.W. auch ausschließlich genutzt.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Hier einige Beiträge von B.G. (golf2010) der das Channel Hopping auf 
seinen Scans relativ gut darstellt.
Was mir dabei aufgefallen ist, sind die Retry-Kaskaden von 15 
Retransmits jeder Nachricht.
Das liegt m.E. eventuell daran, daß die DTU mit diesen aktuellen 
Retransmit Settings ebenso viele Anfragen sendet ?
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Kann man die o.g. Beobachtungen nicht auch mit einem RTL-SDR (RTL2832U) 
mit einem der Tools unter 
https://www.rtl-sdr.com/big-list-rtl-sdr-supported-software/ machen. 
Solange es nur um das Aufzeichnen des Channel Hoppings einer einsamen 
DTU-Pro und eines WR geht sollte das doch zumindest helfen die Kanäle 
und das Muster zu erkennen ?

von Harry G. (sorentodriver)


Lesenswert?

Holger S. schrieb:
> Hallo, das soll jetzt keine Werbe Veranstaltung werden, aber wen es
> interessiert, hier mal ein paar Bilder von meinem Platinen Layout das
> ich entworfen und bestellt habe.
>
> Ich würde 3,- pro Platine + 1,60 Versand nehmen.
> Wer nicht löten kann oder will, kann auch ein fertiges Gerät für 45,-
> inc Versand bekommen.
>
> Nur ein Angebot... Keine Profitabsichten ;-) Ich hab das eigentlich für
> mich und meinem Kumpel gemacht, und weil ich mit KiCad umgehen lernen
> wollte. Nun kann und soll aber auch gerne die Community was davon haben.

Hallo Holger,
ich würde gerne dein Angebot in Anspruch nehmen.Und ein fertiges Gerät + 
Versand kaufen.
H.G.

von guilligan (Gast)


Lesenswert?

Ha F. schrieb:
> Eike schrieb:
>
>> Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot
>> und ich
>> erreiche das Teil gar nicht mehr.
>> Wie bekomme ich eine bin von dem ayoli zeig her ?
>> Eike
>
> Hallo,
> steht schon mehrfach immer wieder mal weiter oben:
> https://github.com/grindylow/ahoy/actions
> Man muss angemeldet sein!
> Hier die FAQ:
> 
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu

Hi, ich bin angemeldet, kann aber leider keine fertige .bin finden. Auch 
die FAQ ist an der Stelle noch nicht fertig aufgebaut. Da kommt aber 
bestimmt noch Hilfe oder ?

VG Frank

von Giuseppe M. (drdigital)


Angehängte Dateien:

Lesenswert?

Highlander schrieb:
> Es kann nur einen geben;-)

Ich kann das so nicht bestätigen.
Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32.
Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten.
Aktuell wird bei mir ein HM-600 und ein HM-700 ausgelesen und es kommt 
demnächst noch ein weiterer HM-700 dazu. Entfernung von DTU-Pro und 
ESP32 zu HM-600 ist in etwa 3 Meter durch eine Sicherheitsverglasung und 
zum HM-700 ca. 8 Meter durch zwei Wände.

Als ich diesen Thread und das OpenDTU mit ESP32 gefunden hatte war meine 
DTU-Pro schon unterwegs.
Da ich evtl. das Limit Active Power nutzen möchte habe bzw. werde ich 
die DTU-Pro trotzdem behalten.

Hat das hier schon jemand erfolgreich benutzt?

Ich verstehe den Modbus Befehl nicht so richtig.
Laut Anleitung in der DTU-Pro soll Function Code 0x05 an die Adresse 
0xC001 gesendet werden (siehe auch Anhang). Dabei soll man Werte bei HM 
von 2 bis 100% senden können.
Nach meinem Verständnis kann Function Code 0x05 aber nur 1 Bit Werte 
senden bzw. schreiben also nur 1 oder 0.

Kann mir da jemand weiter helfen bzw. den entscheidenden Tipp geben?

Wenn es eine Möglichkeit gibt über OpenDTU per MQTT diese limit Active 
Power zu setzen wäre das natürlich auch super.

von Günter H. (gnter_h534)


Angehängte Dateien:

Lesenswert?

guilligan schrieb:
> Hi, ich bin angemeldet, kann aber leider keine fertige .bin finden.

In dem angehängten Bild habe ich den Weg zur .bin am Beispiel "ahoy" 
skizziert. Die neuste .bin ist jeweils oben in der Liste.

Für "OpenDTU" gelten die Angaben sinngemäß.

Viel Erfolg - Günter

: Bearbeitet durch User
von Olli (Gast)


Lesenswert?

Ist OpenDTU eine Alternive zu Ahoi und kann auch auf einem Esp8266 
installiert werden?

von Günter H. (gnter_h534)


Lesenswert?


von Olli (Gast)


Lesenswert?

Danke Dir.

von JedernureinKreuz (Gast)


Lesenswert?

Vermutlich ist es ein simpler Anfängerfehler, aber ich bekomme ahoy 
nicht auf meinem RasPi zum laufen. Das getting_started von RF24 läuft 
und ich sehe die SPI Kommunikation auf dem Oszi, aber wenn ich ahoy 
starten will bekomme ich folgendes:

pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config 
ahoy.yml
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "/home/pi/ahoy-tool/hoymiles/__init__.py", line 14, in <module>
    from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, 
RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
ModuleNotFoundError: No module named 'RF24'

Aber in der pip list ist es, so soll es doch eigentlich sein?

pi@ahoy:~/ahoy-tool $ python3 -m pip list
Package       Version
------------- ---------
certifi       2020.6.20
chardet       4.0.0
colorzero     1.1
crcmod        1.7
distro        1.5.0
gpiozero      1.6.2
idna          2.10
paho-mqtt     1.6.1
pip           22.2.1
python-apt    2.2.1
PyYAML        6.0
requests      2.25.1
RF24          1.4.5
RPi.GPIO      0.7.0
setuptools    63.4.0
six           1.16.0
spidev        3.5
ssh-import-id 5.10
urllib3       1.26.5
wheel         0.34.2

Hat jemand eine Idee?

von Olli (Gast)


Lesenswert?

Giuseppe M. schrieb:
> Ich kann das so nicht bestätigen.
> Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32.
> Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten.

Hallo,

ist was etwas technisches, dass sich die Systeme stören, oder liegt das 
an der Software?
Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?

von Ziyat T. (toe_c)


Lesenswert?

Giuseppe M. schrieb:
>
> Ich verstehe den Modbus Befehl nicht so richtig.
> Laut Anleitung in der DTU-Pro soll Function Code 0x05 an die Adresse
> 0xC001 gesendet werden (siehe auch Anhang). Dabei soll man Werte bei HM
> von 2 bis 100% senden können.
> Nach meinem Verständnis kann Function Code 0x05 aber nur 1 Bit Werte
> senden bzw. schreiben also nur 1 oder 0.
>
> Kann mir da jemand weiter helfen bzw. den entscheidenden Tipp geben?
>
das Handbuch hat viele Fehler!
Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport. 
Raspi/PyModbus:
clientDTU.read_holding_registers und
clientDTU.write_register
für alle DTU-Pro Register
also nicht mit FC 0x05

von Ziyat T. (toe_c)


Lesenswert?

JedernureinKreuz schrieb:

> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
mit sudo

> pi@ahoy:~/ahoy-tool $ python3 -m pip list
ohne sudo

kann sein dass die beiden aufrufe andere "environments" haben

von Ziyat T. (toe_c)


Lesenswert?

Olli schrieb:
> Giuseppe M. schrieb:
>> Ich kann das so nicht bestätigen.
>> Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32.
>> Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten.
>
> Hallo,
>
> ist was etwas technisches, dass sich die Systeme stören, oder liegt das
> an der Software?
> Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?

JA es laufen beide parallel wenn die DTU-Adressen gleich sind

von Ziyat T. (toe_c)


Lesenswert?

Stefan T. schrieb:

> gab da in der Zwischenzeit immer aktiv) es das sog.
> Channel Hopping das die mRxChList[4]={03, 23, 40, 61, 75} der Reihe nach
> durchgeht. Für die mTxChLst[0]=40 gibt es das bisher noch nicht. Wer
> also Probleme mit dem Funk hat könnte sich daran machen auch für das
> Senden ein Channel Hop einzubauen und vor allem die beiden irgendwie
> sinnvoll miteinander zu koordinieren, damit er auch den nächsten
> Empfangskanal des Wechselrichters möglichst gut errät. Dazu muß man sich
> wie gesagt die o.g. Hack RF Aufnahmen ansehen und einen geschickten
> Algorithmus finden.

Das habe ich ja schon lange hier geschrieben und so ist meine SW 
implementiert. Mein MI-1500 aendert die kanaele staendig, so muss ich 
auf RX UND TX hoppen. Ich glaube auch, dass nicht nur der MI so macht..

von Giuseppe M. (drdigital)



Lesenswert?

Olli schrieb:
> Hallo,
>
> ist was etwas technisches, dass sich die Systeme stören, oder liegt das
> an der Software?
> Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?

Zum präzisieren.
Ich verwende einen ESP32 keinen ESP8266 bzw. WemosD1
Ich habe zum flashen des ESP32 das hier verwendet
https://github.com/tbnobody/OpenDTU
Es gibt keine fertigen Bin Dateien bzw. habe ich keine gefunden musste 
also genau nach Anleitung per Vscode den ESP32 bespielen.
Nach meinem Verständnis basieren aber Ahoy Wemos D1 und das OpenDTU für 
den ESP32 auf dem gleichen Basis Code sollten also sehr ähnlich sein.
Der ESP32 hat lediglich etwas mehr Speicher und CPU-Speed.

Ich habe die DTU-Pro und den ESP32 im Abstand von ca. 0,5 m gleichzeitig 
im Betrieb.
Der ESP32 ist per MQTT an meinem Smarthome System (Symcon) angebunden.
Die Daten werden zuverlässig übertragen und geloggt (siehe beigefügte 
Screenshots).
Die DTU-Pro wird aktuell nur mit der Cloud genutzt also kein ständiges 
auslesen per Modbus oder ähnliches. Aber in der Cloud werden die zwei 
Wechselrichter ebenfalls zuverlässig geloggt (siehe Screenshot).

von Giuseppe M. (drdigital)


Lesenswert?

Ziyat T. schrieb:
> das Handbuch hat viele Fehler!
> Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport.
> Raspi/PyModbus:
> clientDTU.read_holding_registers und
> clientDTU.write_register
> für alle DTU-Pro Register
> also nicht mit FC 0x05

Vielen Dank für die Rückmeldung.
Sind die Register in der Anleitung korrekt?
Oder sind diese ebenfalls fehlerhaft?
Das lesen der Daten also Leistung etc. mit 0x03 funktioniert bei mir 
soweit ohne Probleme.
Nach Deiner Erklärung müsste ich also z.B. zum limitieren aller 
Wechselrichter  in das Register 0xC001 per Function 0x06 einen Wert von 
2-100 schreiben.
Das werde ich morgen mal ausprobieren.

Wenn Du dies schon länger verwendest, wie lange dauert es bis die 
Wechselrichter auf den neuen Limit Wert reagieren?

von Ziyat T. (toe_c)


Lesenswert?

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> das Handbuch hat viele Fehler!
>> Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport.
>> Raspi/PyModbus:
>> clientDTU.read_holding_registers und
>> clientDTU.write_register
>> für alle DTU-Pro Register
>> also nicht mit FC 0x05
>
> Vielen Dank für die Rückmeldung.
> Sind die Register in der Anleitung korrekt?
> Oder sind diese ebenfalls fehlerhaft?
> Das lesen der Daten also Leistung etc. mit 0x03 funktioniert bei mir
> soweit ohne Probleme.
> Nach Deiner Erklärung müsste ich also z.B. zum limitieren aller
> Wechselrichter  in das Register 0xC001 per Function 0x06 einen Wert von
> 2-100 schreiben.
> Das werde ich morgen mal ausprobieren.
>
> Wenn Du dies schon länger verwendest, wie lange dauert es bis die
> Wechselrichter auf den neuen Limit Wert reagieren?

- ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006 
ist nicht für  Port 1 sondern für WR 1
- beim MI unter 10% schaltet er fast auf 0
- er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche 
v. mppt ist, dann klar etwas laenger)

von JedernureinKreuz (Gast)


Lesenswert?

Ziyat T. schrieb:
> JedernureinKreuz schrieb:
>
>> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
> mit sudo
>
>> pi@ahoy:~/ahoy-tool $ python3 -m pip list
> ohne sudo
>
> kann sein dass die beiden aufrufe andere "environments" haben

Abgefahren, jetzt muss ich das nur noch bereinigt bekommen...


pi@ahoy:~ $ sudo python3 -m pip list
Package       Version
------------- ---------
certifi       2020.6.20
chardet       4.0.0
colorzero     1.1
crcmod        1.7
distro        1.5.0
gpiozero      1.6.2
idna          2.10
paho-mqtt     1.6.1
pip           20.3.4
python-apt    2.2.1
PyYAML        6.0
requests      2.25.1
RPi.GPIO      0.7.0
setuptools    52.0.0
six           1.16.0
spidev        3.5
ssh-import-id 5.10
urllib3       1.26.5
wheel         0.34.2

von Giuseppe M. (drdigital)


Angehängte Dateien:

Lesenswert?

Ziyat T. schrieb:
> - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006
> ist nicht für  Port 1 sondern für WR 1
> - beim MI unter 10% schaltet er fast auf 0
> - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche
> v. mppt ist, dann klar etwas laenger)
Das es WR1 sein muss dachte ich mir schon.
Adresse ist C006?
Weil in der Anleitung steht C007.
Ich werde es morgen testen und noch mal Rückinfo geben.
Vielen Dank

von Stefan T. (isnoahoy)


Lesenswert?

Für alle die Ahoy DTU (ESP8266) nutzen, @baloo und ich haben uns heute 
das Problem mit dem MQTT Reconnect angesehen und einen Wechsel des TX 
Kanals für diejenigen, die manchmal 30 Minuten keine Daten vom WR 
bekommen eingebaut.

Der Pull Request dafür ist gestellt.

fix MQTT problem and add TX channel switch to send loop #119
https://github.com/grindylow/ahoy/pull/119

von Olli (Gast)


Lesenswert?

Giuseppe M. schrieb:
> Zum präzisieren.
> Ich verwende einen ESP32 keinen ESP8266 bzw. WemosD1
> Ich habe zum flashen des ESP32 das hier verwendet
> https://github.com/tbnobody/OpenDTU
> Es gibt keine fertigen Bin Dateien bzw. habe ich keine gefunden musste

Vielen Dank für die Infos.
Die .bin Files kannst du doch über "Aktions" generieren.

von Stefan T. (isnoahoy)


Lesenswert?

Hallo Olli,
Thomas B. schreibt OpenDTU gerade großteils um / neu um die in der 
Zwischenzeit neu hinzugekommenen Kommandos unterzubringen. Es gibt m.W. 
für OpenDTU noch keine GitHub Actions die automatisch die Binaries 
erzeugen.
Wenn Du also Lust hast und weißt wie es geht, kannst Du gerne die 
Actions erstellen und in einem Fork testen.

von HM (Gast)


Lesenswert?

Hallo,
ist in OpenDTU oder Ahoy die Möglichkeit schon eingebaut die Leistung zu 
limitieren? Ich muss meinen Elektriker zeigen, dass ich die Geräte auf 
70% eingestellt habe.

LG

von Thomas B. (tbnobody)


Lesenswert?

Stefan T. schrieb:
> Es gibt m.W. für OpenDTU noch keine GitHub Actions die automatisch die Binaries 
erzeugen.

Doch gibt es...

von Ziyat T. (toe_c)


Lesenswert?

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006
>> ist nicht für  Port 1 sondern für WR 1
>> - beim MI unter 10% schaltet er fast auf 0
>> - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche
>> v. mppt ist, dann klar etwas laenger)
> Das es WR1 sein muss dachte ich mir schon.
> Adresse ist C006?
> Weil in der Anleitung steht C007.
> Ich werde es morgen testen und noch mal Rückinfo geben.
> Vielen Dank

0xc006 on/off wr1
0xc007 limit wr1

: Bearbeitet durch User
von Horst G. (horstg-57)


Lesenswert?

habe mal einen Fork mit meiner Lösung für das MQTT-Reconncet Problem und 
dem Anmeldenamen am MQTT erstellt.

Der Reconncet läuft bei mir jetzt sehr zuverlässig und für die Anmeldung 
am MQTT wird jetzt der Device-Name verwendet ( wie er im Setup steht ).

Ausserdem sende ich die MQTT Daten jedesmal sofort aus,
nachdem die WR Daten intern aufbereitet wurden.

Ich lese den WR alle 30 Sekunden aus und erhalte die Daten mit 2 
Sekunden Verzögerung ( so gewollt wegen Funkfeld Belegung ) sofort im 
MQTT-Broker.

Den Pull Request dafür habe ich erstellt.

von Lukas P. (lumapu)


Lesenswert?

Hier kann man die neueste Version von Ahoy ESP8266 runterladen, mit MQTT 
Reconnect von isnoAhoy

Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link 
auch jede neuere Version bekommen (ohne Login):
https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip

: Bearbeitet durch User
von Olli (Gast)


Lesenswert?

Stefan T. schrieb:
> Wenn Du also Lust hast und weißt wie es geht, kannst Du gerne die
> Actions erstellen und in einem Fork testen.

Hallo Stefan,

da bin ich leider der Falsche, da mir da einige Kenntnisse fehlen.
Aber "Actions" gibt es doch bereits über die man sich eine .bin erzeugen 
kann.

von Dirk S. (fusebit)


Lesenswert?

Ziyat T. schrieb:
> JedernureinKreuz schrieb:
>
>> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
> mit sudo
>
>> pi@ahoy:~/ahoy-tool $ python3 -m pip list
> ohne sudo
>
> kann sein dass die beiden aufrufe andere "environments" haben

Jetzt auch wieder mit Login, bitte nicht meckern :-)

Ich habe diesen Teil
python3 -m pip install --upgrade pip
python3 -m pip install .
von hier https://github.com/grindylow/ahoy/tree/main/tools/rpi

nochmal als sudo ausgeführt und nun ist das Modul gelistet.

Danach bekam ich syntax errors, nachdem ich in

ahoy/tools/rpi/hoymiles/decoders/__init__.py

Die Kommentareinleitungen von // auf # geändert habe funktioniert es 
jetzt (vermutlich). Mein HM-300 ist noch unterwegs, aber ahoy versucht 
jetzt zu pollen :-)

von Tobias G. (tobias_g841)


Lesenswert?

Vielen Dank an alle Beteiligten für die 0.4.26 - ich bin gespannt.

Wo bringe ich den Wunsch ein, oben bei Visualisation eine summierte 
Gesamtübersicht (YieldTotal, Day, P_AC, P_DC) haben zu können?
Jeder, der mehrere Wechselrichter betreibt, dürfte sich darüber freuen.

Idealerweise per Checkbox im Setup auswählbar (Display SUM).

von Günter H. (gnter_h534)


Lesenswert?

Lukas P. schrieb:
> Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link
> auch jede neuere Version bekommen (ohne Login):
> https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip

Über "Actions" bei GitHub ist nun wirklich kein Hexenwerk, der Link ist 
aber noch komfortabler.

Danke dafür und für die ganze Entwicklungsarbeit - natürlich auch an das 
ganze "Team".

von Stefan T. (isnoahoy)


Lesenswert?

Danke auch an HorstG-57 und baloo die beim finden und beheben des MQTT 
Problems tatkräftig unterstützt haben. Jetzt bin ich gespannt ob das 
auch tatsächlich allen Betroffenen hilft und wir einige Issues schließen 
können.

@Tobias G. wenn ich mich recht entsinne hat das bereits jemand 
umgesetzt. Der Code / Pull Request steht aber noch aus...

von Frank L. (guilligan)


Lesenswert?

Ich habe auf Version 0.4.26 geupdatet. Bei mqtt ist immernoch nur 
read-only 75s möglich (also keine Eingabe einer kürzeren Zeit)? Oder 
sehe ich das nur nicht?
Kann diese Version schon Befehle zur Limitierung über Mqttfx umsetzen 
und wenn ja wie wären die zu schreiben? Bei mir "dtu/hm600/Ch0/??????" 
Und was anstelle der "?" ?
Danke für Hilfe und die Supi-Arbeit hier.

VG Frank (Anfänger mit technischem Verständnis, aber ohne 
Programmierung)

: Bearbeitet durch User
von Holger F. (holger_f)


Lesenswert?

Stefan T. schrieb:
> ... und einen Wechsel des TX
> Kanals für diejenigen, die manchmal 30 Minuten keine Daten vom WR
> bekommen eingebaut.
>
> Der Pull Request dafür ist gestellt.
>
> fix MQTT problem and add TX channel switch to send loop #119
> https://github.com/grindylow/ahoy/pull/119

Habe mir jetzt neben der ESP32 OpenDTU auch noch eine ESP8266 Ahoy DTU 
zum Vergleich gebastelt und ich kann bestätigen, dass die 30 Minuten 
Empfangslücke nach WR-Neustart mit der aktuellen Ahoy-Version nicht 
auftreten. Es kommen sofort alle Daten. Spitze!!!

von Dirk (Gast)


Lesenswert?

Hallo ich würde gerne die 0.4.26er bin Version testen. Wie kann ich 
meine aktuelle Version 0.4.25 am besten upgraden ?
Was ist der Unterschied zwischen Firmware und Filesystem Upgrade ?

von Günter H. (gnter_h534)


Lesenswert?

1. Einige Beiträge nach oben scrollen, dort hat Lukas P. heute einen 
Link zur jeweils aktuellen .bin eingestellt.
2. zip-Datei entpacken.
3. Update Firmware durchführen (Wozu Update FileSystem gut sein kann, 
weiß ich auch nicht).

von Dirk Z. (dirk007)


Lesenswert?

Super danke ...

von Joachim (Gast)


Lesenswert?

Moin! Eine kurze Frage bzgl. Verbindungsproblemen: welche 
Minimal(!)voraussetzungen genau gibt es, damit über Funk eine erste 
erfolgreiche Verbindung zum WR hergestellt werden kann? Meine 
Vermutungen:
1. Mindestens ein Panel muss angeschlossen sein und Strom produzieren.
2. Der WR muss auch an AC angeschlossen sein (sonst blinkt die LED wohl 
im Sekundentakt rot auf)
3. Laut Forenberichten muss der WR wohl zunächst 30 Minuten laufen - ist 
das wirklich so?

von Olli (Gast)


Lesenswert?

Joachim schrieb:
> 1. Mindestens ein Panel muss angeschlossen sein und Strom produzieren.
> 2. Der WR muss auch an AC angeschlossen sein (sonst blinkt die LED wohl
> im Sekundentakt rot auf)
> 3. Laut Forenberichten muss der WR wohl zunächst 30 Minuten laufen - ist
> das wirklich so?

Nur 1. muss gegeben sein.

von Joachim (Gast)


Lesenswert?

Danke! Ich frage deshalb, weil er bei mir bisher keine Verbindung 
herstellen kann, es ist ein 300W-Modul dran und die LED blinkt im 
Sekundentakt rot (da noch kein AC angeschlossen ist). Die 30 Min. sind 
bald rum, ich fürchte nur, dass sich nicht viel ändern wird. Die SN ist 
korrekt eingetragen, zwischen Antenne und WR liegen nur 3m. Die 
Meldungen sind bisher nicht vielversprechend:
I: Requesting Inverter SN 11417201xxxx
-> I: Transmit 27 | ...
Inverter #0 I: no Payload received! (retransmits: 5)
....
Hab das Modul im Setup sowohl mal unter Port 1 als auch unter Port 2 
ausprobiert, die Meldungen sind leider die gleichen.

von Joachim (Gast)


Angehängte Dateien:

Lesenswert?

Das hier sind die Meldungen (Anhang)

von Tobi D. (tobidd)


Lesenswert?

Joachim schrieb:
> Das hier sind die Meldungen (Anhang)

Probier mal sowohl hardwaremässig als auch Softwaremässig d3 und d4 zu 
tauschen, bei mir gehts damit, siehe

https://github.com/grindylow/ahoy/issues/36

von Joachim (Gast)


Lesenswert?

Danke für den Tipp! Auf diese Idee wäre ich natürlich nicht gekommen. 
Ich schau mal, wie ich das umsetzen kann, dummerweise ist das alles 
bereits gut verlötet (angepasste Platine). Aber trotzdem. Wenn ich die 
PINs nur softwareseitig vertausche, bleibt zumindest die Startmeldung 
zur Antenne identisch:
17:04:25.532 -> I: RF24 Amp Pwr: RF24_PA_MIN
17:04:25.532 -> I: Radio Config:
17:04:25.532 -> SPI Frequency    = 1 Mhz
17:04:25.579 -> Channel      = 3 (~ 2403 MHz)
17:04:25.579 -> RF Data Rate    = 250 KBPS
17:04:25.579 -> RF Power Amplifier  = PA_MIN
17:04:25.579 -> RF Low Noise Amplifier  = Enabled
17:04:25.579 -> CRC Length    = 16 bits
17:04:25.579 -> Address Length    = 5 bytes
17:04:25.579 -> Static Payload Length  = 32 bytes
17:04:25.579 -> Auto Retry Delay  = 250 microseconds
17:04:25.579 -> Auto Retry Attempts  = 0 maximum
17:04:25.579 -> Packets lost on
17:04:25.579 ->     current channel  = 0
17:04:25.579 -> Retry attempts made for
17:04:25.579 ->     last transmission  = 15
17:04:25.579 -> Multicast    = Disabled
17:04:25.579 -> Custom ACK Payload  = Disabled
17:04:25.579 -> Dynamic Payloads  = Enabled
17:04:25.579 -> Auto Acknowledgment  = Disabled
17:04:25.579 -> Primary Mode    = RX
17:04:25.579 -> TX address    = 0xdeadbeef01
17:04:25.579 -> pipe 0 (closed) bound  = 0xdeadbeef01
17:04:25.626 -> pipe 1 ( open ) bound  = 0x1234567801
17:04:25.626 -> pipe 2 (closed) bound  = 0xc3
17:04:25.626 -> pipe 3 (closed) bound  = 0xc4
17:04:25.626 -> pipe 4 (closed) bound  = 0xc5
17:04:25.626 -> pipe 5 (closed) bound  = 0xc6

Falls es keine anderen Tipps gibt, werde ich nachher wohl nochmal den 
Kolben in die Hand nehmen müssen :-(

von Olli (Gast)


Lesenswert?

Mit welcher Software flasht Ihr die OpenDTU bin Files auf den ESP32?

von Steffen D. (steffen_d)


Lesenswert?

Olli schrieb:
> Mit welcher Software flasht Ihr die OpenDTU bin Files auf den
> ESP32?

Mit Visual Studio Code + PlatformIO

von Joachim (Gast)


Lesenswert?

OK, ich werde wohl eine neue Antenne bestellen müssen, das Entfernen hat 
sie wohl irgendwie nicht überlebt, obwohl die Kontakte eigentlich 
funktionieren. Ich werde sowas zukünftig besser nicht mehr löten, bevor 
alles auf dem Breadboard läuft.

von Giuseppe M. (drdigital)


Lesenswert?

Ziyat T. schrieb:
> 0xc006 on/off wr1
> 0xc007 limit wr1
Hallo,
ich habe es heute mal probiert aber irgendwie hat es nicht richtig 
geklappt.
Könntest Du mir mal bitte ein Beispiel geben welchen Wert man senden 
muss?
Also ich meine muss man Dezimal 2-100 senden?
Oder muss man einen Wert z.B. 400 für 400 Watt senden?
Ich habe mehrere Werte an den Wechselrichter gesendet, irgendwann hat er 
nichts mehr produziert, aber eine Limitierung auf einen bestimmten Wert 
ist mir nicht gelungen.

von Eike (Gast)


Lesenswert?

Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen? Also 
opendtu und ahoi?

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

@Eike
wäre vielleicht toll, wenn du einmal die Wikis von OpenDTU und Ahoy 
lesen würdest.
Ein bisschen selber informieren und denken kann nicht schaden.

von Eike (Gast)


Lesenswert?

Ne geile FAQ wäre auch toll. Gibt es aber auch nicht.

von Steffen D. (steffen_d)


Lesenswert?

Eike schrieb:
> Ne geile FAQ wäre auch toll. Gibt es aber auch nicht.

Vielleicht mal ein wenig mitlesen .....
https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Eigentlich ist alles gut beschrieben.
Wenn jemand fragt, o man für OpenDTU und Ahoy die selbe Hardware 
verwenden kann, da liegt es wieder einmal beim Fragesteller.
Hatten wir schon einmal. Da hast ja gleich OpenDTU schlecht geredet, nur 
weil es nicht funktioniert.
Zitat von dir am 02.08 "Das opendtu ist Mist"

Wie so oft, liegt der Fehler vor dir, wenn du in den Spiegel siehst.
Da machen sich andere die Mühe und entwickeln so etwas geniales, und 
dann kommen solche wie du daher, und sagen das ist "Mist"

von Ha F. (harry_f)


Lesenswert?

Eike schrieb:
> Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen?
> Also
> opendtu und ahoi?
Hier nachzulesen:

https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-hardware-brauche-ich-f%C3%BCr-die-verschiedenen-software-projekte

von Hermann (Gast)


Lesenswert?

Rene M. schrieb:
> Eigentlich ist alles gut beschrieben.

Schenkelklopfer, Zitat aus der achso geilen FAQ:

Q: "Reicht ein ESP8266 mit 1MB oder muss es unbedingt ein ESP8266 mit 
4MB sein?"

A: NIX

Q: Muß es ein nrf24L01+ sein oder funktioniert auch ein nrf24L01 (ohne 
Plus)?

A: NIX

Q: Ich will mir eines bestellen, wo gibt es eine sichere Quelle?

A: NIX

Q: Wie ist das Gerät mit Spannung zu versorgen

A: "Stabile Stromversorgung ..." -> Schenkelklopfer, warum schreibt man 
hier nicht "aus der Steckdose"?

Q: Wo und wie kommt man direkt ohne Entwicklungsumgebung an die .bin?

A: NIX, ein Link wäre wohl zu anstrengend ;)

Q: o liegen die verschiedenen Versionen der .bin´s?

A: NIX, ein Link wäre wohl zu anstrengend ;)

usw. usf.

Das sollte umgehend umbenannt werden in 
FAQ-Frequently-Asked-Questions-without-helpful-answers

Hochachtung vor der Programmierleistung und dem Reverse-Engineering, 
aber Doku? Katastrophe!

Und so zu tun als wäre die superduper und hilfreich (wie die zahlreichen 
Links zur "FAQ" hier im Endlospost zeigen) kann man nicht 
unwidersprochen stehen lassen ;)

von Ha F. (harry_f)


Lesenswert?

Naja die FAQ gibt es erst seit wenigen Wochen /einigen Tagen.

Ich denke der Ersteller ist dankbar für jeden hilfreichen Text den er 
bekommt um ihn einzufügen.

Hermann schrieb:
> A: "Stabile Stromversorgung ..." -> Schenkelklopfer, warum schreibt man
> hier nicht "aus der Steckdose"?

Mit der Antwort "aus der Steckdose" kann auch niemand etwas anfangen. 
Hier geht es genau darum, dass das Netzteil entsprechend geeignet sein 
muss um den ESP mit Strom zu versorgen und zwar auch dann wenn er mal 
kurzzeitige etwas mehr zieht (WLAN etc). Ein Netzteil mit 1A kann 
funktionieren, kann aber auch dafür sorgen, dass es Neustarts gibt.

von Joni N. (hal_9000)


Lesenswert?

Mein OpenDTU läuft absolut stabil und fehlerfrei seit dem ich es 
angesteckt habe, seit 9 Tagen.

WR steht etwa 5 Meter vom ESP32 entfernt, es ist eine dicke Betondecke + 
Kies dazwischen.

PA Level: Maximum (0 dBm)

Komponenten:
https://www.amazon.de/gp/product/B071P98VTG
https://www.amazon.de/gp/product/B07VQ838KT
https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz

Strom bekomme ich so (direkt von einem der USB-Anschlüsse):
https://www.amazon.de/gp/product/B096BFKWSK


Ein herzliches Dankeschön an alle Entwickler!

: Bearbeitet durch User
von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Hermann schrieb:

> Und so zu tun als wäre die superduper und hilfreich (wie die zahlreichen
> Links zur "FAQ" hier im Endlospost zeigen) kann man nicht
> unwidersprochen stehen lassen ;)


Würde man einfach nur selbst ein bisschen Hirn einschalten und sich die 
Mühe machen etwas selber zu informieren, wäre das kein Problem.
Aber es wird immer Leute geben, die alles vorgekaut brauchen, weil sie 
es selbst nicht schaffen, etwas zu googeln.

Ist aber noch immer kein Grund, irgendetwas schlecht zu mache wie der 
User Eike, den ich zukünftig sicher ignorieren werde

von Eike (Gast)


Lesenswert?

Eigentlich ist es ganz einfach...entweder es sollen nur Hardcore User 
nutzen die wissen wie man Datenströme mitloesst und was was ich alles 
oder eben auch normalos.

Normalos. Rauchen eben Amazon links und einfache antworten. Müsst ihr 
euch entscheiden was ihr wollt oder was das für ein prot werden soll so 
einfach ist das.


Eike

von FrankW (Gast)


Lesenswert?

@Eike und Hermann

kauf doch einfach das fertige kommerzielle Gerät.
Da musst Du nicht mitdenken und bekommst für Dein Geld ein (hoffentlich) 
fertig entwickeltes und marktreifes Produkt - gleich mit Cloud. Hier 
dreht es sich um ein Projekt von freiwilligen in der Entwicklungsphase. 
Wenn beim kommerziellen Produkt etwas nicht gleich geht, kannst Du gerne 
dem Hersteller schreiben sein Produkt wäre "Mist".

So ist das einfach im Leben. Wer nur Ansprüche hat ohne mithelfen und 
ausprobieren zu wollen, der muss halt einfach ein fertiges Produkt 
kaufen und die Entwicklungsarbeit, Marketing, Vertrieb, Gewinn usw. des 
Herstellers bezahlen.

von Bibo (Gast)


Lesenswert?

Hallo zusammen und vielen Dank für eure tolle Leitung bisher.

Ich werde in den nächsten Tagen meinen HM400 aktivieren und hab vorab 
schon mal einen ESP8266 (Wemos D1 mini) + NRF24L01(plus) 
zusammengesteckt und mit der Version 0.4.26 geflasht.

Als Funkmodul hab ich dieses verwendet:
https://www.amazon.de/WayinTop-NRF24L01-Transceiver-Regulator-kompatibel/dp/B07PBBC4H9

Auf dem Chip steht nrf24l01+. Ich hab das Modul über den mitgelieferten 
Adapter an den Wemos angeschlossen. Die Stromversorgung des Adapters 
kommt vom 5V PIN des Wemos.

Nach dem Flashen konnte ich wunderbar auf die Weboberfläche zugreifen 
und alle Einstellungen vornehmen und alles sieht normal aus. Ich bekomme 
natürlich noch keine Daten, da der Wechselrichter noch nicht in Betrieb 
ist.

Was ich aber feststellen musste ist, dass der ESP Chip sehr heiss wird.

Kennt jemand das Verhalten?
Woran kann das liegen?

Viele Gruße,
Bibo

von Ralla66 (Gast)


Lesenswert?

Es wäre mal nett wenn jemand erklärt wie man die Commandos für die 
Leistungsbegrenzung über einen ESP8266 zum NRF sendet.
Geschieht dies per Mqtt oder funktioniert dies per Terminal Programm wie 
z.B. Hterm.
Also Command per Hterm TX in hex an ESP senden der dies zum NRF sendet 
oder ist das in der HoyDTUsimu nicht mit enthalten ?

von Klaus H. (klahi)


Lesenswert?

Solche Projekte leben vom konstruktiven Mitmachen. Da sind Kommentare 
wie "Mist" oder "NIX, ein Link wäre wohl zu anstrengend ;)" nicht 
hilfreich.

Es gibt da auf Youtube ein Video mit dem Titel 
"Hoymiles-Mikrowechselrichter – DTU für Monitoring einrichten – Tipps 
und Tricks" . Ich war erstaunt wie viele Einschränkungen und 
Fehlfunktionen bei der originalen DTU von Hoymiles erwähnt wurden. Da 
scheint im Kommunikationsverfahren zwischen DTU und Wechselrichter mehr 
als ein bekannter Bug eingebaut zu sein. Open Source Reverse-Engineering 
Projekte diskutieren wenigstens darüber und lösen. Die Hersteller 
wechseln im besten Fall das Produkt aus.

Hochachtung vor allen, die sich bisher eingebracht haben.

von Peter L. (leliep)


Lesenswert?

Hermann schrieb:
> …
> Das sollte umgehend umbenannt werden in
> FAQ-Frequently-Asked-Questions-without-helpful-answers
>
> Hochachtung vor der Programmierleistung und dem Reverse-Engineering,
> aber Doku? Katastrophe!
> …
Du weisst aber, dass es sich hier um ein gemeinschaftlich entwickeltes 
Projekt handelt, bei dem jeder herzlich eingeladen ist, einen Beitrag zu 
leisten, um das Gesamtergebnis zu verbessern?

Also: finde die Lücken in der Doku, arbeite Dich durch den ganzen 
Diskussions-Thread und fülle die Lücken mit Deinem erarbeiteten Wissen 
auf. Hat den Effekt, dass Du danach schlauer bist und die, die nach Dir 
Informationen suchen, sie auch mühelos finden.

Und wenn Du erwartest, ein fertiges Produkt zu erhalten, dann schau Dich 
auf dem kommerziellen Markt um. Vielen Dank.

Und ein herzliches „Danke“ an alle hier, die ihre Zeit, ihr Gehinschmalz 
und ihre Arbeit investieren! -pl

von Dirk Z. (dirk007)


Lesenswert?

Hallo zusammen, ich find euer Projekt und die Leistung hier echt super. 
Ich würde euch gerne beim ausfüllen der Faqs (soweit es mir möglich ist) 
unterstützen bzw. auch gerne mal ne Anleitung schreiben. Wie kann man 
das organisieren ?

von Günter H. (gnter_h534)


Lesenswert?

Bibo schrieb:
> Was ich aber feststellen musste ist, dass der ESP Chip sehr heiss wird.

Was heißt denn "sehr heiß"? Bei den ESP8266 auf meinem Wemos D1 mini ist 
im Dauerbetrieb eine "leichte Erwärmung" feststellbar.

Kannst du die Stromaufnahme messen? Bei mir mit Netzteil (also an 230 V) 
gemessen 0,6 W.

von HM (Gast)


Lesenswert?

Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade 
eingestellt ist, da ich das für die EVU brauche.

von Bibo (Gast)


Lesenswert?

Günter H. schrieb:
> Was heißt denn "sehr heiß"? Bei den ESP8266 auf meinem Wemos D1 mini ist
> im Dauerbetrieb eine "leichte Erwärmung" feststellbar.

Wenn ich mit meinem Finger ;) die Temperatur messe halte ich es nicht 
lange aus. Ich schätze > 50 °C.

Günter H. schrieb:
> Kannst du die Stromaufnahme messen? Bei mir mit Netzteil (also an 230 V)
> gemessen 0,6 W.

Den Strom werde ich heute Abend mal messen.

von Daniel M. (daniel_m821)


Lesenswert?

Dirk Z. schrieb:
> Hallo zusammen, ich find euer Projekt und die Leistung hier echt super.
> Ich würde euch gerne beim ausfüllen der Faqs (soweit es mir möglich ist)
> unterstützen bzw. auch gerne mal ne Anleitung schreiben. Wie kann man
> das organisieren ?

Hallo Dirk,

am einfachsten ist es aktuell, wenn du auf den Discord kommst:
https://discord.gg/6Y4dAs2v

Da können wir die FAQ übersichtlicher erweitern und es ist allen dabei 
geholfen.

Danke für dein Angebot zum Mitmachen :)

lg

von Daniel M. (daniel_m821)


Lesenswert?

Liebe Leute,

die Diskussionskultur hier ist vereinzelt unter aller Sau.
Dieses Projekt lebt von konstruktiver Kritik, Verbesserungsvorschlägen 
und dem Mitwirken von Entwicklern, die das ganze hier in ihrer Freizeit 
machen.

Genauso lebt dieses Projekt von Leuten, die Hardware kaufen (zum Teil 
mehrere 100€), öffnen, auf Garantie verzichten und am Ende Daten 
mitloggen und Bereitstellen, aufbereiten, auswerten und das auch mal 
nachts, in der Freizeit.

Das Projekt hier ist weit voran geschritten, weil viele sich helfen, 
gute Fragen stellen oder ordentlich beantworten.
Es geht beim Basteln und Bauen nicht ohne Hirnschmalz.

Wer also der Meinung ist, hier irgendwas Steckerfertig zu kriegen und 
rummotzen kann, weil irgendwas nicht geht, ist falsch hier.
Geht auf ne Webseite, kauft euch vom Hersteller einen Datenlogger und 
schaltet euer Hirn aus. Danke.

Wer jedoch ordentlich Fragen stellt, Diskussionsettikette hat und sich 
selbst erstmal informiert, ist herzlichst willkommen und dem wird auch 
geholfen.

Beiträge wie "ist Kacke" oder "Nix" in den FAQ sind schlicht fehl am 
Platz.

Es gibt wenig Leute hier, die ein Problem damit haben, wenn die eine 
oder andere Frage doppelt oder 3fach kommt, vor allem wenn dazwischen 
Tage oder teils Wochen liegen, aber eine Suchfunktion nutzen ist keine 
Raketenwissenschaft. Das Ding zwischen den Ohren ist nicht zum Haare 
schneiden da sondern zum Denken und Mitdenken.

Stellt eure Fragen so, dass man die beantworten kann und habt etwas 
Geduld. Manche Antwort braucht eben 1-2 Tage.
Nehmt jedoch euren Undank, geht was fertiges kaufen und verstopft hier 
nicht die Pipe mit eurem sinnfreien Gesabbel und Gemotze.

Danke.

von Daniel M. (daniel_m821)


Lesenswert?

HM schrieb:
> Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade
> eingestellt ist, da ich das für die EVU brauche.

Hallo HM,

das Powerlimit befindet sich derzeit auf einigen Forks in der Testphase.
Für OpenDTU ist dieses noch nicht verfügbar.

Eine Option um das auszulesen gibt es nicht. Ich würde beim EVU mal 
nachfragen, ob die sich sicher sind, was die da tun. Mir scheint, da ist 
eine gehörige Portion Willkür und Verhinderungstaktik dabei.

So sinnbefreit es auch ist, hier wäre vllt für dich die Option der 
DTU-Pro mit CHiNT Zähler und 0-Einspeisung der richtige Weg. Kostet zwar 
ca. 300€ plus Elektriker, ist aber sicher leichter, als den 
Netzbetreiber zu wechseln, der mindestens fragwürdige Anforderungen an 
ein "Balkonkraftwerk" hat.

Das, was dein EVU fordert, kann weder AHOY noch OpenDTU leisten 
(aktuell).
Zumal einerseits die 70% jederzeit variabel änderbar und nicht verplompt 
sind und andererseits ab 2023 die 70% eh wegfallen sollen, auch für 
Bestandsanlagen. In wie weit das schon durch ist, kann ich gerade nicht 
sagen.

lg

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Eine Art Nulleinspeisung mit Werten von MQTT wäre das übertrüber.
Ich habe ja schon meine Werte vom Smartmeter per MQTT.
Bin schon gespannt auf die Leistungsanpassung.

Übernimmt und setzt der Wechselrichter diese auch sofort um, oder dauert 
das etwas, bis die Leistung reduziert wird?

von Daniel M. (daniel_m821)


Lesenswert?

Rene M. schrieb:
> Eine Art Nulleinspeisung mit Werten von MQTT wäre das übertrüber.
> Ich habe ja schon meine Werte vom Smartmeter per MQTT.
> Bin schon gespannt auf die Leistungsanpassung.
>
> Übernimmt und setzt der Wechselrichter diese auch sofort um, oder dauert
> das etwas, bis die Leistung reduziert wird?

Im Test laufen die praktisch sofort auf das neue Limit, wir wissen nur 
noch nicht, wie gesund das ganze ist.

Die DTU Pro setzt auch das Limit und die WR reagieren sofort.

Welchen Smartmeter hast du im Einsatz?

lg

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Netzbetreiber hat bei mir einen Kaifa installiert (bin aus Österreich).

Lasse mir sämtliche Smartmeter Werte sekündlich ins Iobroker senden.

Ich denke, wenn Hoymiles die Nulleinspeisung, sprich Leistungsbegrenzung 
von sich aus anbietet, sollte es ja nicht unbedingt ungesund für den 
Wechselrichter sein

von Ha F. (harry_f)


Lesenswert?

Also ich hätte auch meinen Momentanverbrauch vom Haus per MQTT zur 
Verfügung.

IoBroker + Adapter Smartmeter + IR-Lesekopf + "Moderner Zähler"

Holley DTZ541-ZDBA  im Bayernwerk Netz.

Liefert unter anderem (ca. alle 5 Sekunden) unter den Datenpunkten:

16.7.0 Momentanwert Gesamtwirkleistung  (Total)  (saldierend)    Bsp. 
250W

2.8.0 Zählerstand 1 Summe Wirkarbeit (Abgabe)                    Bsp 60 
kWh (an der Netzbetreiber verschenkt)


1.8.1 Bezug Tarif 1 (erregt)
1.8.2 Bezug Tarif 2
2.8.0 Lieferung

von Daniel M. (daniel_m821)


Lesenswert?

Rene M. schrieb:
> Netzbetreiber hat bei mir einen Kaifa installiert (bin aus Österreich).

Da bin ich jetzt nicht so drin, was das ist.

> Lasse mir sämtliche Smartmeter Werte sekündlich ins Iobroker senden.

Ok :)

> Ich denke, wenn Hoymiles die Nulleinspeisung, sprich Leistungsbegrenzung
> von sich aus anbietet, sollte es ja nicht unbedingt ungesund für den
> Wechselrichter sein

Das kommt drauf an, wenn der zu schnell zu viel nachregeln muss, wirds 
schon interessant, Elektronik kann viel leisten, aber es gibt eben 
Grenzen.

Komm doch gerne im Discord vorbei und mach bei den Tests mit.

lg

von Jörg R. (rejoe2)


Lesenswert?

Hallo zusammen,

vorab mal Hut ab, was ihr da gezaubert habt!

Hätte da auch noch ein paar Fragen und Anmerkungen...

Habe einen MI-600 und die Ahoy-0.4.26 auf einem D1-Mini-Klon am laufen. 
Der WR scheint ein "echter" MI zu sein. Dementspechend macht der zwar 
fleißig Anfragen, bekommt aber derzeit (= mit dieser firmware-Version) 
keine Rückmeldungen.
Soweit ich das jetzt verstanden habe, liegt das schlicht daran, dass die 
MI-Varianten noch nicht funktionieren/eingepflegt sind. Kann ich da 
irgendwie helfen bzw. wie nähere ich mich dieser Sache?
(ich bin Hobbyist und kann mich zwar in den C-Code orientieren, aber die 
ganzen Auswertungen sind oberhalb meiner Fähigkeiten...)

Auf ESP32 umzuswitchen bringt im Hinblick auf die MI-Hardware derzeit 
auch nichts, korrekt?

Aufgrund meiner MySensors- und MiLight-Hub-Erfahrungen gehe ich auch 
davon aus, dass die Hardware an sich funktional ist - die nRF-Boards 
stammen aus MySensors-Nodes, die zwischenzeitlich auf RS485 umgestellt 
wurden, es ist eine Hilfsplatine zwischengeschaltet, die einen 
Spannungswandler und ein paar Kondensatoren mitbringt, und an der 
seriellen Schnittstelle sieht zumindest das Senden auch ok aus.
Oder ist das ggf. ein Trugschluss?

Was Doku angeht: Abgesehen von D2/D3 und der Verwendung der IRQ-Line 
entspricht der Aufbau recht genau dem, was insbesondere bei MySensors 
schon lange erprobt ist - da finden sich dann auch viele Tipps betr. der 
Spannungsversorgung des nRF, Fakes/guten Shops und ggf. sogar Platinen 
und 3D-Druck-Daten. Ich selbst habe noch das Glück gehabt, einige nRF 
"vor der großen Fake-Flut" geordert zu haben, die funktionierten zum 
großen Teil (aber auch damals schon nicht alle). Wenn ich heute 
einkaufen müßte: nur noch die "geschieldeten" mit pa+nla (3.100m oder 
so), da scheint das Risiko für fakes nicht ganz so hoch zu sein...

Wünsche bzw. Anregungen hätte ich dann auch noch:
- sowas wie ein "LWT" wäre klasse (vielleicht komme ich dazu, da was 
beizutragen)
- die jeweils zusammengehörenden Datensätze (z.B. pro Eingang?) in einen 
JSON zu verpacken wäre super - das würde weniger Last auf dem von mir 
eingesetzten FHEM erzeugen.
Vielleicht hat ja jemand Lust, das (als Option?) umzusetzen...

Grüße jedenfalls, J.

von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Hallo zusammen,
>
> vorab mal Hut ab, was ihr da gezaubert habt!
>
> Hätte da auch noch ein paar Fragen und Anmerkungen...
>
> Habe einen MI-600 und die Ahoy-0.4.26 auf einem D1-Mini-Klon am laufen.
> Der WR scheint ein "echter" MI zu sein. Dementspechend macht der zwar
> fleißig Anfragen, bekommt aber derzeit (= mit dieser firmware-Version)
> keine Rückmeldungen.

habe eine esp8266 version für MI veröffentlicht, weiter oben

von Ziyat T. (toe_c)


Lesenswert?

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> 0xc006 on/off wr1
>> 0xc007 limit wr1
> Hallo,
> ich habe es heute mal probiert aber irgendwie hat es nicht richtig
> geklappt.
> Könntest Du mir mal bitte ein Beispiel geben welchen Wert man senden
> muss?
> Also ich meine muss man Dezimal 2-100 senden?
> Oder muss man einen Wert z.B. 400 für 400 Watt senden?
> Ich habe mehrere Werte an den Wechselrichter gesendet, irgendwann hat er
> nichts mehr produziert, aber eine Limitierung auf einen bestimmten Wert
> ist mir nicht gelungen.

in 0xc007 (uint8)2 bis 100 schreiben, prozent der angeschlossene 
nennleistung
z.B. 1000W angeschlossen, wenn du 500W willst dann ist der wert 50

edit:
> Ich habe mehrere Werte an den Wechselrichter gesendet
an den wr? ne, du schickst an die dtu-pro über modbus, oder?

: Bearbeitet durch User
von Stefan T. (isnoahoy)


Lesenswert?

Hallo Joerg,
ich glaube Ziyat T. hatte sich mit dem MI-Protokoll beschäftigt und den 
Code für seinen MI-1500 angepaßt. Analog dazu geht es auch für 
MI-600-800 und die kleine MI-300-500. Beim MI-250 bin ich mir nicht 
sicher, was der tatsächlich verwendet, könnte laut DTU-Pro Source Code 
noch ein Spezialfall sein, da sozusagen der Urschleim der Hoymiles WR.
Such doch mal ob er den Code auch hochgeladen hat oder vielleicht in 
seinem github Repo hinterlegt hat, seit das mit dem ActivePowerLimit 
Kommando bei ihm geklappt hat =^D.

: Bearbeitet durch User
von Giuseppe M. (drdigital)



Lesenswert?

Ziyat T. schrieb:
> an den wr? ne, du schickst an die dtu-pro über modbus, oder?

Danke für die Antwort.
Ich habe an die DTU-Pro gesendet.
Per Modbus TCP also an die IP-Adresse des DTU-Pro über Port 502.
Vielleicht habe ich aber auch dort noch einen Fehler bei den RS485 
Einstellungen.
Wie sind diese bei Dir eingestellt?
Einspeisesteuerung oder Fernbedienung?

: Bearbeitet durch User
von Jörg R. (rejoe2)


Lesenswert?

Ziyat T. schrieb:
> habe eine esp8266 version für MI veröffentlicht, weiter oben

Danke, auch an Stefan T..
Hoffe, nichts neueres übersehen zu haben, das scheint die zip vom 13.07. 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") zu sein. Habe die 
Daten zum MQTT-Server, Wifi und der Seriennummer (meine beginnt mit 
1041) angepaßt, aber leider will die Arduino-IDE nicht durchlaufen 
(1.8.19). Wenn ich die erweiterten debug-Ausgaben richtig deute, beißt 
sich da was. Vielleicht kann jemand mit dem Schnipsel was anfangen, ich 
vermute, dass die ESP-libs jetzt "zu neu" sind:
1
In file included from /home/joerg/Arduino/libraries/ESP8266WiFi/src/ESP8266WiFi.h:39,
2
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/wifi.h:10,
3
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/mqtt.h:3,
4
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:21:
5
/home/joerg/Arduino/libraries/ESP8266WiFi/src/WiFiClient.h:89:10: error: conflicting return type specified for 'virtual size_t WiFiClient::availableForWrite()'
6
   89 |   size_t availableForWrite();
7
      |          ^~~~~~~~~~~~~~~~~
8
In file included from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Stream.h:27,
9
                 from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/HardwareSerial.h:32,
10
                 from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Arduino.h:288,
11
                 from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:11:
12
/home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Print.h:80:21: note: overridden function is 'virtual int Print::availableForWrite()'
13
   80 |         virtual int availableForWrite() { return 0; }
14
      |                     ^~~~~~~~~~~~~~~~~
Werde jetzt erst mal was anderes machen...

Danke aber auf alle Fälle bis hierhin!

von Ziyat T. (toe_c)


Lesenswert?

Giuseppe M. schrieb:
> Ziyat T. schrieb:
>> an den wr? ne, du schickst an die dtu-pro über modbus, oder?
>
> Danke für die Antwort.
> Ich habe an die DTU-Pro gesendet.
> Per Modbus TCP also an die IP-Adresse des DTU-Pro über Port 502.
> Vielleicht habe ich aber auch dort noch einen Fehler bei den RS485
> Einstellungen.
> Wie sind diese bei Dir eingestellt?
> Einspeisesteuerung oder Fernbedienung?

es wird als fernbedienung eingestellt, damit sagst du der dtu was sie 
machen soll

da ich auch einen DTSU (smartmeter) abfrage mein modbus laeuft nur über 
rs485

hatte auch mal mit tcp über port 502 verbunden, no problem

von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Ziyat T. schrieb:
>> habe eine esp8266 version für MI veröffentlicht, weiter oben
>
>>>>>>>>>>
> /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:11:
> /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp 
8266/Print.h:80:21:
> note: overridden function is 'virtual int Print::availableForWrite()'
>    80 |         virtual int availableForWrite() { return 0; }
>       |                     ^~~~~~~~~~~~~~~~~[/code]
> Werde jetzt erst mal was anderes machen...
>
> Danke aber auf alle Fälle bis hierhin!

- bei mir laeuft mit arduino-ide 2.0.0-rc6 und 1.8.19, also die esp libs 
sollten bei mir die neueste sein.
- additional board manager url: 
https://arduino.esp8266.com/stable/package_esp8266com_index.json
- selected board: LOLIN(WEMOS) D1 R2 & mini
dann müsste es beim compiler durchkommen

edit:
# ESP8266 platform
name=ESP8266 Boards (3.0.2)
version=3.0.2

: Bearbeitet durch User
von ohnePlan (Gast)


Lesenswert?

Hallo, hat jemand schon mal vom ESP8266 oder ESP32 eine Verbindung per 
USB auf ein Samsung Smartphone realisiert (per USB Kabel natürlich) um 
dort die Ertragsdaten abzulegen. Also z.B. pro Tag eine Datei und z.B. 
alle 10 Min. einen Datensatz mit den PV Daten ans Ende der Datei anfügen 
(append) ?  Hab hier nämlich eines herumliegen, das so noch eine 
sinnvolle Verwenung hätte.

von Ziyat T. (toe_c)


Lesenswert?

@Jörg R, @Stefan T.

Bin als "keineahnungvongithub" auch auf den github Zug gesprungen.

QUICK&DIRTY  DTUsim für MI
---------------------------
https://github.com/Ziyatoe/DTUsimMI

von Jörg R. (rejoe2)


Lesenswert?

Ziyat T. schrieb:
> - selected board: LOLIN(WEMOS) D1 R2 & mini
> dann müsste es beim compiler durchkommen
>
> edit:
> # ESP8266 platform
> name=ESP8266 Boards (3.0.2)
> version=3.0.2

OK, DANKE!

Problem saß (zum Teil) vor dem Bildschirm... Meine Arduino-IDE hat schon 
ein paar Versionen hinter sich, und es lagen schlicht noch ein paar 
betagte Versionen von diversen libs im "Arduino"-Folder. Nachdem die da 
gelöscht waren, lief es durch.

Was jetzt aber nicht klappen will, ist der connect zum MQTT-Broker. Der 
ESP schreibt in der seriellen Konsole unglaublich viele Zeichen in den 
Versuch rein, die Subscriptions anzumelden (?), und Werte zeigt er auch 
per Web-Interface bisher keine an. Jetzt lasse ich den mal die 
"verdächtigen 30 Minuten" laufen, vielleicht wird es bis dahin dann 
was...

Als MQTT-Server habe ich es sowohl mit dem in FHEM integrierten 
MQTT2_SERVER versucht (mit der Ahoy-Version kein Problem) wie auch mit 
einem Mosquitto (2.0, anonyme Anmeldung ist erlaubt).

Ziyat T. schrieb:
> @Jörg R, @Stefan T.
>
> Bin als "keineahnungvongithub" auch auf den github Zug gesprungen.
>
> QUICK&DIRTY  DTUsim für MI
> ---------------------------
> https://github.com/Ziyatoe/DTUsimMI

THX, hab's direkt geklont. Bin auch nicht wirklich firm mit github, 
obwohl schon "ewig" dabei...

von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Ziyat T. schrieb:
>> - selected board: LOLIN(WEMOS) D1 R2 & mini
>> dann müsste es beim compiler durchkommen
>>
>> edit:
>> # ESP8266 platform
>> name=ESP8266 Boards (3.0.2)
>> version=3.0.2
>
> OK, DANKE!
>
> Problem saß (zum Teil) vor dem Bildschirm... Meine Arduino-IDE hat schon
> ein paar Versionen hinter sich, und es lagen schlicht noch ein paar
> betagte Versionen von diversen libs im "Arduino"-Folder. Nachdem die da
> gelöscht waren, lief es durch.
>
> Was jetzt aber nicht klappen will, ist der connect zum MQTT-Broker. Der
> ESP schreibt in der seriellen Konsole unglaublich viele Zeichen in den
> Versuch rein, die Subscriptions anzumelden (?), und Werte zeigt er auch
> per Web-Interface bisher keine an. Jetzt lasse ich den mal die
> "verdächtigen 30 Minuten" laufen, vielleicht wird es bis dahin dann
> was...

- wichtigste ist die wr-adresse im settings.h
- im settings.h mal tx- und rx-debug einschalten, laeuft was?
- wie weit ist der wr? ev. mit pa_level per serial command 
erhöhen/verringern
- auch wenns nix kommt müssten die null werte auf der web-interface 
sichtbar sein
- ich verwende eigenen mqtt-broker auf dem pi

edit:
als serial monitor nicht den arduino-ide-monitor verwenden, direkt im 
terminal mit dem z.B. minicom auf /dev/ttyXXX gehen, ich verwende ascii 
steuerung im terminal

hast du im settings.h wifi on?

: Bearbeitet durch User
von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Daniel M. schrieb:
>
> Komm doch gerne im Discord vorbei und mach bei den Tests mit.
>

Ich bin da keine Hilfe leider. Schaffe es nicht einmal, den 
Wechselrichter per Hand in eine Leistungsbegrenzung zu bringen.
Wollte das mit MQTT machen, aber klappt nicht.

von Volker.B. (Gast)


Lesenswert?

Ich habe gerade auf die 0.5.1 upgedatet.
Bei "Aktive Power Level" hatte ich nichts eingetragen, also stand es bei 
0.
Nun produzierte mein HM600 nichts mehr, auch nicht nachdem ich 600 
eigetragen habe.
Erst nach einem Neustart des WR produziert er wieder.
Ist das so beabsichtigt?

Zusatzfrage, kann (darf) man das Limit auch nach oben setzen?

von Volker.B. (Gast)


Lesenswert?

Volker.B. schrieb:
> Zusatzfrage, kann (darf) man das Limit auch nach oben setzen?

Hat sich erledigt, bringt nichts, habe es getestet.

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Wie funktioniert das mit dieser Leistungsbegrenzung?
ich habe einen HM1500
habe nun  ohne Leistungsbegrenzung 250Watt.
Setze ich die Begrenzung auf 200 Watt habe ich danach plötzlich nur mehr 
um die 100Watt.
Setze ich das ganze wieder auf 1500Watt Begrenzung habe ich wieder die 
250Watt.

von Canon.Fritz (Gast)


Lesenswert?

Volker.B. schrieb:
> Ich habe gerade auf die 0.5.1 upgedatet.

@Volker.B. : Wo hast du die Version 0.5.1 her ?
Ich konnte im Repo noch keine neue Version finden :/

von Jörg R. (rejoe2)


Lesenswert?

Ziyat T. schrieb:
> - wichtigste ist die wr-adresse im settings.h
Die ist eingetragen, das ULL am Ende bleibt ja, oder?

> - auch wenns nix kommt müssten die null werte auf der web-interface
> sichtbar sein
Die sind da, das Ding wird aber als MI-1500 gelabelt. Muss man da für 
MI-600 noch irgendwo anders was umstellen?
> - ich verwende eigenen mqtt-broker auf dem pi
Im Moment habe ich einen ziemlichen "Mesh-up" zwischen deinem 
aktuellsten zip aus github und meinen "Altdaten" und da dann auch noch 
eine Client-Id reingemogelt, die dürfte für den MQTT2_SERVER 
erforderlich sein (Mosquitto ging vorher ja aber auch nicht). In minicom 
sehe ich im Moment trotzdem keine anderen Infos wie den Versuch, sich am 
Server anzumelden, die tx- und rx-debug-Settings habe ich auf "1" 
gesetzt. Das einzige, das sich ändert ist von "LOOP" beim ersten Versuch 
auf "loop" bei allen weiteren.

Man kann den/die Verbindungsversuch/e (?) bei der Variante MQTT2_SERVER 
in FHEM per verbose-Änderung sichtbar machen, das schaut dann so aus:
1
2022.08.06 14:02:47 5: in@192.168.2.59:52662 SUBSCRIBE: (130)(12)(0)(1)(0)(7)ImpExpW(0)
2
2022.08.06 14:02:47 4:   MQTT2_FHEM_Server_192.168.2.59_52662 HOY-DTU SUBSCRIBE
3
2022.08.06 14:02:47 4:   topic:ImpExpW qos:0
4
2022.08.06 14:02:47 5: out@192.168.2.59:52662 SUBACK: (144)(3)(0)(1)(0)
5
2022.08.06 14:02:55 4: Connection closed for MQTT2_FHEM_Server_192.168.2.59_52662: EOF
6
2022.08.06 14:02:55 4: Connection accepted from MQTT2_FHEM_Server_192.168.2.59_58027
7
2022.08.06 14:02:55 5: in@192.168.2.59:58027 CONNECT: (16)(19)(0)(4)MQTT(4)(2)(0)<(0)(7)HOY-DTU
8
2022.08.06 14:02:55 4:   MQTT2_FHEM_Server_192.168.2.59_58027 cid:HOY-DTU CONNECT V:4 keepAlive:60
9
2022.08.06 14:02:55 5: out@192.168.2.59:58027 CONNACK:  (2)(0)(0)
10
2022.08.06 14:02:55 5: in@192.168.2.59:58027 SUBSCRIBE: (130)(12)(0)(1)(0)(7)ImpExpW(0)
11
2022.08.06 14:02:55 4:   MQTT2_FHEM_Server_192.168.2.59_58027 HOY-DTU SUBSCRIBE
12
2022.08.06 14:02:55 4:   topic:ImpExpW qos:0
13
2022.08.06 14:02:55 5: out@192.168.2.59:58027 SUBACK: (144)(3)(0)(1)(0)
Der ESP meldet sich also mit der vergebenen ClientId an, die Verbindung 
wird aber 8 Sek. später wieder zugemacht, k.A. warum.

> - wie weit ist der wr? ev. mit pa_level per serial command
> erhöhen/verringern
PA-Level steht noch auf LOW, aber das sollte nicht das Problem sein, 
sind nur ca. 3m+ein paar Ziegel + Gips... Den nRF habe ich auch nochmal 
hin- und hergetauscht, kein Unterschied.

Werde mir das nochmal in Ruhe ansehen müssen, und dann ausgehend von 
deinem letzten zip erst mal alles der Reihe nach anpassen und versuchen 
zu verstehen, wann da was warum stattfindet.

EDIT: hier noch die sich ständig wiederholenden Zeilen aus minicom:
1
MQTT connected = 0
2
Subscribing to topics.. No MQTT..
3
Attempting to connect to the MQTT broker: <ip-Adresse>

: Bearbeitet durch User
von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Ziyat T. schrieb:
>> - wichtigste ist die wr-adresse im settings.h
> Die ist eingetragen, das ULL am Ende bleibt ja, oder?

ja, richtig

>
>> - auch wenns nix kommt müssten die null werte auf der web-interface
>> sichtbar sein
> Die sind da, das Ding wird aber als MI-1500 gelabelt. Muss man da für
> MI-600 noch irgendwo anders was umstellen?

eigentlich nicht, meine version erwartet 3 PV's aber es sollte trotzdem 
etwas zeigen


> Der ESP meldet sich also mit der vergebenen ClientId an, die Verbindung
> wird aber 8 Sek. später wieder zugemacht, k.A. warum.

lieg das ev am broker? timeout oder so?

>
> EDIT: hier noch die sich ständig wiederholenden Zeilen aus minicom:
>
1
MQTT connected = 0
2
> Subscribing to topics.. No MQTT..
3
> Attempting to connect to the MQTT broker: <ip-Adresse>
4
>

ja, mqtt nicht vorhanden
ich nehme an dass du im mqtt.h diese zeilen angepasst hast
const char MQTTbroker[] = "192.168.1.11";
int        MQTTport     = 1883;


ich würde mal im settings.h wifi = 0 stellen dann schauen was vom wr 
kommt, falls die pv's/wr etwas liefern, dann weiter machen mit wifi, 
mqtt

ach ja noch in der "uint8_t checkAllPV(void)"
die Zeile
if (pvCnt[0]+pvCnt[1]+pvCnt[2]==3)  >> ich habe 3 PV's
anpassen, nehme an du hast 2 PV's
if (pvCnt[0]+pvCnt[1]==2)
muss ich mal diese auch irgendwie inn settings.h zügeln

EDIT:
jetzt ist glaube klar, ich abboniere von meinem mqtt broker den 
"ImpExpW", das ding kommt vom meinem DTSU-Smart meter und du hast das 
ding natürlich nicht. füge in deinem broker irgendwie den "ImpExpW"

: Bearbeitet durch User
von Volker.B. (Gast)


Lesenswert?

Canon.Fritz schrieb:
> @Volker.B. : Wo hast du die Version 0.5.1 her ?
> Ich konnte im Repo noch keine neue Version finden :/



https://github.com/grindylow/ahoy/actions/runs/2808392417

von Jörg R. (rejoe2)


Lesenswert?

Ziyat T. schrieb:
> EDIT:
> jetzt ist glaube klar, ich abboniere von meinem mqtt broker den
> "ImpExpW", das ding kommt vom meinem DTSU-Smart meter und du hast das
> ding natürlich nicht. füge in deinem broker irgendwie den "ImpExpW"
OK, da habe ich jetzt mal ein "600" mit retain-Flag reingeschubst.

Dann ändert sich das auf
1
Subscribing to topics.. ImpExpW Watt 600.0Watt  | All PVs received?:0
2
No MQTT..
Die erscheinen dann auch als "600.00W" im Web-Interface. Soweit so gut, 
aber irgendwie scheint der ESP was anderes/noch mehr zu erwarten?
(Wo finde ich das? Und wie kann man es ggf. abschalten?)

(Eine originale DTU ist nicht vorhanden, ich könnte natürlich den 
Messwert aus dem zwischengeschalteten Aktor da reinschieben.)

Die übrigen Anpassungen mache ich dann bei Gelegenheit.

von Jörg R. (rejoe2)


Lesenswert?

Ziyat T. schrieb:
> ch würde mal im settings.h wifi = 0 stellen dann schauen was vom wr
> kommt, falls die pv's/wr etwas liefern, dann weiter machen mit wifi,
> mqtt
>
> ach ja noch in der "uint8_t checkAllPV(void)"
> die Zeile
> if (pvCnt[0]+pvCnt[1]+pvCnt[2]==3)  >> ich habe 3 PV's
> anpassen, nehme an du hast 2 PV's
> if (pvCnt[0]+pvCnt[1]==2)
> muss ich mal diese auch irgendwie inn settings.h zügeln

Wenn WITHWIFI auf 0 steht (und man dann auch noch die PINS richtig 
anpaßt) kommt dann sowas im "sniffer"-Mode:
1
40 00 1234567801 00A0 14 0  52 56AD1089 2D434553 EA4AE14B1092078000C8EA150C 0                                     
2
CH61 00 1234567801 00D5 1A 2  B4 F5BB6BAA A554A84D 0B2AAA84AD369A9955598AA495283690A95255 0                              
3
CH23 00 1234567801 012A 25 1  55 726ABA6A C9AFAAB5 DAA59D95A5B5F54AB8724ED56D2B0CA551B7654E96000000000000000000 0        
4
CH23 00 1234567801 0075 0E 2  6D 7A896B5D B548BADE 953A2AA884D8D0 0                                                      
5
CH40 00 1234567801 003C 07 2  EDAB15B55256AAAAD5                                                                         
6
CH75 00 1234567801 0095 12 2  69 AB5AA332 759DADDE D5959B612B59295515A515 0
7
CH61 00 1234567801 00AA 15 1  64 59149A29 D4892271 069250AA6D488A3693512C208B56 0
8
CH23 00 1234567801 002A 05 1  D46B65DA95323A 
9
CH61 00 1234567801 0086 10 3  28 B9CE5215 2A2AA462 44D4A4D57294582A56 0
10
CH23 00 1234567801 016A 2D 1  D6 AE255922 5A9A5D6B Ill remain 38
11
CH75 00 1234567801 009C 13 2  FF FB32E6BF AFAC1B29 56677884005090092B048288 0
12
CH75 00 1234567801 0055 0A 2  DA AD2E2B5B AED55492 4E91E5 0
13
CH75 00 1234567801 012D 25 2  AA 9512A1F2 2555755A 6A5451655455EA954552A4D49AA65AA94AAB14C395000000000000000000 0
14
CH61 00 1234567801 01D4 3A 2  99 C9DEBD6C A9F2DAEB Ill remain 51
15
CH40 00 1234567801 002A 05 1  2AA5114954B548 
16
CH61 00 1234567801 00A9 15 0  95 D52A556A 8556DBB5 5BFCD2A5BAAD52A2545695AAD649 0
17
CH3 00 1234567801 0122 24 1  F4 AA45A976 AEAD1494 F55B52C000010895220424415544424B6AA4CA696A0000000000000000 0
18
CH61 00 1234567801 008C 11 2  76 E9AA8246 01949E55 4A48B569245551251349 0
19
CH61 00 1234567801 00DB 1B 1  65 B540929A 8082D355 5A6AF5DEAAD55BB6BF7B576AAED29454644C84AA 0
20
CH40 00 1234567801 015F 2B 3  55 64794E0F 5592AEA5 Ill remain 36
21
CH75 00 1234567801 0098 13 0  C8 8928A92A F6FD5DBE EADFB7D9F35B55D667AA7D5E 0
22
CH75 00 1234567801 0131 26 0  06 294AB34A A45B55B5 5552A76D6955D6A7C2D6A36956A2D56ABB4ABAA5AE00000000000000000000 0
23
CH3 00 1234567801 0031 06 0  D4A825B41A801D52 
24
CH40 00 1234567801 006B 0D 1  24 63509551 5396B58E BD5FFFFFFFFF 0
25
CH23 00 1234567801 01FF 3F 3  FF FDFFFFFF FFFFFFFF Ill remain 56
26
CH40 00 1234567801 01FF 3F 3  FF FFFFFFFF FFD77FED Ill remain 56
27
CH61 00 1234567801 00D9 1B 0  9C 4AB3EB5A 84A2CA9B 2AB15554058322CDEF6EEFFFFDED55BDDFEDA757 0
28
CH40 00 1234567801 0086 10 3  F6 7FFFFFFF FFFFFFFF FFF7FA9551DFF57BFF 0
29
CH40 00 1234567801 014D 29 2  4C A4956A70 A868B557 Ill remain 34
30
CH75 00 1234567801 0155 2A 2  66 DCD957E4 28B2B2FE Ill remain 35
31
CH61 00 1234567801 0129 25 0  8D 5DD5969A D6DB558D 7D8559A7AD54F66EAEAFB75B5ED56E6AD79EAD774D000000EFA9CA010000 0
32
CH40 00 1234567801 0095 12 2  53 D2C00040 00200000 036352D556BAAAA5AA9495 0
33
CH3 00 1234567801 0057 0A 3  DE BAAAAF5D 26CAFD1D 559ABA 6220 B5CA CA72 9E3B 90D8 2C0E B99C D126 84C4 7837 13C0 CA72 B03B B561 CA72 2303 676A 0A2D CA72 28BA C39D 02EA 7EC4 CA72 453A 8D60
34
CH61 00 1234567801 0098 13 0  5A F994F958 B2B5652E B45BFDEFD555B5642B6F6FA9 0
35
CH3 00 1234567801 01AD 35 2  92 8D75AB52 45DB6569 Ill remain 46
36
CH40 00 1234567801 0055 0A 2  5A 54DBFFFE FFFFFFFF FC96AA 0
37
CH75 00 1234567801 00A9 15 0  54 65A55A26 164611AA 289E5474F15AC24DCAAAAAADA52B 0
38
CH61 00 1234567801 00A9 15 0  15 21352A58 A9135A95 6A75281A5F0295356C1A2A0A52D5 0
39
CH75 00 1234567801 0096 12 3  A9 746B7D95 526C6B6E B5B5B12AB1AADAF3BAEADB 0
40
CH40 00 1234567801 00BA 17 1  B5 B6A5A6AE 6B567B4A AA59B55BFDEBFFFEBEFFE92900000800 0
41
CH61 00 1234567801 00B7 16 3  29 ACD6FA65 495420C5 215F52A2BF53F0128294840C1AA733 0
42
CH23 00 1234567801 0022 04 1  E4B25C86AA95 
43
CH61 00 1234567801 0095 12 2  56 A6552D54 5BAAB6F4 DCD3ED1EDAAEF56D74EF77 0
44
CH23 00 1234567801 0055 0A 2  A4 8D491611 94AD8ACB 5A4A34 0
45
CH75 00 1234567801 00AE 15 3  56 AB34D096 E959E66B 48954AF776EACA65AAA96EB7D926 0
46
CH3 00 1234567801 00D6 1A 3  E7 9ED2AE6F DA0AAEDB 0ACBFFFFF5BFFFFFFFDAFDDDB7FF76DFEFFBFF 0
47
CH61 00 1234567801 01D5 3A 2  4A DD7AB6D5 AFEAD56E Ill remain 51
48
CH75 00 1234567801 01FF 3F 3  FD FFFFFFF2 43BAB2AA Ill remain 56
Entweder kommen wir der Sache grade näher, oder das ist irgendwelches 
Zigbee oder WiFi-Gefunke, oder mein MiLight-Hub macht Zicken.... (lt. 
Messgerät kamen grade ca. 308W an).

: Bearbeitet durch User
von Canon.Fritz (Gast)


Lesenswert?

Danke @Volker.B.

von Jörg R. (rejoe2)


Lesenswert?

Jörg R. schrieb:
> Entweder kommen wir der Sache grade näher

Scheint so:
Bisher war "ONLY_RX" eingeschaltet gewesen, was ohne DTU dann wohl 
keinen Sinn macht. Steht jetzt auf "0", mal schauen, ob dann heute noch 
irgendwelche Werte decodiert werden können. Wenn ich das richtig 
verstanden habe, muss man erst mal ca. 30 Minuten warten?

von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Ziyat T. schrieb:
> Wenn WITHWIFI auf 0 steht (und man dann auch noch die PINS richtig
> anpaßt) kommt dann sowas im "sniffer"-Mode:
> [code]
> 40 00 1234567801 00A0 14 0  52 56AD1089 2D434553
> EA4AE14B1092078000C8EA150C 0
> CH61 00 1234567801 00D5 1A 2  B4 F5BB6BAA A554A84D
> 0B2AAA84AD369A9955598AA495283690A95255 0
> CH23 00 1234567801 012A 25 1  55 726ABA6A C9AFAAB5
> DAA59D95A5B5F54AB8724ED56D2B0CA551B7654E96000000000000000000 0
> CH23 00 1234567801 0075 0E 2  6D 7A896B5D B548BADE 953A2AA884D8D0 0
> CH40 00 1234567801 003C 07 2  EDAB15B55256AAAAD5
> CH75 00 1234567801 0095 12 2  69 AB5AA332 759DADDE
>>>>>>
> Entweder kommen wir der Sache grade näher, oder das ist irgendwelches
> Zigbee oder WiFi-Gefunke, oder mein MiLight-Hub macht Zicken.... (lt.
> Messgerät kamen grade ca. 308W an).

das ist wie im sniffer mode, ist SNIFFER = 0? jedenfalls das ist 
airtrash!
oder DEBUG_RCV_DATA ist 1;
kannst du mal DEBUG_TX_DATA = 1 stellen?

du kannst es auch im terminal per command 8/9 stellen:
1: help 2:Status 3:PA_LOW 4:PA_HIGH 5:PA_MAX 6:Sniffer 7:ZeroEx 8:OnlyRX 
9:ShowTX 10:Wifi 11:CRC 20:WRinfo 21:Gongfa

von Jörg R. (rejoe2)


Lesenswert?

Wie geschrieben: Das war im Sniffer-Modus.

DEBUG_RCV_DATA und DEBUG_TX_DATA stehen jetzt noch auf 1, dann sieht das 
aktuell so aus (meine aktuelle Leistung wird jetzt dahin gepublisht):
1
Send... CH40 376010001378563412005C.....send res 0
2
ImpExpW Watt 223.0Watt  | All PVs received?:0
3
Send... CH61 3860100013785634120053.....send res 0
4
Send... CH75 3960100013785634120052.....send res 0
5
Send... CH03 366010001378563412005D.....send res 0
6
Send... CH23 376010001378563412005C.....send res 0
7
Send... CH40 3860100013785634120053.....send res 0
8
Send... CH61 3960100013785634120052.....send res 0
9
Send... CH75 366010001378563412005D.....send res 0
10
Send... CH03 376010001378563412005C.....send res 0
11
Send... CH23 3860100013785634120053.....send res 0
12
Send... CH40 3960100013785634120052.....send res 0
13
Send... CH61 366010001378563412005D.....send res 0
14
Send... CH75 376010001378563412005C.....send res 0
15
Send... CH03 3860100013785634120053.....send res 0
16
Send... CH23 3960100013785634120052.....send res 0
Komisch kommt mir vor, dass sich die firmware immer wieder den Wert 
holt, man muss daher mit retain-flag publishen, aber darum kümmern wir 
uns ggf. später.
PA-Level steht jetzt auf "HIGH".

Sollte die "echt-DTU-Adresse" aktiviert werden (im Moment ist das die 
1234...)?

von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Wie geschrieben: Das war im Sniffer-Modus.
>
> DEBUG_RCV_DATA und DEBUG_TX_DATA stehen jetzt noch auf 1, dann sieht das
> aktuell so aus (meine aktuelle Leistung wird jetzt dahin gepublisht):
>
1
> Send... CH40 376010001378563412005C.....send res 0
2
> ImpExpW Watt 223.0Watt  | All PVs received?:0
3
> Send... CH61 3860100013785634120053.....send res 0
4
> Send... CH75 3960100013785634120052.....send res 0
5
> Send... CH03 366010001378563412005D.....send res 0
6
> Send... CH23 376010001378563412005C.....send res 0
7
> Send... CH40 3860100013785634120053.....send res 0
8
> Send... CH61 3960100013785634120052.....send res 0
9
> Send... CH75 366010001378563412005D.....send res 0
10
> Send... CH03 376010001378563412005C.....send res 0
11
> Send... CH23 3860100013785634120053.....send res 0
12
> Send... CH40 3960100013785634120052.....send res 0
13
> Send... CH61 366010001378563412005D.....send res 0
14
> Send... CH75 376010001378563412005C.....send res 0
15
> Send... CH03 3860100013785634120053.....send res 0
16
> Send... CH23 3960100013785634120052.....send res 0
17
>
> Komisch kommt mir vor, dass sich die firmware immer wieder den Wert
> holt, man muss daher mit retain-flag publishen, aber darum kümmern wir
> uns ggf. später.
> PA-Level steht jetzt auf "HIGH".
>
> Sollte die "echt-DTU-Adresse" aktiviert werden (im Moment ist das die
> 1234...)?

wenn deine wr-sn 104160100013 ist dann sollte es gehen, dtu adr ist egal

probiere mal ohne crc
kannst auch mal ohne interrupt probieren

ich fahre immer ohne crc und interrupt

von Jörg R. (rejoe2)


Lesenswert?

Die Adresse paßt (jedenfalls steht die so auf dem abfotografierten 
Etikett), CRC war eh' aus (entsprechend den in der zip enthaltenen 
Vorgaben).

Aktuelle Settings lt. minicom:
1
DEBUG_RCV_DATA 0
2
DEBUG_TX_DATA 0
3
PA_LEVEL 2
4
WITHWIFI 1
5
ZEROEXP 0
6
INTERRUPT 0
7
SNIFFER 0
8
ONLY_RX 0
9
CHECK_CRC 0

Werde das ganze dann nochmal in Ruhe durchgehen müssen bzw. ggf. auch 
warten, ob sich das "beruhigt" (oder sind die 30 Min Wartezeit bei 
diesem Code egal?).

von Ziyat T. (toe_c)


Lesenswert?

Jörg R. schrieb:
> Werde das ganze dann nochmal in Ruhe durchgehen müssen bzw. ggf. auch
> warten, ob sich das "beruhigt" (oder sind die 30 Min Wartezeit bei
> diesem Code egal?).

Ich habe mal in Ruhe das "RF_communication_protocol-V6.5.xlsx" 
angeschaut und gesehen dass 500/600W-Inverter nicht gleich ist wie der 
1000/1500W-Inverter, schade

EDIT:
hier
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

: Bearbeitet durch User
von Jörg R. (rejoe2)


Angehängte Dateien:

Lesenswert?

Hm, schade, ja. Trotzdem herzlichen Dank für deinen Support bis dahin, 
dann werde ich mir das mal zu Gemüte führen, vielleicht verstehe ich es 
ja...

Habe in den zwei angehängten Dateien ein paar kleinere Änderungen 
vorgenommen, damit man die nicht unbedingt direkt editieren muss, 
sondern die Einstellungen auch über settings.h vornehmen. Klappt 
zumindest teilweise, betr. MQTT ist kommentiert, inwieweit ich es prüfen 
konnte.

settings.h bekommt dann ein paar weitere Einträge:
1
// Pinger IP
2
#define PINGER_IP  {192,168,1,1}
3
4
// MQTT
5
bool MQTT_ON = 1;
6
#define MSERVER_IP   "192.168.1.99"
7
#define MSERVER_PORT 1883
8
#define MQTT_ID      "HOYMILES-DTU"
9
#define VALUE_TOPIC "inverter1"
10
#define SET_TOPIC   "inverter1/set"

von Eike (Gast)


Lesenswert?

Hi sage mal wie kann ich meine hardwar so flashen das sie wie am anfang 
ist ?
ich komme null mehr auf das boar d drauf ganz egal wie oft ich brüber 
flashe.
gibt es einen clean befehl den ich vorher absetzen kann ?


eike

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Der Eike der immer nur will und alles schlecht redet,...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.