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.
Angehängte Dateien:
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
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.
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 :)
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.
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...
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
Welche EXPERIMENTELLEN Software Funktionen sind bisher noch nicht im Standard enthalten (Pull Request / Merge) https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-experimentellen-software-funktionen-sind-bisher-noch-nicht-im-standard-enthalten-pull-request--merge Power Limit via mqtt https://github.com/grindylow/ahoy/pull/109
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.
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!!!!!
Mein Cloud MQTT (HiveMQ) Broker verwendet TLS-Verschlüsselung auf Port 8883, kann AhoyDTU dies unterstützen?
Angehängte Dateien:
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?
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
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
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
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.
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
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()
Angehängte Dateien:
-
IMG_20220704_082950066.jpg
370 KB -
IMG_20220730_190647241.jpg
160 KB
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.
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 :-)
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
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.
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...?
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
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?)
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.
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.
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
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.
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.
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
Daniel M. schrieb: > Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was > alles kommt und wie es bei dir genau aussieht. Ich konnte die Topics mittels MQTT Explorer raussuchen. Besten dank für den Tipp :) Nun funktionierte auch bei mir die Integration in Fhem. Jetzt stellt sich mir nur noch die Frage wie ich den Topic für die Leistungslimitierung formen muss. Ich verwende die Ahoy 0.4.25.bin hier aus dem Forum, da mir VS Code immer 70 Fehler beim kompilieren rauswirft und ich mir daher keine eigene .bin exportieren kann ;( Ich hoffe es geht auch schon in dieser Version.
guilligan71 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
Angehängte Dateien:
-
setup.png
22 KB
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.
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.
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.
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
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.
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?
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 ;-)
Angehängte Dateien:
-
mqtt.PNG
20 KB
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.
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
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.
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.
Angehängte Dateien:
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.
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
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.
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.
ja in inverter settings aber doch nicht in dtu settings oder ?
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+?
Jau da war auch eine drin die habe ich bei ersten Male gelöscht weil ich dachte ich muss da meine serial eintragen
Die ist standardmäßig drinnen 99978563412
Eingetragen...klappt nicht wie nah muss das Teil beim Umrichter sein?
@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?
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
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
https://www.amazon.de/gp/product/B07Z83MF5W/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1 das gekauft https://www.amazon.de/gp/product/B09MKCZ7WT/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1 und das
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.
Angehängte Dateien:
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.
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 =:-)
Angehängte Dateien:
-
Ahoy-Setup-Sample.png
64 KB
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 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
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.
Found it: RF通讯协议-V6.6.xlsx last entry from 2020.03.10
Angehängte Dateien:
-
hm600.JPG
110 KB
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.
Maik R. schrieb: > schau mal in den angehängten Screenshot Ich kann da gar nichts eintragen, da ich opendtu habe :( Eike
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?
Angehängte Dateien:
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
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).
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
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?
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.
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
Angehängte Dateien:
-
OpenDTU.jpg
58 KB
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.
Merkwürdig. OpenDTU läuft bei mir seit Wochen einwandfrei. Ich würde sagen, der Fehler sitzt selber vor dem Teil,....
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.
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
Angehängte Dateien:
-
AC_Power.jpg
70 KB
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
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 :-)
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 ;)
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
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
Angehängte Dateien:
-
AlarmData_diff.png
38 KB
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.
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.
@Olli Das hat man normal, wenn parallel eine original DTU mitläuft.
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 ?
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.
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?
Olli schrieb: > Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht > funktionieren würden? Es kann nur einen geben;-)
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.
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 ?
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.
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
Angehängte Dateien:
-
modbus-C001.png
77 KB
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.
Angehängte Dateien:
-
Download_bin.png
89 KB
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
Ist OpenDTU eine Alternive zu Ahoi und kann auch auf einem Esp8266 installiert werden?
...einfach 'mal die FAQ https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu bemühen, genau dafür sind sie da.
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?
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?
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
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
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
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..
Angehängte Dateien:
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).
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?
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)
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
Angehängte Dateien:
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
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
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.
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.
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
Stefan T. schrieb: > Es gibt m.W. für OpenDTU noch keine GitHub Actions die automatisch die Binaries erzeugen. Doch gibt es...
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
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.
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
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.
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 :-)
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).
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".
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...
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)
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!!!
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 ?
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).
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?
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.
Danke! Ich frage deshalb, weil er bei mir bisher keine Verbindung herstellen kann, es ist ein 300W-Modul dran und die LED blinkt im Sekundentakt rot (da noch kein AC angeschlossen ist). Die 30 Min. sind bald rum, ich fürchte nur, dass sich nicht viel ändern wird. Die SN ist korrekt eingetragen, zwischen Antenne und WR liegen nur 3m. Die Meldungen sind bisher nicht vielversprechend: I: Requesting Inverter SN 11417201xxxx -> I: Transmit 27 | ... Inverter #0 I: no Payload received! (retransmits: 5) .... Hab das Modul im Setup sowohl mal unter Port 1 als auch unter Port 2 ausprobiert, die Meldungen sind leider die gleichen.
Joachim 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
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 :-(
Mit welcher Software flasht Ihr die OpenDTU bin Files auf den ESP32?
Olli schrieb: > Mit welcher Software flasht Ihr die OpenDTU bin Files auf den > ESP32? Mit Visual Studio Code + PlatformIO
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.
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.
Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen? Also opendtu und ahoi?
@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.
Ne geile FAQ wäre auch toll. Gibt es aber auch nicht.
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
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"
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
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 ;)
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.
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!
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
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
@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.
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
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 ?
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.
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
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 ?
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.
Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade eingestellt ist, da ich das für die EVU brauche.
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.
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
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.
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
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?
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
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
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
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
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.
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
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?
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.
Angehängte Dateien:
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?
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!
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
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
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.
@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
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...
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?
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.
Ich habe gerade auf die 0.5.1 upgedatet. Bei "Aktive Power Level" hatte ich nichts eingetragen, also stand es bei 0. Nun produzierte mein HM600 nichts mehr, auch nicht nachdem ich 600 eigetragen habe. Erst nach einem Neustart des WR produziert er wieder. Ist das so beabsichtigt? Zusatzfrage, kann (darf) man das Limit auch nach oben setzen?
Volker.B. schrieb: > Zusatzfrage, kann (darf) man das Limit auch nach oben setzen? Hat sich erledigt, bringt nichts, habe es getestet.
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.
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 :/
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> |
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"
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
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.
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).
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?
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
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...)?
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
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?).
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?"
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" |
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
Der Eike der immer nur will und alles schlecht redet,...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.