Hallo,
ich habe mir ein Balkonkraftwerk mit dem Hoymiles HM-600 Wechselrichter gekauft (siehe z.B. hier https://amzn.to/3ukzm7c ).
Zu dem Wechselrichter gibt es das Produkt "Datenlogger DTU-W100 " (siehe z.B. hier https://amzn.to/3bS1kRw ).
Der WLAN-Stick kommuniziert mit dem Wechselrichter und sendet die Verbrauchsdaten in die Cloud. Von hier kann man diese als angemeldeter Benutzer wieder abrufen.
Ich möchte die Daten des erzeugten Stroms gerne in FHEM integrieren und verwalten.
Jetzt frage ich mich, ob es nicht eine einfachere Möglichkeit gibt, die Daten vom Wechselrichter abzurufen, ohne dass ich mir das Produkt DTU-W100 kaufe.
Hat sich damit schon jemand beschäftigt?
Lösungen mit Zwischenstecker, Shelly etc sind mir natürlich auch bekannt und wären umsetzbar.
Ich finde es nur ganz interessant, dass wenn der Wechselrichter die Daten schon bereitstellt, wenn man diese dann direkt in FHEM integrieren könnte.
Vielleicht kann mir ja jemand helfen und hat sich mit der Frage schon auseinander gesetzt...
Viele Grüße
Jens
...das trifft sich prima!
Ich würde gerne einen von den überzähligen CC2531-USB-Dongles für was ähnliches verwenden, und optimalerweise dafür direkt Module schreiben (also ein IO-Modul, das mit dem speziell geflashten CC2531 redet, und eines, das jeweils einen Microconverter (als Client) repräsentiert...; ich weiß aber nicht, ob das mit der von dir genannten Type direkt geht).
Basis des Ganzen ist hier zu finden: https://github.com/Koenkk/zigbee2mqtt/issues/4221#issuecomment-845295531
Wer es - vorbehaltlich des anderen Models - einfacher haben will und die Lösung von csowada nehmen möchte (macht wohl MQTT über einen ESP8266+CC2530): https://github.com/csowada/Tasmota/blob/aps-pv-ecu/README_AP_SYSTEMS_ZIGBEE.md
Ich habe allerdings noch überhaupt keine Ahnung, wie man so einen USB-Stick vernünftig initialisiert... ;D
Zitat von: Beta-User am 25 Mai 2021, 18:10:10
...das trifft sich prima!
Ich würde gerne einen von den überzähligen CC2531-USB-Dongles für was ähnliches verwenden, und optimalerweise dafür direkt Module schreiben (also ein IO-Modul, das mit dem speziell geflashten CC2531 redet, und eines, das jeweils einen Microconverter (als Client) repräsentiert...; ich weiß aber nicht, ob das mit der von dir genannten Type direkt geht).
Basis des Ganzen ist hier zu finden: https://github.com/Koenkk/zigbee2mqtt/issues/4221#issuecomment-845295531
Wer es - vorbehaltlich des anderen Models - einfacher haben will und die Lösung von csowada nehmen möchte (macht wohl MQTT über einen ESP8266+CC2530): https://github.com/csowada/Tasmota/blob/aps-pv-ecu/README_AP_SYSTEMS_ZIGBEE.md
Ich habe allerdings noch überhaupt keine Ahnung, wie man so einen USB-Stick vernünftig initialisiert... ;D
Ich bin gespannt - immerhin haben wir den selben Gedanke ;-)
Zitat von: josburg am 25 Mai 2021, 18:14:39
Ich bin gespannt - immerhin haben wir den selben Gedanke ;-)
...ich auch...
Allerdings werde ich dafür vermutlich Hilfe benötigen (von jemandem, der sich mit sowas auskennt), das kann also dauern...
(Für eine schnelle Lösung würde ich den "NodeMCU-Weg" aus dem verlinkten zip empfehlen, wenn du grade einen ESP8266 mit passenden PINs und einen CC2530 übrig haben solltest.)
@potentielle kompetente Mitleser: In der verlinkten Zip ist lua-Code, um mit einem CC253x seriell zu kommunizieren, einmal für's "Pairen", einmal zum regulären Betrieb (Anforderung der Daten und Auswertung). Vielleicht hat mir jemand eine Fundstelle, die er verlinken kann, wie man sowas in Perl-Code (optimalerweise im FHEM-Kontext) umwandelt...?
(Für's erste wäre ich schon froh, dem CC2531 ein "Hello World" (z.B. in Form einer Versionsinfo) entlocken zu können.)
Danke vorab für's Verlinken ;) .
verstehe ich das jetzt richtig das die Hoymiles mit Zigbee funken ?
Zitat von: laserrichi am 26 Mai 2021, 13:31:48
verstehe ich das jetzt richtig das die Hoymiles mit Zigbee funken ?
Mit ziemlicher Wahrscheinlichkeit.
ABER: Wenn, dann ist es proprietäres ZigBee, gefunkt wird ausschließlich auf Kanal 16. Es gibt für die ähnlich aufgebauten YC600 und QS1 (?) eine spezielle (Coordinator-) Firmware für den CC2530 (und CC2531), mit der man das wohl empfangen und auswerten kann, wenn die Dinger gepairt sind.
Weitere Infos sind in dem verlinkten zigbee2mqtt-Thread zu finden, viel mehr weiß ich im Moment auch noch nicht...
Der Hoymiles 1200 benutzte definitiv kein Zigbee sondern der von NRF propriertäre entwickelte Standart ähnlich der auch bei den NRF24L01-Module zum Einsatz kommt. Meinet Wissens sind alle von 600 bis 1500 W mit der gleicher Schnittstelle ausgestattet, daher die gleiche Loger.
Der Standart hat nichts mit Zigbee zu tun außer das der genau wie Zigbee, Bluetooth, WiFi und andere auf 2.4 GHz sendet. Mehr aber auch nicht.
Auch die Angabe das die APsystem YC600 Baugleich mit Hoymiles HM-600 sind, kann ich in den Links nicht wieder finden.
Woher kommen diese Aussagen bzw. auf welcher Grundlage wurden die gemacht, dass die Baugleich sind und somit auch Zigbee nutzen sollen?
Siehe hier - da steht klar und deutlich "Nordic RF proprietary": https://www.dtcmro.com/product-p803737.html?variant=5229530 (https://www.dtcmro.com/product-p803737.html?variant=5229530)
P.S. Alleine die techn-Daten der beiden Geräte sind so unterschiedlich, dass eine Ähnlichkeit und Baugleichheit ich stark bezweifele. Der Hoymiles kann bis zu 760W aushalten, der Apsystem nur 600W; Eigenverbrauch liegt bei 50 gegenüber 20mW, empfohlene PV-Spannung 29-48V ggü. 16-55V.
P.S. Schaut Euch doch mal das Produktdatenblatt an. Ganz am Ende die 4te vorletzte Zeile.;-)
https://www.alpha-solar.info/media/Dokumente/Wechselrichter/Hoymiles%20HM/Deutsch/Datenbl%C3%A4tter/HM-600%20Technische%20Daten.pdf
Vermutlich hast du recht und da war Wunschlesemodus aktiv...
Wobei das, was die APSystems-Geräte machen auch eigentlich was proprietätes (offiziell als ZigBee bezeichnetes) zu sein scheint.
(Na ja, falls jemand eine Idee hat, wie man ggf. mit Nordic-Chips zu einem Ergebnis kommt: nRF24L+...-Module hätte ich noch ein paar rumliegen, (und diverse MCU's,) daran würde es nicht scheitern.)
(For later use: https://www.blackhillsinfosec.com/promiscuous-wireless-packet-sniffer-project/ (https://www.blackhillsinfosec.com/promiscuous-wireless-packet-sniffer-project/)
"nordic proprietary" ist z.B. hier beschrieben: https://www.nordicsemi.com/Products/2-4-GHz-proprietary. Danach wäre anzunehmen, dass es der "gazelle" genannte Standard sein könnte, was allerdings auch wieder fraglich ist, da damit ein "pairing" nur im Nahbereich (bis 30cm) geht, siehe https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.0.0%2Fgzp_02_user_guide.html)
Gibt es da schon was neues ?
Ich habe jetzt CC2531 USB stick und die Firmware von hier https://gitlab.com/RunningPenguin/YC600_serial mit cc_write aufgespielt.
Aber da tut sich dann garnichts mehr bei dem Stick.
So wie ich das verstehe ist das nicht für den USB CC2531.
Hat das jemand mal probiert ?
Zitat von: laserrichi am 06 August 2021, 16:20:30
Gibt es da schon was neues ?
Falls du auch einen Hoymiles hast: Wie @gerdshi zurecht angemerkt hatte, sprechen etwas, das in der Doku des Herstellers "nordic proprietary" genannt wird.
Um was es sich dabei genau handelt ist unklar; möglich wäre z.B. auch ein (anderer?) ZigBee-Dialekt, weil neuere Chips aus dem Hause Nordic das _auch könnten_, oder der "gazelle" genannte Nordic-eigene Funkstandard.
Am wahrscheinlichsten erscheint es mir, dass es schlicht das "alte" nRF24-Format ist mit 32 Byte Payload, ich bin aber bisher nicht dazu gekommen, mal den verlinkten Sniffer anzuwerfen. Und ob man dann mit den Daten was anfangen könnte, wäre die nächste ungeklärte Frage, daher eilt es mir damit im Moment nicht...
Ich liebäugle damit mir einen HM-400 zuzulegen. Da ich bisher fast alles über FHEM laufen habe, wäre es natürlich auch schön wenn es mit diesem auch gehen würde. Jetzt hab ich aber schon die Erfahrung, selbst wenn man jetzt an die Kommunikation ran kommt, wie schaut es dann mit decodieren aus? Für die Tigo/SMA Optimierer zB habe ich keine Lösung zum dekodieren gefunden. Da hilft mir dann die Kommunikation auch nichts. Oder ist das mit einem Standard Protokoll dann wahrscheinlicher an lesbare Daten zu kommen?
Hallo Zusammen, auch wenn es hier um dem HM-600 geht, hat die Stichwortsuche "YC600" zu diesem Thread geführt. Fur die, die es interessiert: das Projekt von Patience4711 zum ApSystem YC600 ist ziemlich weit. Ich konnte meinen YC600 damit pairen und hab die Leistung der einzelnen Panles erfasst.
https://github.com/patience4711 (https://github.com/patience4711)
Wichtig: die Version, die gerade als Bin runter zu laden ist, unterstützt nur 40 Zeichen bei der WPA Verschlüsselung. Ich hab aber eine Version, die auch 63 Zeichen kann. Und der Wechselrichter startet erst wenn die Panels Leistung produzieren. Als geht das pairing nur bei Sonne :-)
Die Bemerkung im Datenblatt kann ich bestätigen. Es gibt auch Datenblätter [1] zum DTU genannten Auslesegerät von Hoymiles.
Dort wird zwar beim DTU-Lite-S [2] von einer "Sub-1G-Funklösung mit Mikro-Wechselrichter" gesprochen, was aber m.E. Unfug ist, da Bluetooth auf 2,4GHz läuft und somit wohl eher Supra-2G wäre =^D Vermutlich ist das chinesische Marketing hier wieder mal erfinderisch gewesen. Im Datenblatt des DTU-WWlite [3] heißt es dahingegen "Typ: Proprietärer 2,4-GHz-Protokoll (Nordic)". Beim DTU-Pro [4] steht hingegen gar nichts zur Kommunikation zwischen Wechselrichter und DTU.
Mein Hoymiles HM-600 scheint sich mit einem Nordic UART Service per Bluetooth zu melden.
Mit dem Tool nrfConnect von Nordic Semiconductors unter iOS/Android lassen sich damit die Bluetooth Services entdecken / discovern.
Meiner nennt sich "OBT123456" wobei 123456 hier ein sechstelliger Hexadezimal Code ist.
Das sollte sich mit einem Bluetooth BLE Dongle an einem Raspberry Pi bestätigen und ggf. mit gattctl/gatttool auslesen lassen.
Vielleicht hat ja auch jemand einen DTU und kann das Pairing zwischen Wechselrichter, DTU und der Hoymiles DTU Cloud mit Wireshark oder anderen Mitteln auf Bluetooth und Ethernet/WLAN Ebene mitschneiden ?
[1] Datenblätter https://www.hoymiles.com/de-eu/sdm_downloads/?jsf=epro-archive&tax=sdm_categories:599;download_language:533,595,532
[2] DTU-Lite-S https://www.hoymiles.com/wp-content/uploads/2022/03/Datenubertragungseinheit-Datenblatt_DTU-Lite-S_Global_DE_V202202.pdf
[3] DTU-Wlite https://www.hoymiles.com/wp-content/uploads/2021/12/Datenblatt-der-Datenubertragung-seinheit_DTU-Wlite_Europe_DE_V202110.pdf
[4] DTU-Pro https://www.hoymiles.com/wp-content/uploads/2022/02/Datenubertragung-seinheit-Datenblatt_DTU-Pro_Global_DE_V202105.pdf
Hallo zusammen,
das Thema hat rasant an Entwicklungsgeschwindigkeit zugenommen.
Es geht vorerst mal hier im mikrocontroller Forum um das Eingemachte:
https://www.mikrocontroller.net/topic/525778
habe mit nrfConnect einmal probiert um den MI-600 zu finden, aber leider nichts zu sehen.
Zwischenzeitlich läuft die Lösung von
https://www.mikrocontroller.net/topic/525778
Ich habe den Ansatz mit ESP8266 und dem Funkmodul seit heute in Kombination mit einem HM-800 laufen.
Die Verbindung zu FHEM läuft via MQTT. Dabei habe ich noch ein Thema mit MQTT-Nachrichten mit identischem Namen.
als Reading List - wird von autocreate für beide Kanäle des Wechselrichter jeweils U_DC, IDC, P_DC aungelegt.
ESP_238:/inverter/CDS-Block-1/ch1/U_DC:.* U_DC
ESP_238:/inverter/CDS-Block-1/ch1/I_DC:.* I_DC
ESP_238:/inverter/CDS-Block-1/ch1/P_DC:.* P_DC
ESP_238:/inverter/CDS-Block-1/ch2/U_DC:.* U_DC
ESP_238:/inverter/CDS-Block-1/ch2/I_DC:.* I_DC
ESP_238:/inverter/CDS-Block-1/ch2/P_DC:.* P_DC
In den Readings scheint der eine Kanal den anderen Kanal zu überschreiben. U_DC I_DC und P_DC gibt es nur noch einmal.
Internals:
CFGFN
CID ESP_238
DEF ESP_238
FUUID 6272c14f-f33f-84af-34a2-b8bfa6061a06878a
IODev MQTT2_SERVER
LASTInputDev MQTT2_SERVER
MQTT2_SERVER_CONN MQTT2_SERVER_192.178.168.92_58402
MQTT2_SERVER_MSGCNT 1260
MQTT2_SERVER_TIME 2022-05-04 20:23:30
MSGCNT 1260
NAME MQTT2_ESP_238
NR 9308
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2022-05-04 20:23:30 Freq 50.000
2022-05-04 20:09:19 IODev MQTT2_SERVER
2022-05-04 20:23:30 I_AC 0.020
2022-05-04 20:23:30 I_DC 0.110
2022-05-04 20:23:30 P_AC 5.700
2022-05-04 20:23:30 P_DC 3.100
2022-05-04 20:23:30 Temp 19.000
2022-05-04 20:23:30 U_AC 232.400
2022-05-04 20:23:30 U_DC 28.800
2022-05-04 20:23:30 YieldDay 1492.000
2022-05-04 20:23:30 YieldTotal 10.438
2022-05-04 20:23:30 YieldWeek 9703.000
2022-05-04 20:09:20 version 0.3.3
Attributes:
readingList ESP_238:/inverter/version:.* version
ESP_238:/inverter/CDS-Block-1/ch1/U_DC:.* U_DC
ESP_238:/inverter/CDS-Block-1/ch1/I_DC:.* I_DC
ESP_238:/inverter/CDS-Block-1/ch1/P_DC:.* P_DC
ESP_238:/inverter/CDS-Block-1/ch2/U_DC:.* U_DC
ESP_238:/inverter/CDS-Block-1/ch2/I_DC:.* I_DC
ESP_238:/inverter/CDS-Block-1/ch2/P_DC:.* P_DC
ESP_238:/inverter/CDS-Block-1/ch0/YieldWeek:.* YieldWeek
ESP_238:/inverter/CDS-Block-1/ch0/YieldTotal:.* YieldTotal
ESP_238:/inverter/CDS-Block-1/ch1/YieldDay:.* YieldDay
ESP_238:/inverter/CDS-Block-1/ch2/YieldDay:.* YieldDay
ESP_238:/inverter/CDS-Block-1/ch0/U_AC:.* U_AC
ESP_238:/inverter/CDS-Block-1/ch0/Freq:.* Freq
ESP_238:/inverter/CDS-Block-1/ch0/P_AC:.* P_AC
ESP_238:/inverter/CDS-Block-1/ch0/I_AC:.* I_AC
ESP_238:/inverter/CDS-Block-1/ch0/Temp:.* Temp
room MQTT2_DEVICE
Mache ich hier einen Fehler?
Gruß Manuel
Mein Problem konnte ich nun selber durch die Anpassung der ReadingList lösen...
Gruß Manuel
ESP_2c91:/inverter/version:.* version
ESP_2c91:/inverter/CDS-Block-1/ch1/U_DC:.* U_DC1
ESP_2c91:/inverter/CDS-Block-1/ch1/I_DC:.* I_DC1
ESP_2c91:/inverter/CDS-Block-1/ch1/P_DC:.* P_DC1
ESP_2c91:/inverter/CDS-Block-1/ch2/U_DC:.* U_DC2
ESP_2c91:/inverter/CDS-Block-1/ch2/I_DC:.* I_DC2
ESP_2c91:/inverter/CDS-Block-1/ch2/P_DC:.* P_DC2
ESP_2c91:/inverter/CDS-Block-1/ch0/YieldWeek:.* YieldWeek_0
ESP_2c91:/inverter/CDS-Block-1/ch0/YieldTotal:.* YieldTotal_0
ESP_2c91:/inverter/CDS-Block-1/ch0/U_AC:.* U_AC_0
ESP_2c91:/inverter/CDS-Block-1/ch0/Freq:.* Freq_0
ESP_2c91:/inverter/CDS-Block-1/ch0/Temp:.* Temp_0
ESP_2c91:/inverter/CDS-Block-1/ch0/P_AC:.* P_AC_0
ESP_2c91:/inverter/CDS-Block-1/ch0/I_AC:.* I_AC_0
ESP_2c91:/inverter/CDS-Block-1/ch2/YieldDay:.* YieldDay_2
ESP_2c91:/inverter/CDS-Block-1/ch0/YieldDay:.* YieldDay_0
ESP_2c91:/inverter/CDS-Block-1/ch1/YieldDay:.* YieldDay_1
Hallo,
ich habe mir 6 Stk Balkonkraftwerke gekauft. Auf denen sind HM-300 verbaut.
Ich bin gerade dabei mich ein zu lesen. Da Du das schon am laufen hast, würde mich mal interessieren was ich dazu benötige um die Zellen in Fhem abzufragen.
Brauche ich den nRF24L01+ Transceiver da für jeden Wechselrichter ?
Kann man einen D1 Mini mit dem nRF24L01+ verbinden und darauf dann einen Sketch flashen der dann im besten Fall alle HM-300 Daten empfängt ?
Oder ist das doch etwas aufwändiger ?
Der nRF24L01+ ist ja recht günstig. Ich würde dann schonmal so einen ordern
Ich brauch mal Starthilfe...
Zitat von: Skusi am 16 Mai 2022, 18:59:18
Brauche ich den nRF24L01+ Transceiver da für jeden Wechselrichter ?
Kann man einen D1 Mini mit dem nRF24L01+ verbinden und darauf dann einen Sketch flashen der dann im besten Fall alle HM-300 Daten empfängt ?
Ich warte noch auf mein Balkonkraftwerk bzw. Wechselrichter, hab' aber dafür den anderen Schritt schonmal gemacht...
Habe das da bestellt und 1 davon mit einem vorhandenen D1-mini-pro (Nachbau) verbunden: https://www.amazon.de/gp/product/B07PQPFTWZ/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1
Achtung: Das Pinning ist anders als in der Anleitung beschrieben.
Firmware geflasht und nach ein paar Versuchen hat's dann auch wie beschrieben geklappt.
Aktuell können in der Firmware 3 unterschiedliche Wechselrichter eingetragen werden, d.h. für 6 Stück würdest Du nach aktuellem Stand 2x D1 mit je 1 NRF24L01+ brauchen.
Nachtrag:
Blöde Frage, warum kauft man 6 Stück HM-300 und nicht beispielsweise 3 Stück HM-600/700/800? (Oder 1-2 1500er?)
Das hört sich gut an.
Dann werde ich mal 2 Stk nRF24L01+ besorgen.
Wo bekomme ich die Firmware für den ESP 8266 her ?
ZitatBlöde Frage, warum kauft man 6 Stück HM-300 und nicht beispielsweise 3 Stück HM-600/700/800? (Oder 1-2 1500er?)
Weil die HM-300 nun mal vom Hersteller auf jedem Modul verbaut sind, und ich die sehr günstig kaufen konnte. ;)
Zitat von: Skusi am 16 Mai 2022, 20:36:50
Wo bekomme ich die Firmware für den ESP 8266 her ?
Entweder die Quelldateien von GIT runterladen und selbst übersetzen oder im Mikrokontroller-Forum aus einem der Anhänge die Binaries runterladen. Das ist dann aber nicht der letzte Erkenntnisstand, gab schon ein paar Tage keine neuen Binaries dort.
Ich habe die letzte Datei von dort laufen, da ich noch keinen Wechselrichter habe reicht das vorerst.
Bin auch noch nicht weiter gekommen, aber die Zahl der Wechselrichter ist konfigurierbar. Steht zumindest hier:
https://github.com/grindylow/ahoy/tree/main/tools/esp8266#optional-configuration-before-compilation
Wie lange bleibt bei euch der MQTT connectet ? Der DTU ESP läuft stabil aber MQTT bricht ständig ab und connectet nicht neu. Also keinen Daten mehr :(
Habe MQTT nicht aktiviert.
Da noch kein Wechselrichter dran ist, prüfe ich mittels HTTPMOD aktuell nur die Uptime.
Ich verwende die ESP8266 Variante. (Gibt ja auch die Möglichkeit ein Phyton Skript direkt am Raspberry zu verwenden.)
Das mit den BIN Files aus dem Forum habe ich bei mir noch nicht hinbekommen. Liegt wohl daran dass die Hardware nicht bei jedem identisch ist.
Ich habe einen ESP8266 mit 4MB Flash Speicher - Im Forum scheint eine 1MB Variante verbreitet zu sein.
Ich habe bei mir Arduino IDE 1.8.19 installiert und hole mir die Sourcen über Visual Studio Core direkt aus dem Git.
https://github.com/grindylow/ahoy.git (https://github.com/grindylow/ahoy.git)
Aktuell gibt es da die Version 0.4.2 die ich eben erst gezogen habe.
MQTT läuft bei mir nicht stabil was erst mal nicht kritisch wäre - derzeit wird aber nach jedem reboot ein neues Gerät erzeugt d.h. Visualisierungen brechen dann ab und müssten auf das neue Gerät angepasst werden. Ich nehme an das ist noch ein Bug der behoben werden kann. Derzeit gehe ich nicht davon aus dass dies ein Problem von meiner FHEM Konfiguration ist.
Grundsätzlich habe ich in FHEM einen MQTT2_SERVER installiert und die IP meines FHEM-Raspberry im APP inkl. Passwort/Username bekannt gemacht. Damit wir MQTT als connected angezeigt und die Daten übertragen.
Wirf die CID-Angaben aus der readingList...
Danke das hat mir geholfen - so scheint es nun zu funktionieren wie gewünscht.
ESP_.*:/inverter/version:.* version
ESP_.*:/inverter/CDS-Block-1/ch1/U_DC:.* 1_U_DC
ESP_.*:/inverter/CDS-Block-1/ch1/I_DC:.* 1_I_DC
ESP_.*:/inverter/CDS-Block-1/ch1/P_DC:.* 1_P_DC
ESP_.*:/inverter/CDS-Block-1/ch1/YieldDay:.* 1_YieldDay
ESP_.*:/inverter/CDS-Block-1/ch1/YieldTotal:.* 1_YieldTotal
ESP_.*:/inverter/CDS-Block-1/ch2/U_DC:.* 2_U_DC
ESP_.*:/inverter/CDS-Block-1/ch2/I_DC:.* 2_I_DC
ESP_.*:/inverter/CDS-Block-1/ch2/P_DC:.* 2_P_DC
ESP_.*:/inverter/CDS-Block-1/ch2/YieldDay:.* 2_Y_ieldDay
ESP_.*:/inverter/CDS-Block-1/ch2/YieldTotal:.* 2_YieldTotal
ESP_.*:/inverter/CDS-Block-1/ch0/U_AC:.* U_AC
ESP_.*:/inverter/CDS-Block-1/ch0/I_AC:.* I_AC
ESP_.*:/inverter/CDS-Block-1/ch0/P_AC:.* P_AC
ESP_.*:/inverter/CDS-Block-1/ch0/Freq:.* Freq
ESP_.*:/inverter/CDS-Block-1/ch0/Temp:.* Temp
ESP_.*:/inverter/CDS-Block-1/ch0/YieldDay:.* YieldDay
ESP_.*/inverter/CDS-Block-1/ch0/YieldTotal:.* YieldTotal
Zitat von: Petrosilius Zwackelmann am 18 Mai 2022, 08:04:03
Danke das hat mir geholfen - so scheint es nun zu funktionieren wie gewünscht.
Ist ein "Standard-Problem"
https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St.C3.A4ndig_neue_Devices.3F (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St.C3.A4ndig_neue_Devices.3F)
So ginge es auch
/inverter/version:.* version
/inverter/CDS-Block-1/ch1/U_DC:.* 1_U_DC
[...](Insgesamt muss ich mir das mal ansehen. Eigentlich sollte jede MQTT-firmware in der Lage sein, eine dauerhafte ClientId vergeben zu lassen, und auch die (verkürzte) Info, was zu welcher Seriennummer gehört, sollte nach meinem Geschmack eigentlich über die Topic-Struktur erkennbar sein. Dann könnte man auch sowas wie eine bridgeRegexp setzen und den ESP an sich und jeden Inverter als getrenntes MQTT2_DEVICE betrachten. Noch cooler wäre es, wenn man dann das ganze mit dem OpenMQTTGateway-Code verheiraten könnte - an den ESP32 noch einen nRF anzuschließen würde den wohl nicht überfordern...).
Zitat von: Petrosilius Zwackelmann am 17 Mai 2022, 20:43:41
Ich habe einen ESP8266 mit 4MB Flash Speicher - Im Forum scheint eine 1MB Variante verbreitet zu sein.
Das sollte nicht das Problem sein, ich habe gar 16MB Speicher, trotzdem habe ich die Binaries aus dem Forum zum Laufen gebracht... allerdings hat es auch unzählige Versuche gebraucht, bis es irgendwann ging. Habe gestern dann OTA-Update auf die 0.4.1 aus dem Forum probiert, was ebenfalls problemlos ging.
Zitatallerdings hat es auch unzählige Versuche gebraucht, bis es irgendwann ging.
Kannst du erklären worauf es ankommt ?
Zitat von: Petrosilius Zwackelmann am 19 Mai 2022, 16:28:34
Kannst du erklären worauf es ankommt ?
Nein.
Ich hatte zuerst ESPEasy auf dem D1. Lt. Beschreibung im Mikrokontroller-Forum hätte ich darauf einfach deren Firmware mittels OTA aufspielen sollen, was ich versucht habe. Dann ging aber nix mehr.
Habe dann blank files draufgespielt und dann deren Firmware, ging wieder nicht, zurück auf ESPEasy um zu sehen ob der D1 überhaupt noch funktioniert, wieder auf deren Firmware, was wieder nicht ging. Habe dann ältere binaries probiert, ohne Erfolg, und als ich schon aufgeben wollte, lief die letzte 0.3.x dann doch hoch.
also ich bekomme es auch nicht hin, ich hatte mir vom git das ganze runtegeladen, dann meine wifi eingetragen und compiiert und hochgeladen
Ich habe weder einen wifi accesspoint noch verbindet sich das mit meinen netz...
Welche BIN habt ihr ? im git ist keine fertige binary
Wifi muss man nicht vor dem comilieren eingeben.
Die Verbindung mit dem ESP8266 erfolgt über einen Wifi access point.
// access point info
WIFI_AP_SSID "AHOY-DTU"
WIFI_AP_PWD "esp_8266"
Erst hier trägt man dann die Infos von seinem eigenen Wifi ein. Nach einem Neustart findet man dann die IP in seinem Router.
http://<ip>/hoymiles
http://<ip>/setup
Gruß Manuel
ja das hab ich schon auch so gesehen.
Aber der Accesspoint erscheint erst garnicht.
Ich habe auch die 220529_ahoy_0.4.11.d1_mini.bin schon probiert und ist das selbe verhalten
Die LED blinkt... mehr nicht
also ich bin einen schritt weiter... ich kann das Verhalten nicht plausibel erklären aber mit 2 ESPs war ein identisches Verhalten.
Die Version 220519_ahoy_0.4.4_esp8266.bin hat jetzt funktioniert.
Dabei sah ich aber auch in den Settings lauter yyyyyyyyyyyyyyyyyyy und ich vermute bei der 0.4.11 und 0.4.13 wurde der Speicher nicht richtig initialisiert.
Und von dieser Version aus konnte ich OTA die 220529_ahoy_0.4.13_esp8266.bin installieren.
Mal sehen ob damit mein WR zu sehen ist wenn es hell wird.
Zitat von: laserrichi am 09 Juni 2022, 22:25:21
Und von dieser Version aus konnte ich OTA die 220529_ahoy_0.4.13_esp8266.bin installieren.
Mal sehen ob damit mein WR zu sehen ist wenn es hell wird.
Läuft die denn?
Bei mir läuft die zwar noch, aber das Webinterface ist endlos langsam. Bin daher wieder auf die 0.4.4 gegangen.
Wenn die Dachständer heute früh genug kommen, kann ich heute vielleicht noch die Paneele aufstellen und ev. den Wechselrichter anschließen. Nächste Woche sollte dann hoffentlich den "DTU-Ersatz" soweit sein, dass die Kommunikation mit dem WR läuft.
Zitat von: TheTrumpeter am 10 Juni 2022, 10:56:24
Läuft die denn?
Bei mir läuft die zwar noch, aber das Webinterface ist endlos langsam. Bin daher wieder auf die 0.4.4 gegangen.
zumindest ESP läuft :-) da ich einen MI-600 habe geht es noch nicht mit diesem Wechselrichter. aber einer hat es geschafft der MI Serie daten zu entlocken. Bleibt also spannend.
Habe jetzt auch nochmal die 0.4.13 probiert...
Webinterface hat gar nicht mehr geladen; im Router habe ich aber gesehen, dass die IP-Adresse genutzt wird.
Mehrfache Kaltstarts haben nichts geändert, als ich dann das nRF-Modul abgesteckt habe, ging's plötzlich.
Habe dann gesehen, dass in der Konfiguration alle Pins mit D3 eingetragen waren und auch die Infos zum WR verloren waren.
Habe alles neu konfiguriert, nRF-Modul angeschlossen und neu gestartet, ging trotzdem nicht.
Erst als ich das nRF-Modul erneut abgesteckt habe, ging's wieder. Die Konfiguration war wieder verloren.
Bin nun wieder auf 0.4.4, die erstmal zuverlässig läuft, wenngleich noch ohne Kommunikation zum WR.
ich habe festgestellt das ich das nrf-Modul falsch angelötet hatte und dann bootet der nicht mehr richtig bzw. ich konnte auch nicht mehr flashen.
Jetzt hab ich den so verbunden:
| nRF24L01+ | | ESP8266 |
| GND | | GND |
| VCC | | +3.3V |
| CE | | D4 |
| CSN | | D8 |
| SCK | | D5 |
| MOSI | | D7 |
| MISO | | D6 |
| IRQ | | D3 |
Also ich habe jetzt die 0.4.19 selbst kompiliert mit 6 Stk HM-300 Wechselrichtern sauber am laufen.
Alle Daten werden nacheinander abgefragt und per MQTT an Fhem gesendet.
Tolle Arbeit die die Jungs da geleistet haben,und noch leisten:
https://www.mikrocontroller.net/topic/525778
Für mich macht der Wemos schon alles was ich brauche...
Zitat von: Skusi am 29 Juni 2022, 16:53:57
Also ich habe jetzt die 0.4.19 selbst kompiliert mit 6 Stk HM-300 Wechselrichtern sauber am laufen.
Alle Daten werden nacheinander abgefragt und per MQTT an Fhem gesendet.
Habe erst heute die 0.4.19 aus dem Mikrocontroller-Forum ausprobiert... er versucht damit in ein "kryptisches" WLAN einzuwählen, was nicht gelingt. Egal wie lange ich warte, der AP wird nie aufgemacht.
Die 0.4.17 läuft anstandslos.
Zitat von: Skusi am 29 Juni 2022, 16:53:57
Für mich macht der Wemos schon alles was ich brauche...
Ja sehe ich im Wesentlichen auch so.
Was mir noch fehlt (aber das ist schon meckern auf hohem Niveau):
- Abschalten der Abfrage nach Sonnenuntergang und Einschalten vor Sonnenaufgang
- Ausblenden der "0en" nach dem Neustart (d.h. einfach mal paar Sekunden auf Antwort vom WR warten, bevor die "0en" geschickt werden)
Habe heute mal die Abschirmung des nRF-Moduls gemacht wie im Mikrocontroller-Forum beschrieben; bzgl. Reboots hat's bei mir leider nicht geholfen. Bin noch nicht dahintergekommen, warum die Neustarts erfolgen, manchmal läuft der Wemos über 24h und dann wieder nur ein paar Stunden.
wegen den reboots, ich habs drüben im anderen forum auch mal geschrieben.
setze doch mal den 5sec intervall auf 20sec und retry auf 1
ich hatte auch die reboots, aber jetzt seit 6 Tagen läufts durch.
Zitat von: laserrichi am 01 Juli 2022, 21:00:27
wegen den reboots, ich habs drüben im anderen forum auch mal geschrieben.
setze doch mal den 5sec intervall auf 20sec und retry auf 1
ich hatte auch die reboots, aber jetzt seit 6 Tagen läufts durch.
Habe langsam die 5 "Retry" reduziert, hat aber erstmal keine Besserung gebracht. Seit dem Reset gestern läuft's nun mit 1 Retry und 5 Sekunden, ca. 24h momentan. Habe aber auch davor schon teilweise Laufzeiten von über 24h gehabt und dann wieder nur wenige Stunden ohne dass ich irgendetwas geändert hätte.
Mal sehen wie's nun aussieht.
Grundsätzlich sind die Reboots kein großes Problem für mich, weil die Verbindung danach sofort wieder vorhanden ist, nur die "0en" sind etwas störend.
Also mit 1 Retry und 5 Sekunden war's auch nicht besser.
Habe seit gestern ein anderes Netzteil (kleiner AC-DC-Wandler, den ich direkt angelötet habe) im Einsatz, ebenfalls keine Besserung.
Momentan lasse ich es einfach so laufen, habe andere wichtigere Dinge zu tun. Eventuell überleg' ich mir im Winter dann was, wenn sich bis dahin keine Lösung aufgetan hat.
Ich habe das gleiche Problem mit MQTT.
Man kann das Ding folgendermaßen neustarten:
defmod DR.Balkonsolar_restart at *07:00:30 { GetFileFromURL("http://esp-ahoy/reboot",2) }
Ich mache das jeden Morgen, nachdem das WLAN wieder eingeschaltet wurde.
Ist zumindest ein Workaround bis es eine stabile Version gibt.
Gruß Heiko
Kann ich mal probieren, aber ich glaube nicht, dass ein morgendlicher Neustart die sporadischen Neustarts tagsüber verhindert.
Mittlerweile glaube ich immer mehr, dass es irgendwie mit dem Fritz.Repeater, an dem das Teil eingebucht ist, zusammenhängt.
Sporadische Neustarts kann ich mit der 0.4.25 nicht mehr nachvollziehen.
Bei mir läuft er tageweise ohne Reboot durch.
Die letzen Neustarts waren bei mir manuelle, da die MQTT Verbindung abgerissen ist.
Hab allerdings nur eine Zentrale Fritzbox und kein Repeater.
Zitat von: der2of6 am 26 Juli 2022, 09:59:53
Sporadische Neustarts kann ich mit der 0.4.25 nicht mehr nachvollziehen.
Hm... ich bin noch auf der 0.4.17. Habe zuletzt 0.4.19 oder 0.4.20 probiert, die haben sich gar nicht ins WLAN eingebucht bzw. aber auch keinen Accesspoint geöffnet. Vielleicht probier' ich mal wieder ein Update. Abgesehen von den Reboots läuft die 0.4.17 problemlos.
Zitat von: der2of6 am 26 Juli 2022, 09:59:53
Bei mir läuft er tageweise ohne Reboot durch.
Tja, habe auch schon Laufzeiten über 2 Tagen gesehen, dann wieder nur ein paar Stunden.
Zuletzt war vor dem Reboot schon die HS110, die auch die PV-Leistung misst und auch an dem Repeater hängt, 1-2h ohne WLAN-Verbindung. Als diese Steckdose dann wieder "kam", hat auch die DTU rebootet.
Zitat von: der2of6 am 26 Juli 2022, 09:59:53
Die letzen Neustarts waren bei mir manuelle, da die MQTT Verbindung abgerissen ist.
Ich nutze MQTT nicht, daher kann ich dazu nix sagen. Ich lese die Werte einfach per HTTPMOD aus.
Bei mir läuft die V0.4.22 seit fast einer Woche fehlerfrei. Auch die Wiederverbindung von MQTT nach Wlan-Abschaltung klappt damit fehlerfrei.
Den automatischen reboot habe ich wieder deaktiviert.
Das MQTT Problem wurde gefixt im git vor wenigen Tagen.
Hat aber leider immer noch die version 4.25 :(
Aber wie macht ihr das mit der readingslist? Wenn mehrere Panels oder WR's dranhängen überschreibt der ja einfach die Werte immer, da diese ja gleich heissen.
Habt ihr die alle angepasst oder wie gelöst?
Ich habe es in der readingList manuell überschrieben.
AHOY_DTU:Wechselrichter/HM1/ch1/U_DC:.*U_DC1
[....]
AHOY_DTU:Wechselrichter/HM1/ch2/U_DC:.*U_DC2
Das hatte ich fast befürchtet das es alle so gemacht haben, mich eingeschlossen.
Vieleicht bastellt ja mal einer ein Modul für das Teil.
Ich kann schlechter Perl wie Fische fliegen. Also bin ich raus ;)
Aber das/der/die Gateway/Dongle/Moped oder wie auch immer ihr das nennen mögt funktioniert ja tadellos.
Zitat von: kask am 04 August 2022, 17:30:27
Aber wie macht ihr das mit der readingslist? Wenn mehrere Panels oder WR's dranhängen überschreibt der ja einfach die Werte immer, da diese ja gleich heissen.
Habt ihr die alle angepasst oder wie gelöst?
Ich hole die Daten via HTTPMOD und habe das Problem daher nicht.
Verstehe aber nicht wieso das Problem überhaupt existiert. Wenn Du bei den Einstellungen jedem Wechselrichter bzw. Modul einen eigenen Namen gibst, würde ich erwarten, dass die Werte in MQTT auch unterschiedliche Namen haben.
Sobald das mit dem MI-600 auch (bei mir) klappt, gibt's eventuell einen attrTemplate-Satz dazu. Aber insgesamt sollte das auch kein Hexenwerk sein, das händisch einzurichten.
Leider bekomme ich bis dato keine Daten von dem Ding (via ESP8266+nRFL01+ und
AHOY-DTU in Version 0.4.26), wenn ich das im Mikrocontroller.net-Thread richtig verstanden habe, ist das noch nicht ganz soweit.
Wenn, dann würde ich das wieder in ein "MCU"-Basis-/Verteil-Device aufsplitten, das dann die einzelnen Wechselrichter je in ein Device weiterleitet, das dann wieder 1, 2 oder 4 (?) Kanäle für die Leistungsdaten je MPPT-Tracker hat, oder?
Zitat von: Beta-User am 04 August 2022, 21:58:29
Wenn, dann würde ich das wieder in ein "MCU"-Basis-/Verteil-Device aufsplitten, das dann die einzelnen Wechselrichter je in ein Device weiterleitet, das dann wieder 1, 2 oder 4 (?) Kanäle für die Leistungsdaten je MPPT-Tracker hat, oder?
Ich sehe den Vorteil von mehreren Devices noch nicht. Würde es nicht einfacher sein die Namen der Readings einfach aus den Einstellungen der DTU zu generieren?
Also einfach das, was die Leute als Bezeichnung für ihre WR/Module eintragen, als Präfix vor die Namen der Readings zu setzen?
Aus U_DC wird dann z.B. "WR1_Modul1_U_DC", "WR1_Modul2_U-DC", "WR2_Modul1_U-DC" usw.
Zitat von: TheTrumpeter am 05 August 2022, 06:35:21
Ich sehe den Vorteil von mehreren Devices noch nicht. Würde es nicht einfacher sein die Namen der Readings einfach aus den Einstellungen der DTU zu generieren?
Also einfach das, was die Leute als Bezeichnung für ihre WR/Module eintragen, als Präfix vor die Namen der Readings zu setzen?
Aus U_DC wird dann z.B. "WR1_Modul1_U_DC", "WR1_Modul2_U-DC", "WR2_Modul1_U-DC" usw.
Wie gesagt: ich habe noch keinen wirklichen Eindruck von dem, was der AHOY-ESP wie sendet. Prinzipiell (ganz ohne dass das was mit dieser konkreten Sache hier beschränkt wäre) sehe ich "individualisierte Readingnamen" sehr skeptisch: Da muss dann jeder in FHEM wieder seine individuelle Visualisierung draus generieren, Code zur Weiterverarbeitung zu teilen ist schwieriger etc. pp.
Mehrere Devices dagegen kann man untereinander gruppieren (in FHEMWEB) bzw. ggf. mit mehr oder weniger gleichen Einstellungen nebeneinander (afaik: FTUI), um dann optisch auf einen Blick zu erfassen, was "Sache ist".
Und wenn man Geräte "an" und "aus" schalten will/muss bzw. irgendwelche "pct"-Einstellungen vornehmen (offgrid-Nutzung), tut man sich wesentlich leichter, wenn jedes angesprochene Endgerät (=> WR) als separates FHEM-Device angesprochen werden kann.
Falls jemand hier mitliest, der an der firmware mitentwickelt: Wenn man "zusammengehörende" Infos in JSON verpackt und sendet, ist das für FHEM weniger Last (pro JSON eine Event-Loop, sonst allgemein: pro empfangenem Topic).
Falls jemand bessere Ideen hat: Es wäre auch kein Problem, zwei unterschiedliche Vorgehensweisen mit aufzunehmen, es gibt ja z.B. auch für mehrkanalige Tasmota-Devices die Varianten "unified" und "split". An denen wird es vielleicht auch etwas einfacher nachzuvollziehen, wie das obige gemeint ist; ich sehe dann nur schon das Problem, dass es mehr Fragen der User generiert, was denn nun sinnvollerweise genommen werden sollte....
Ansonsten könnte ich auch vorab schon "spielen", wenn jemand ein (aktuelles) RAW-listing hier einstellen würde (falls bereits teilweise JSON übertragen wird wäre zusätzlich je mind. ein JSON-Payload hilfreich, samt der Info, zu welchem Topic er jeweils gehört).
Zitat von: TheTrumpeter am 04 August 2022, 21:19:25
Ich hole die Daten via HTTPMOD und habe das Problem daher nicht.
Verstehe aber nicht wieso das Problem überhaupt existiert. Wenn Du bei den Einstellungen jedem Wechselrichter bzw. Modul einen eigenen Namen gibst, würde ich erwarten, dass die Werte in MQTT auch unterschiedliche Namen haben.
Einen ESP8266+nRFL01+ hab ich mir jetzt auch mal zusammengebastelt. Die Version 0.4.25 läuft bei mir auch ganz stabil.
Weil bei mir kein MQTT Server läuft, habe ich jetzt auch versucht die Daten via HTTPMOD in FHEM zu holen. Leider bekomme ich es nicht hin.
Kannst du bitte mal posten wie du das eingerichtet hast?
Besten Dank
Zitat von: olde am 06 August 2022, 08:40:44
Weil bei mir kein MQTT Server läuft, habe ich jetzt auch versucht die Daten via HTTPMOD in FHEM zu holen. Leider bekomme ich es nicht hin.
Vermutlich ist es einfacher, einen MQTT2_SERVER zu aktivieren, als es mit HTTPMOD zu versuchen...:
https://wiki.fhem.de/wiki/MQTT#Schnellstart_f.C3.BCr_Ungeduldige (https://wiki.fhem.de/wiki/MQTT#Schnellstart_f.C3.BCr_Ungeduldige)
Das ging ja einfach. Läuft soweit, danke für den Tipp :)
Zitat von: olde am 06 August 2022, 08:40:44
Einen ESP8266+nRFL01+ hab ich mir jetzt auch mal zusammengebastelt. Die Version 0.4.25 läuft bei mir auch ganz stabil.
Weil bei mir kein MQTT Server läuft, habe ich jetzt auch versucht die Daten via HTTPMOD in FHEM zu holen. Leider bekomme ich es nicht hin.
Kannst du bitte mal posten wie du das eingerichtet hast?
Besten Dank
Der Trick ist, dass Du die Seite "/livedata" parsen musst.
Zitat von: Beta-User am 04 August 2022, 21:58:29
würde [...] das wieder in ein "MCU"-Basis-/Verteil-Device aufsplitten, das dann die einzelnen Wechselrichter je in ein Device weiterleitet, das dann wieder 1, 2 oder 4 (?) Kanäle für die Leistungsdaten je MPPT-Tracker hat, oder?
Nachdem es in https://www.mikrocontroller.net/topic/525778?page=11#7152250 (https://www.mikrocontroller.net/topic/525778?page=11#7152250) die Info gab, wie Steuerungsbefehle an den jeweiligen WR gesendet werden können, hier mal der erste Wurf (erst mal nur für bis zu 2 Kanäle):
Am einfachsten [....] ab morgen früh ein update machen, sind seit eben im svn.
das ganze ans Ende eurer file /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template (unterstellt, es ist ein default-Linux) packen und
{ AttrTemplate_Initialize() }
ausführen. (Achtung: es gab gestern noch wegen was anderem ein update dazu, also ggf. entweder vorher updaten oder eben warten bzw. exkludieren)
name:hoymiles_microinverter_hub_bridge
[...gelöscht, da via update aktualisiert verfügbar...]
name:hoymiles_microinverter_inverter
[...gelöscht, da via update aktualisiert verfügbar...]Das erste attrTemplate (hoymiles_microinverter_hub_bridge) wird auf das von autocreate erzeugte Device angewendet. Per bridgeRegexp sollten dann - je nach Anzahl der WR - weitere Devices erstellt werden (der Teil hat hier mit den Testdaten nicht klappen wollen, noch k.A., an was es ggf. hängt).
Auf die dann jeweils das 2. attrTemplate anwenden.
Anmerkungen:
- ch0 müßte jeweils die AC-Seite repräsentieren, daher sind die dortigen Daten nicht mit einem numerischen Index versehen (das war hier teils anders zu finden).
- ch1 bzw. ch2 müßte jeweils die DC-Seite sein. Wer also 4 Kanäle hat, bräuchte das nur entsprechend aufbohren.
- Die Nr. ist jetzt als postfix ausgestaltet. Damit sind jeweils alle "vergleichbaren" Werte aus den Kanälen untereinander gelistet, das ganze ist aber uU. künftig etwas schwieriger zu handeln, falls jemand das in der firmware MQTT-seitig dann auf JSON umstellen sollte; man könnte das also ggf. auch via prefix auseinanderdröseln.
Wer es testen will, ohne seine vorhandenen Devices zu "zerstören", kann von seinem jetzigen Device auch einfach zwei Kopien (RAW-Definitionen) nehmen; das 2. attrTemplate wird allerdings erst/nur angezeigt, wenn es ein Device vom ersten Typ gibt, und man kann damit dann auch nicht testen, ob das mit der brideRegexp klappt wie gedacht.
Zitat von: der2of6 am 26 Juli 2022, 09:59:53
Sporadische Neustarts kann ich mit der 0.4.25 nicht mehr nachvollziehen.
Bei mir läuft er tageweise ohne Reboot durch.
Nachdem trotz Tausch des Repeaters die Reboots mit der 0.4.19 geblieben sind, habe ich nun erfolgreich auf die 0.4.25 aktualisiert. (Soweit ich gesehen habe ist das die letzte Version die im Mikrokontroller-Forum zum Download angeboten wird. Alle neueren Versionen 0.4.26 bzw. 0.5.x müsste man selbst bauen bzw. einen Github-Account haben.)
Die läuft nun erstmal, nur musste ich feststellen, dass das Sendeintervall auf 15 Sekunden begrenzt wurde, mit der 0.4.19 ging noch 5 Sekunden.
Mal sehen ob es damit auch zu den Reboots kommt, dann kann ich gleich wieder auf die 0.4.19 runter.
Was anderes:
Die DTU sendet ja in der Nacht munter weiter, was komplett nutzlos ist. Eigentlich könnte mit Sonnenuntergang aufgehört werden zu senden und erst mit Sonnenaufgang wieder begonnen werden. (Oder von mir aus paar Minuten danach bzw. davor um sicher nix zu verlieren.)
Habe keinen Account im Mikrocontroller-Forum bzw. Github, vielleicht kann das mal jemand anregen der dort auch schreibt?
Anbei des aktuellste "Artifakt" - schnell sein lohnt, die wird dann auch wieder gelöscht!
Mal selber bauen ist übrigens keine schlechte Übung, v.a., weil man dann ggf. auch "bekannten Übeln" (PIN-Wahl) (EDIT: kann man ja bei dieser firmware auch per Web-Interface anpassen) aus dem Weg gehen kann...
Was mich etwas wundert: 0 feedback zu den attrTemplates bisher?
Zitat von: Beta-User am 10 August 2022, 15:44:25
Anbei des aktuellste "Artifakt" - schnell sein lohnt, die wird dann auch wieder gelöscht!
Danke, gezogen.
Zitat von: Beta-User am 10 August 2022, 15:44:25
Mal selber bauen ist übrigens keine schlechte Übung, v.a., weil man dann ggf. auch "bekannten Übeln" (PIN-Wahl) (EDIT: kann man ja bei dieser firmware auch per Web-Interface anpassen) aus dem Weg gehen kann...
Verstehe ich, meine Arduino-IDE ist aber seit 2 Jahren nicht mehr benutzt worden, drum setze ich solange es geht auf "fertiges". Setze viel ESPEasy ein, da bin ich von den
fertigen Releases in allen möglichen Konfigurationsvarianten schon sehr verwöhnt.
Zitat von: Beta-User am 10 August 2022, 15:44:25
Was mich etwas wundert: 0 feedback zu den attrTemplates bisher?
Bei mir derzeit kein Einsatz, da Auslesen über HTTPMOD stattfindet.
Zitat von: TheTrumpeter am 10 August 2022, 16:47:10
Danke, gezogen.
Oha, dazu drei weitere Downloads in der kurzen Zeit? Hab's mit dem Löschen nicht eilig, es ist aber zum einen unschön, wenn es zu viele Quellen gibt, und zum anderen veraltet das (derzeit) ja auch schnell...
Zitat
Verstehe ich, meine Arduino-IDE ist aber seit 2 Jahren nicht mehr benutzt worden, drum setze ich solange es geht auf "fertiges". Setze viel ESPEasy ein, da bin ich von den
fertigen Releases in allen möglichen Konfigurationsvarianten schon sehr verwöhnt.
Kann ich verstehen, hatte auch vor ein paar Tagen mal wieder Atom/platformIO und die Arduino-IDE in Betrieb genommen. War etwas aus der Übung, und irgendwelche "Reste", die sich so im Lauf der Zeit "irgendwo" angesammelt hatten, waren dann erst mal kein großer Spaß. Dafür habe ich jetzt die ersten Daten von meinem MI-600, und meine Junkers spricht auch mit FHEM via MQTT 8) .
Zitat
Bei mir derzeit kein Einsatz, da Auslesen über HTTPMOD stattfindet.
Schön. Idealer Ausgangspunkt, um die Darstellung via MQTT2_DEVICE (für den Rest der Welt) mal anzutesten und ggf. Rückmeldung zu geben, was nicht paßt ;D . Ginge auch auf einem anderen "Test-FHEM", notfalls sogar unter Win.* auf einem USB-Stick ;) ...
Zitat von: Beta-User am 10 August 2022, 15:44:25
Was mich etwas wundert: 0 feedback zu den attrTemplates bisher?
Was soll ich sagen?
Läuft einwandfrei.
Zitat von: costa2 am 11 August 2022, 12:45:20
Was soll ich sagen?
Läuft einwandfrei.
:)
Bedeutet: Du hast einen oder mehrere WR? Aufbau (2+ M2D-Instanzen) und "Nomenklatur" sind verständlich?
Vorschläge zur Doku sind willkommen (falls erforderlich)...
Nochmal: ich habe bisher nur "graue Theorie" und die paar Schnipsel, die hier und bei Mikrocontroler.net zu finden sind und sehe _nicht_ live, was da abgeht. Von daher wäre ggf. noch ein Vorschlag für die "event-on-change"-Attribut-Familie hilfreich (mit passenden Hysteresen etc.).
EDIT: aktuelles Artefakt angehängt (0.5.6, anscheinend läuft die MQTT-Kommunikation jetzt anders, was das timing angeht => event-on.* (!)).
Zitat von: Beta-User am 10 August 2022, 15:44:25
Anbei des aktuellste "Artifakt" - schnell sein lohnt, die wird dann auch wieder gelöscht!
Schade ich hätte auch gern getestet... 2 Minuten zu spät zu Hause :-\
Zitat von: kabanett am 11 August 2022, 15:22:01
Schade ich hätte auch gern getestet... 2 Minuten zu spät zu Hause :-\
Gelöscht, da (im darauffolgenden Post hier) 0.5.6 verfügbar gemacht wurde ;) . (unglückliches timing, sorry).
Zitat von: Beta-User am 11 August 2022, 15:23:43
Gelöscht, da (im darauffolgenden Post hier) 0.5.6 verfügbar gemacht wurde ;) . (unglückliches timing, sorry).
Danke fürs bereitstellen. Funktioniert mit Ausnahme des Device-Templates. Naja... Ich schnall einfach nicht, was für ID`s da wo hin sollen... ::)
ZitatFunktioniert mit Ausnahme des Device-Templates. Naja... Ich schnall einfach nicht, was für ID`s da wo hin sollen..
Hmmm, "eigentlich" sollte nur der dritte Teil der Abfrage kommen, und die auch nur, wenn es das erste Mal ist...
An sich sollten die Parameter aufgelöst werden können, sobald die AC-Daten einmal gesendet worden sind - dann hat die readingList nämlich (hoffentlich) die Daten, die benötigt werden, um das automatisiert zu machen.
Auch manuell ist es nicht sooo schwierig:
die LONG... ist der Topic einschl. des von dir vergeben Präfixes (hier war dafür mal "inverter1" gezeigt gewesen, das ist gleichzeitig die BASE_ID) und der Benennung des WR im ESP also sowas "inverter1/beispiel".
Ich habe das Template benutzt für meinen HM-400.
Hat soweit funktioniert, allerdings sind die Readings für "version" und "device" im Bridge-Device nicht direkt wieder aufgetaucht. Erst nach Neustart des esp kamen die dann.
Dabei wurden folgende Einträge zur ReadingsList hizugefügt:
esp_ahoy:homeassistant/sensor/Balkon/ch1_U_DC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch1_I_DC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch1_P_DC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch1_YieldDay/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch1_YieldTotal/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch1_Irradiation/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_U_AC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_I_AC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_P_AC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_P_ACr/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_Freq/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_Temp/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_ALARM_MES_ID/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_P_DC/config:.* { json2nameValue($EVENT) }
esp_ahoy:homeassistant/sensor/Balkon/ch0_Efficiency/config:.* { json2nameValue($EVENT) }
Die hatte das automatisch erzeugte "Urdevice" auch. Ich habe sie einmal gelöscht, was die Funktion erstmal nicht beeinflusst hat. Bei einem erneiten ESP-Neustart wurden sie wieder angelegt.
Als MQTT-Noob die Frage: Wozu dienen diese Zeilen?
PS: mit der oben angehängten V0.5.7 gabs bei mir kein MQTT connect.
Der Device-Name schien nicht übernommen zu werden. In der V0.5.6 ist die Konfig-Seite noch nicht überarbeitet, da läuft es.
Jetzt wollte ich das Limit mal verstellen.
attr Hoymiles limit 150
wird zu
attr Hoymiles limit set 150
Es werden aber nach wie vor über 200W produziert.
Im Atrr setList steht
on:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/0 on
off:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/1 off
limit esp_ahoy:Balkon/devcontrol/INVERTER_NR/11 $EVTPART1
reboot:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/2 restart
Das wurde vom Template eingetragen.
Wie schaltet man die Limitierung wieder aus? (... wenn sie den ginge...) Einfach die maximale Leistung eintragen?
Zitat von: HeikoE am 12 August 2022, 10:20:01
Ich habe das Template benutzt für meinen HM-400.
Hat soweit funktioniert,
:)
Zitat
allerdings sind die Readings für "version" und "device" im Bridge-Device nicht direkt wieder aufgetaucht. Erst nach Neustart des esp kamen die dann.
Dieses Verhalten ist relativ normal, das Setzen von bridgeRegexp löscht (prinzipiell und immer) mehr oder weniger alle Readings, die werden erst wieder angelegt, wenn neue Daten kommen. In anderen Fällen senden wir daher einen reboot-Befehl an den ESP, aber hier weiß ich noch nicht, ob und wie das ggf. ginge (und erwünscht ist!).
Zitat
Dabei wurden folgende Einträge zur ReadingsList hizugefügt:
esp_ahoy:homeassistant/sensor/Balkon/ch1_U_DC/config:.* { json2nameValue($EVENT) }
Das ist ein Thema, das man am IO "erschlagen" sollte (prinzipiell und immer!), siehe die Beschreibung zu "ignoreRegexp" im Wiki zu MQTT2_CLIENT. Anders gesagt: Man sollte die HomeAssistant-autocreate-Infos auch abschalten können (auf dem ESP).
Zitat
PS: mit der oben angehängten V0.5.7 gabs bei mir kein MQTT connect.
Der Device-Name schien nicht übernommen zu werden. In der V0.5.6 ist die Konfig-Seite noch nicht überarbeitet, da läuft es.
Version von gestern wieder anbei.
Bug-reports bitte entweder auf github oder im MC-Forum. Wer mag und versteht, was gemeint ist, kann gleich noch JSON als Sendeoption für alle gemeinsam ausgelesenen Datenfelder und LWT auf die dortige Stichwortliste setzen, super wäre auch, wenn man Hysteresen und Zeitgrenzen setzen könnte (z.B. spätestens alle 5 Minuten, wenn aktualisiert, zwischendurch nur, wenn mehr wie +/- 10 W oder +/-10% zum letzten gesendeten Wert). Sonst müssten wir eine myUtils für sowas basteln...
Zitat von: HeikoE am 12 August 2022, 10:46:10
Jetzt wollte ich das Limit mal verstellen.
attr Hoymiles limit 150
wird zu
attr Hoymiles limit set 150
Das müßte jeweils "set" sein bzw. der Reading-Wert?
Zitat
Es werden aber nach wie vor über 200W produziert.
Im Atrr setList steht u.a
limit esp_ahoy:Balkon/devcontrol/INVERTER_NR/11 $EVTPART1
Das mit der CID vorneweg ist ein (doppelter) Bug!
Bitte ändern in
limit Balkon/devcontrol/0/11 $EVTPART1
Und dann nochmal versuchen.
Wie sind die Daten da reingekommen? Hattest du das so in das Dialogfeld eingetragen oder war das das attrTemplate direkt?
Wenn ja, hätte ich gerne ein vollständiges RAW-Listing VOR der Anwendung des 2. attrTemplate (also Device einfach löschen und warten, bis es angelegt ist). Sonst kann ich nicht/schlecht testen...
Zitat von: Beta-User am 12 August 2022, 10:55:47
Bug-reports bitte entweder auf github oder im MC-Forum.
Steht schon auf Github.
Zitat von: Beta-User am 12 August 2022, 10:55:47
Wie sind die Daten da reingekommen? Hattest du das so in das Dialogfeld eingetragen oder war das das attrTemplate direkt?
Ich hatte im automatisch entstandenen "Urdevice"
set Balkonsolar attrTemplate hoymiles_microinverter_hub_bridgeausgeführt. Das hat wie erwähnt alle Readings gelöscht und im attr readingList
Balkon/version:.* version
Balkon/free_heap:.* free_heap
Balkon/uptime:.* uptime
Balkon/device:.* device
eingetragenn sowie im attr setList
on:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/0 on
off:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/1 off
limit esp_ahoy:Balkon/devcontrol/INVERTER_NR/11 $EVTPART1
reboot:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/2 restart
Nach einer Zeit wurde das neue Device mit den Leistungsdaten automatisch angelegt. Da habe ich nichts mehr gemacht.
Das attr readingList ist da direkt so gewesen:
Balkon/Balkon/ch1/U_DC:.* U_DC
Balkon/Balkon/ch1/I_DC:.* I_DC
Balkon/Balkon/ch1/P_DC:.* P_DC
Balkon/Balkon/ch1/YieldDay:.* YieldDay
Balkon/Balkon/ch1/YieldTotal:.* YieldTotal
Balkon/Balkon/ch1/Irradiation:.* Irradiation
Balkon/Balkon/ch1/name:.* name
Balkon/Balkon/ch0/U_AC:.* U_AC
Balkon/Balkon/ch0/I_AC:.* I_AC
Balkon/Balkon/ch0/P_AC:.* P_AC
Balkon/Balkon/ch0/P_ACr:.* P_ACr
Balkon/Balkon/ch0/Freq:.* Freq
Balkon/Balkon/ch0/Temp:.* Temp
Balkon/Balkon/ch0/P_DC:.* P_DC
Balkon/Balkon/ch0/Efficiency:.* Efficiency
Balkon/Balkon/ch0/ALARM_MES_ID:.* ALARM_MES_ID
Zitat von: Beta-User am 12 August 2022, 10:55:47
Bitte ändern in
limit Balkon/devcontrol/0/11 $EVTPART1
Und dann nochmal versuchen.
Habe ich gemacht, es geht aber immer noch nicht.
Ursprünglich stand da noch "esp_ahoy:" vor Balkon. Es geht aber weder mit noch ohne.
Mit Auswahl von limit aus der dropdown-Liste wird anscheinend der Eintrag vom reading "limit" übernommen, und immer mit Klick auf "set" um den Text "set" ergänzt.
also
set Balkonsolar limit 150
Klick auf set...
set Balkonsolar limit set 150
Klick auf set...
set Balkonsolar limit set set 150
...
Zitat von: Beta-User am 12 August 2022, 10:55:47
Wenn ja, hätte ich gerne ein vollständiges RAW-Listing VOR der Anwendung des 2. attrTemplate (also Device einfach löschen und warten, bis es angelegt ist). Sonst kann ich nicht/schlecht testen...
Ein zweites mal habe ich kein Template angewendet.
Zitat von: HeikoE am 12 August 2022, 11:56:59
Habe ich gemacht, es geht aber immer noch nicht.
Ursprünglich stand da noch "esp_ahoy:" vor Balkon. Es geht aber weder mit noch ohne.
Sorry, ich war zu ungeduldig.
mit
set Balkonsolar limit 150
wird die Leistung begrenzt, allerdings nicht auf 150,0 sondern z.B. 153,5. Da dachte ich, eine Wolke hätte sich ausgewirkt
Im attr setList steht jetzt
on:noArg Balkon/devcontrol/0/0 on
off:noArg Balkon/devcontrol/0/1 off
limit Balkon/devcontrol/0/11 $EVTPART1
reboot:noArg Balkon/devcontrol/0/2 restart
PS: Nach
set Balkonsolar limit set 150
startet der ESP neu.
Zitat von: HeikoE am 12 August 2022, 11:56:59
Ich hatte im automatisch entstandenen "Urdevice"
set Balkonsolar attrTemplate hoymiles_microinverter_hub_bridge
ausgeführt. Das hat wie erwähnt alle Readings gelöscht und [...] im attr setList
on:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/0 on
off:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/1 off
limit esp_ahoy:Balkon/devcontrol/INVERTER_NR/11 $EVTPART1
reboot:noArg esp_ahoy:Balkon/devcontrol/INVERTER_NR/2 restart
Die setList wird nach meinem Verständnis nur gesetzt, wenn man das 2. attrTemplate auch noch setzt, und zwar (versehentlich) auf das bereits fertig konfigurierte Ausgangsdevice.
ZitatNach einer Zeit wurde das neue Device mit den Leistungsdaten automatisch angelegt. Da habe ich nichts mehr gemacht.
Das attr readingList ist da direkt so gewesen:
Das paßt nur auf einen Einkanaligen Inverter, was aber vermutlich auf den HM-400 zutrifft. Aber da gehört die setList (die einzenlen Zeilen
ohne den CID-Teil vor dem Topic!) eigentlich hin
Zitat
Mit Auswahl von limit aus der dropdown-Liste wird anscheinend der Eintrag vom reading "limit" übernommen, und immer mit Klick auf "set" um den Text "set" ergänzt.
[...]
Ja, das ist die Folge von "setStateList" und der (von dir? dazugepackten) dropdown-Liste. Da (bisher) nicht rückgemeldet wird, dass das erfolgreich war (reine Nummer kommt zurück), kommt da im Reading-Inhalt das "set " dazu. Erwartet wird aber eine reine Nummer => das muss man händisch machen, über FHEMWEB geht es erst, wenn der Rückkanal ggf. da ist (oder wir das auf der FHEM-Seite kompensieren).
Ich hatte extra ein Freitext-Feld vorgesehen, damit solche Effekte erst mal kompensiert werden :( .
Anmerkung:
Falls da jemand im Hintergrund "gute Tipps" geben sollte: Bitte aufhören, wie ihr seht ist das KONTRAPRODUKTIV, weil es keiner nachvollziehen kann, der die Diskussion nicht kennt!
Das mit dem reboot ist interessant zu wissen, m.E. ist das ein firmwarebug, der zu beheben ist; jedenfalls werde ich das nicht als "reboot"-Kommando implementieren 8) .
Zitat von: Beta-User am 12 August 2022, 12:18:55
Das paßt nur auf einen Einkanaligen Inverter, was aber vermutlich auf den HM-400 zutrifft.
Stimmt, HM400 hat einen Kanal
Zitat von: Beta-User am 12 August 2022, 12:18:55
Ja, das ist die Folge von "setStateList" und der (von dir? dazugepackten) dropdown-Liste.
Ich habe dahingehend nichts dazugepackt. Ich meine den Auswahldialod der Weboberfläche.
Ich hänge auch mal ein List der beiden Devices an.
Danke vorab mal für das/die lists (RAW-Format wäre noch einfacher gewesen, aber so ist es auch ok).
Da war noch was schräg beim Auswerten der Parameter am 2. Device, update folgt bei Gelegenheit über's svn - dann gleich mit Auswahlmöglichkeit für die Anzahl der Kanäle. Sowas findet man aber leider nur, wenn man Spielmaterial hat...
Was das set ... limit angeht, kommt doch dann ein Freitextfeld, oder ist das bei diesem Style anders. Da kann man im Prinzip was beliebiges eintragen, also insbesondere auch den (internen Zusatz) "set " entfernen. Versendet wird effektiv jedenfalls $EVTPART1, was der ersten Zeichenkette entspricht - also bei "set set 400" dann eben das 1. "set". Schreibt man da "150 bla blub" rein, wird "150" versendet.
Die setList hatte ich übrigens dazugepackt, weil irgendwo stand, wie die strukturell aussehen müßte. Dass es sie gibt bedeutet aber nicht, dass mir klar wäre, wie sie sinnvoll zu verwenden wäre ::) ... Vermutet hatte ich schon, dass es eine Zahl sein sollte, aber für eine Vorgabe (z.B. per BRI-Slider) fehlte mir noch ein sinnvoller Wertebereich... Von daher wird die kommende Fassung sicher nicht die letzte sein ;D ...
Anbei auch wieder ein Artefakt (0.5.10), wie üblich ohne Gewähr auf Funktionalität...
Wie ist denn das kleinste Abfrageintervall in den 0.5.x Versionen gesetzt?
Die 0.4.26 läuft nun seit ein paar Tagen ohne jegliche Auffälligkeit oder Reboot durch. Allerdings könnte das auch nur am Abfrageintervall liegen, vor dem Versionssprung hatte ich 5 Sekunden.
Hab gestern den ahoy-Transceiver zusammengebastelt. Heute mein Panel besorgt und installiert und das letzte Licht hat noch die ersten Daten produziert. Sehr, sehr coole Arbeit! Vielen Dank!
defmod MQTT2_balcony_ MQTT2_DEVICE balcony_
attr MQTT2_balcony_ IODev mqttBroker
attr MQTT2_balcony_ autocreate 1
attr MQTT2_balcony_ bridgeRegexp balcony/([^/]+)/ch[0-9]+/.*:.* "balcony_$1"
attr MQTT2_balcony_ icon solar_icon
attr MQTT2_balcony_ model hoymiles_microinverter_hub_bridge
attr MQTT2_balcony_ readingList balcony/version:.* version\
balcony/free_heap:.* free_heap\
balcony/uptime:.* uptime\
balcony/device:.* device\
balcony_:/HM-300/ch1/U_DC:.* U_DC\
balcony_:/HM-300/ch1/I_DC:.* I_DC\
balcony_:/HM-300/ch1/P_DC:.* P_DC\
balcony_:/HM-300/ch1/YieldDay:.* YieldDay\
balcony_:/HM-300/ch1/YieldTotal:.* YieldTotal\
balcony_:/HM-300/ch1/Irradiation:.* Irradiation\
balcony_:/HM-300/ch0/U_AC:.* U_AC\
balcony_:/HM-300/ch0/I_AC:.* I_AC\
balcony_:/HM-300/ch0/P_AC:.* P_AC\
balcony_:/HM-300/ch0/P_ACr:.* P_ACr\
balcony_:/HM-300/ch0/Freq:.* Freq\
balcony_:/HM-300/ch0/Temp:.* Temp\
balcony_:/HM-300/ch0/ALARM_MES_ID:.* ALARM_MES_ID\
balcony_:/HM-300/ch0/P_DC:.* P_DC\
balcony_:/HM-300/ch0/Efficiency:.* Efficiency\
balcony_:/uptime:.* uptime
attr MQTT2_balcony_ room balcony solar,MQTT2_DEVICE
attr MQTT2_balcony_ setStateList on off
setstate MQTT2_balcony_ 2022-08-15 20:47:08 ALARM_MES_ID 6.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 Efficiency 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 Freq 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 I_AC 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 I_DC 0.050
setstate MQTT2_balcony_ 2022-08-15 20:47:08 Irradiation 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 P_AC 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 P_ACr 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 P_DC 1.200
setstate MQTT2_balcony_ 2022-08-15 20:47:08 Temp 26.400
setstate MQTT2_balcony_ 2022-08-15 20:47:08 U_AC 0.800
setstate MQTT2_balcony_ 2022-08-15 20:47:08 U_DC 23.500
setstate MQTT2_balcony_ 2022-08-15 20:47:08 YieldDay 0.000
setstate MQTT2_balcony_ 2022-08-15 20:47:08 YieldTotal 0.000
setstate MQTT2_balcony_ 2022-08-15 20:27:54 attrTemplateVersion 20200812
setstate MQTT2_balcony_ 2022-08-15 21:14:38 uptime 3349
Das IODev war noch falsch gesetzt, bis jetzt habe ich nur Daten empfangen.
Muss morgen mal sehen, ob die setList dann erzeugt wird. Die fehlt bis jetzt noch.
@laserichi: Falls du noch hier mitliest: der MI-600 sollte in greifbare Nähe rücken...
@thymjan:
setList wird nie automatisch angelegt. Auf das erstellte Device das 1. attrTemplate anwenden, dann die Anwendungshinweise zum 2. beachten... (Und Rückmeldung geben).
IODev bitte händisch korrigieren!
OT
Zitat@laserichi: Falls du noch hier mitliest: der MI-600 sollte in greifbare Nähe rücken...
Darf man fragen was er dir zur Zeit Wert war ihn zu bestellen ?
Zitat von: TomLee am 15 August 2022, 21:55:51
Darf man fragen was er dir zur Zeit Wert war ihn zu bestellen ?
Diese Info wäre a) nicht "zur Zeit" (der werkelt schon eine Weile vor sich hin), und würde dir
b) nichts bringen, weil das Gerät technisch schon wieder veraltet ist (und vermutlich auch nicht mehr erhältlich).
Die "MI-Serie" ist "2. Generation" (Seriennummern beginnend mit 10xx), aktuell verkauft (wenn verfügbar) werden 3. Generation (Seriennummern 11xx).
Das war auch der Grund, warum ich speziell @laserichi genannt hatte: Er scheint auch einen von diesen "frühen" im Bestand zu haben, und mit denen spricht "ahoy" noch nicht, weil die in einem etwas anderen Dialekt funken. Es gibt aber ein paar Varianten der "ersten Fassung" des im "ahoy-repo" enthaltenen Sketches, mit der man zumindest mal Daten von diesen Geräten aus der 2. Generation erhalten kann. Also falls jemand mitliest, der ein Gerät mit Seriennummer 10xx hat: in dem Thread bei Mikrocontroller.net einklinken...
Zitat von: TheTrumpeter am 15 August 2022, 13:59:19
Die 0.4.26 läuft nun seit ein paar Tagen ohne jegliche Auffälligkeit oder Reboot durch. Allerdings könnte das auch nur am Abfrageintervall liegen, vor dem Versionssprung hatte ich 5 Sekunden.
Wie schaffe ich es denn die Sourcen zu genau dieser Version aus Git zu bekommen?
In der aktuellen Version finde ich in der "defines.h" in Zeile 70/71:
// minimum send interval
#define MIN_SEND_INTERVAL 15
Würd' das gerne mit 5 Sekunden übersetzen um zu sehen, ob die 0.4.26 tatsächlich besser als meine alte Version ist oder die vermeintliche Stabilität nur durch die geringere Sende-/Empfangsfrequenz "passiert".
EDIT: Denke ich hab's gefunden... werd' mich dann in den nächsten Tagen wohl ans Aktualisieren der Build-Umgebung machen.
Hallo
@Beta-User
Vielen Dank fürs bereitstellen der Firmware!!!
Bedingt durch die Version 0.5.12, die keine meiner Einstellungen übernommen hat, habe ich die Devices in fhem gelöscht. Wollte eh mal neu starten... ;)
Nach der Konfiguration des ESP wurde mir die DTU angelegt.
Internals:
CFGFN
CID AHOY_DTU
DEF AHOY_DTU
FUUID 62fba702-f33f-0fc8-8859-21d3698c5a1cfa29
IODev MQTT2_Server
LASTInputDev MQTT2_Server
MQTT2_Server_CONN MQTT2_Server_192.168.xx.xx_54520
MQTT2_Server_MSGCNT 901
MQTT2_Server_TIME 2022-08-16 17:28:31
MSGCNT 901
NAME MQTT2_AHOY_DTU
NR 50606
STATE ???
TYPE MQTT2_DEVICE
eventCount 952
.DT:
DEVICETOPIC MQTT2_AHOY_DTU
.attraggr:
.attrminint:
OLDREADINGS:
READINGS:
2022-08-16 16:19:25 attrTemplateVersion 20200808
2022-08-16 17:13:22 ch0_ miniPV/
2022-08-16 17:20:06 dev_cla power
2022-08-16 17:20:06 dev_cu http://192.168.xx.xx
2022-08-16 17:20:06 dev_ids 11xxxxxxxxxx
2022-08-16 17:20:06 dev_mf Hoymiles
2022-08-16 17:20:06 dev_name Solar_Pavillon
2022-08-16 17:19:51 device AHOY-DTU
2022-08-16 17:20:06 exp_aft 80
2022-08-16 17:20:06 name Solar_Pavillon Efficiency
2022-08-16 17:20:06 stat_cla measurement
2022-08-16 17:20:06 stat_t miniPV/Solar_Pavillon/ch0/Efficiency
2022-08-16 17:20:06 uniq_id 11xxxxxxxxxx_ch0_Efficiency
2022-08-16 17:20:06 unit_of_meas %
2022-08-16 17:28:31 uptime 524
2022-08-16 17:19:51 version 0.5.13
Attributes:
autocreate 1
bridgeRegexp miniPV/([^/]+)/ch[0-9]+/.*:.* "miniPV_$1"
icon solar
model hoymiles_microinverter_hub_bridge
readingList miniPV/version:.* version
miniPV/free_heap:.* free_heap
miniPV/uptime:.* uptime
miniPV/device:.* device
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch1_U_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch1_I_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch1_P_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch1_YieldDay/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch1_YieldTotal/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch1_Irradiation/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch2_U_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch2_I_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch2_P_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch2_YieldDay/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch2_YieldTotal/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch2_Irradiation/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_U_AC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_I_AC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_P_AC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_P_ACr/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_Freq/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_Temp/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_ALARM_MES_ID/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_YieldDay/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_YieldTotal/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_P_DC/config:.* { json2nameValue($EVENT) }
AHOY_DTU:homeassistant/sensor/Solar_Pavillon/ch0_Efficiency/config:.* { json2nameValue($EVENT) }
AHOY_DTU:miniPV/Solar_Pavillon/ch0\x27:.* ch0_
room MQTT2_DEVICE
setStateList on off
Danach ist der Inverter angelegt.
Internals:
CFGFN
CID miniPV_Solar_Pavillon
DEF miniPV_Solar_Pavillon
FUUID 62fbaa5c-f33f-0fc8-86a3-21312f0070d65d51
IODev MQTT2_Server
LASTInputDev MQTT2_Server
MQTT2_Server_CONN MQTT2_Server_192.168.xx.xx_54520
MQTT2_Server_MSGCNT 13870
MQTT2_Server_TIME 2022-08-16 17:30:46
MSGCNT 13870
NAME MQTT2_miniPV_Solar_Pavillon
NR 50790
STATE ???
TYPE MQTT2_DEVICE
eventCount 13893
.DT:
DEVICETOPIC MQTT2_miniPV_Solar_Pavillon
.attraggr:
.attrminint:
READINGS:
2022-08-16 17:30:46 ALARM_MES_ 4.000
2022-08-16 17:30:46 Efficiency 95.174
2022-08-16 17:30:46 Freq 49.990
2022-08-16 16:31:56 IODev MQTT2_Server
2022-08-16 17:30:45 I_AC 0.920
2022-08-16 17:30:45 I_DC 3.570
2022-08-16 17:30:45 Irradiatio 28.175
2022-08-16 17:30:45 P_AC 213.000
2022-08-16 17:30:46 P_ACr 0.200
2022-08-16 17:30:46 P_DC 223.800
2022-08-16 17:30:46 Temp 40.400
2022-08-16 17:30:45 U_AC 230.700
2022-08-16 17:30:45 U_DC 31.600
2022-08-16 17:30:46 YieldDay 2393.000
2022-08-16 17:30:46 YieldTotal 39.735
2022-08-16 16:31:59 associatedWith MQTT2_AHOY_DTU
Attributes:
readingList miniPV/Solar_Pavillon/ch1/U_DC:.* U_DC
miniPV/Solar_Pavillon/ch1/I_DC:.* I_DC
miniPV/Solar_Pavillon/ch1/P_DC:.* P_DC
miniPV/Solar_Pavillon/ch1/YieldDay:.* YieldDay
miniPV/Solar_Pavillon/ch1/YieldTotal:.* YieldTotal
miniPV/Solar_Pavillon/ch1/Irradiatio:.* Irradiatio
miniPV/Solar_Pavillon/ch2/U_DC:.* U_DC
miniPV/Solar_Pavillon/ch2/I_DC:.* I_DC
miniPV/Solar_Pavillon/ch2/P_DC:.* P_DC
miniPV/Solar_Pavillon/ch2/YieldDay:.* YieldDay
miniPV/Solar_Pavillon/ch2/YieldTotal:.* YieldTotal
miniPV/Solar_Pavillon/ch2/Irradiatio:.* Irradiatio
miniPV/Solar_Pavillon/ch0/U_AC:.* U_AC
miniPV/Solar_Pavillon/ch0/I_AC:.* I_AC
miniPV/Solar_Pavillon/ch0/P_AC:.* P_AC
miniPV/Solar_Pavillon/ch0/P_ACr:.* P_ACr
miniPV/Solar_Pavillon/ch0/Freq:.* Freq
miniPV/Solar_Pavillon/ch0/Temp:.* Temp
miniPV/Solar_Pavillon/ch0/ALARM_MES_:.* ALARM_MES_
miniPV/Solar_Pavillon/ch0/YieldDay:.* YieldDay
miniPV/Solar_Pavillon/ch0/YieldTotal:.* YieldTotal
miniPV/Solar_Pavillon/ch0/P_DC:.* P_DC
miniPV/Solar_Pavillon/ch0/Efficiency:.* Efficiency
room MQTT2_DEVICE
Wenn ich hier das Template anwende, bekomme ich folgende Meldung
Unknown command miniPV/Solar_Pavillon/ch0/U_AC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch0/I_AC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch0/P_AC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch0/Freq:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch0/Temp:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch0/YieldDay:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch0/YieldTotal:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch1/I_DC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch1/P_DC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch1/YieldDay:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch1/YieldTotal:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch2/I_DC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch2/P_DC:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch2/YieldDay:.*, try help.
Unknown command miniPV/Solar_Pavillon/ch2/YieldTotal:.*, try help.
Unknown command miniPV/devcontrol/0/0, try help.
Unknown command miniPV/devcontrol/0/1, try help.
Unknown command miniPV/devcontrol/0/11, try help.
Unknown command miniPV/devcontrol/0/2, try help.
Bestätige ich das mit OK, bleibt als Reading "Irradiatio" über. Dieses ist immer mal wieder Blitzartig für Millisekunden riesig und dann wieder nur ein kleiner Zahlenwert.
Ich mache hier sicher etwas falsch und komme nicht drauf...
Achja, reboot und ein paar Minuten warten zwischen jeder Aktion habe ich gemacht und mit Version 0.5.13 ist es auch nicht besser.
Gruß
Hatte eigentlich gedacht, dass die regexp im attrZemlate jetzt passt... Bist du auf dem letzten Stand, was FHEM anbelangt?
Zitat von: Beta-User am 16 August 2022, 18:01:56
Hatte eigentlich gedacht, dass die regexp im attrZemlate jetzt passt... Bist du auf dem letzten Stand, was FHEM anbelangt?
Scheinbar nicht! Ich mach ein Update...
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
fhem
List of new / modified files since last update:
UPD FHEM/55_PIFACE.pm
UPD FHEM/lib/AttrTemplate/mqtt2.template
Ja schaut gut aus!
Muss ich wohl die letzten Tage hier überlesen haben, dass du Änderungen vorgenommen hast. Sorry! und nochmals DANKE!
Zitat von: TheTrumpeter am 16 August 2022, 14:55:52
Wie schaffe ich es denn die Sourcen zu genau dieser Version aus Git zu bekommen?
In der aktuellen Version finde ich in der "defines.h" in Zeile 70/71:
// minimum send interval
#define MIN_SEND_INTERVAL 15
Würd' das gerne mit 5 Sekunden übersetzen um zu sehen, ob die 0.4.26 tatsächlich besser als meine alte Version ist oder die vermeintliche Stabilität nur durch die geringere Sende-/Empfangsfrequenz "passiert".
EDIT: Denke ich hab's gefunden... werd' mich dann in den nächsten Tagen wohl ans Aktualisieren der Build-Umgebung machen.
Das ging unerwartet problemlos...
Anbei die 0.4.26 mit Sendeintervall auf 1
// minimum send interval
#define MIN_SEND_INTERVAL 1
Rest ist unverändert, werde es morgen mal aufspielen.
EDIT: Habe gestern Abend dann noch gesehen, dass ich die 0.4.25 hatte, also habe ich noch die 0.4.25 auch mit 1s Intervall gebaut und diese nun heute draufgespielt. Läuft auf Anhieb, Abfrageintervall habe ich nun wieder auf 5 Sekunden gestellt so wie ich es früher hatte. Mal sehen wie stabil das nun läuft. (Grad heute Nacht hatte ich mit der "Original" 0.4.25 den ersten Reboot, aber nach ca. 1 Woche Laufzeit ist das ok.)
Die zuletzt von Beta-User bereitgestellte Version 0.5.13 ist nach der Installation pauschal schon auf 5 Sekunden eingestellt.
Ich habe diese ersteinmal auf 15 Sekunden hochgesetzt, da ich so viel Daten und Traffic nicht haben möchte und überlege den Intervall noch weit aus höher zu setzen.
Wo liegt denn der Vorteil, Daten so häufig zu bekommen?
Zitat von: kabanett am 17 August 2022, 08:26:00
Wo liegt denn der Vorteil, Daten so häufig zu bekommen?
Smartmeter und Wechselrichter werden asynchron abgefragt, um den tatsächlichen Strombedarf zu ermitteln. Je höher die Abfrageintervalle sind, desto größer kann der Fehler sein.
Wenn sich die Daten nur minimal ändern, fange ich das über "event-on-change"-Attribut ab, sodass die Datenflut "unsichtbar" bleibt.
a) Es gibt "schon wieder" ein update des "interver"-attrTemplate (für die diversen neuen limit-Varianten).
b) Habe ich arge Zweifel, ob ein update-Interval <5 aus technischen Gründen auf der ESP-Seite sinnvoll ist: Je Kanal braucht es (mind.) eine Message von Seiten des WR. Die muss angefragt werden. Kommt eine der beiden Messages (Anfrage+Antwort) nicht an, ändert sich so oder so nichts, und wieder ist eine Sekunde um. Weiß aber (noch) nicht, ob das Intervall nicht auch Einfluss darauf hat, wann der ESP versucht, wieder eine neue "Kollekte" zu starten... Ist letzteres der Fall, wäre die kürzere Anfrage kontraproduktiv.
MAn. müßte man ggf. mal prüfen, ob man nicht bestimmte Hysterese-Prüfungen nicht direkt auf dem ESP erledigen könnte und dafür ggf. kurzfristige Messages versendet, falls sich was gravierendes ändert. Wenn man z.B. 2 Minuten einstellt, und es schiebt sich eine Wolke dazwischen, ist das auch nach 10 Sekunden nach dem letzten Senden interessant...
Zitat von: Beta-User am 17 August 2022, 09:17:13
b) Habe ich arge Zweifel, ob ein update-Interval <5 aus technischen Gründen auf der ESP-Seite sinnvoll ist: Je Kanal braucht es (mind.) eine Message von Seiten des WR. Die muss angefragt werden. Kommt eine der beiden Messages (Anfrage+Antwort) nicht an, ändert sich so oder so nichts, und wieder ist eine Sekunde um. Weiß aber (noch) nicht, ob das Intervall nicht auch Einfluss darauf hat, wann der ESP versucht, wieder eine neue "Kollekte" zu starten... Ist letzteres der Fall, wäre die kürzere Anfrage kontraproduktiv.
Erstmal will ich nur die 5s wieder haben, was ich jetzt auch eingestellt habe, um zu prüfen, ob die neue Version tatsächlich "stabiler" in Hinblick auf die unmotivierten Reboots ist oder es einfach eine Begleiterscheinung der längeren Intervalle war/ist.
Zitat von: Beta-User am 17 August 2022, 09:17:13
MAn. müßte man ggf. mal prüfen, ob man nicht bestimmte Hysterese-Prüfungen nicht direkt auf dem ESP erledigen könnte und dafür ggf. kurzfristige Messages versendet, falls sich was gravierendes ändert. Wenn man z.B. 2 Minuten einstellt, und es schiebt sich eine Wolke dazwischen, ist das auch nach 10 Sekunden nach dem letzten Senden interessant...
Die Frage ist, wie der ESP das machen soll. Um die "Wolke" zu erkennen, muss er ja erst Recht in kurzen Intervallen abfragen. Ob der WR dann die "Filterung" übernimmt und bei geringer Änderung gar nicht erst an FHEM sendet oder das FHEM im Nachgang übernimmt, ist bzgl. Deiner obigen Bedenken doch erstmal egal.
Wenn man das Abfragen "von außen anstoßen" könnte, würde die Welt schon ganz anders ausschauen. Ich habe beispielsweise an der Beschattungssteuerung einen Lichtsensor, den ich auch abfrage. Ich könnte dann bei sprunghafter Änderung des Helligkeitswerts eine "Sonderabfrage" anstoßen. (Zwar müsste ich dann dort das Einleseintervall deutlich erhöhen, aber da die Beschattungssteuerung jede Änderung ohnehin auf den Bus legt, müsste ich das Abtastintervall einfach nur verringern.)
Wenn man keinen Lichtsensor hat, könnte man diverse andere Datenquellen verwenden, entweder den aktuellen Einspeisewert vom Smartmeter oder die Stromstärker des Außenleiters auf dem die PV-Anlage hängt. Man könnte auch eine Zwischensteckdose mit Strommessfunktion verwenden, aber dann hat man die Leistung ohenhin schon, wozu braucht man dann noch die weiteren Werte?
Zitat von: TheTrumpeter am 17 August 2022, 10:10:48
Erstmal will ich nur die 5s wieder haben, was ich jetzt auch eingestellt habe, um zu prüfen, ob die neue Version tatsächlich "stabiler" in Hinblick auf die unmotivierten Reboots ist oder es einfach eine Begleiterscheinung der längeren Intervalle war/ist.
Das wäre eher eine Frage im Zusammenhang mit "Last Will" und/oder der Überwachung eines uptime-Readings oä..
Zitat
Die Frage ist, wie der ESP das machen soll. Um die "Wolke" zu erkennen, muss er ja erst Recht in kurzen Intervallen abfragen. Ob der WR dann die "Filterung" übernimmt und bei geringer Änderung gar nicht erst an FHEM sendet oder das FHEM im Nachgang übernimmt, ist bzgl. Deiner obigen Bedenken doch erstmal egal.
Es "muss" m.E. nicht unbedingt in kurzen Intervallen abfragen, sondern es sollte berücksichtigt werden, ob der WR eigentlich schon bereit sein kann. Wenn alles sehr gut synchronisiert ist, sollte es möglich sein, tatsächlich alle 5 Sekunden Daten zu erhalten, die unterhalb dieser Schwelle vom WR gesendet worden waren.
Aber im Prinzip tut man gut daran, sowohl den ESP "werkeln" zu lassen wie auch den WR dann Daten senden zu lassen, wenn grade die passende Zeit dafür ist...
Erster Reboot nach ca. 3,5h. Kann natürlich Zufall gewesen sein, aber daran glaube ich eher nicht.
Muss dann noch dem Code durchschauen, weil ich sehen will wie die "Max retries per payload" genau verwendet werden. "0" nimmt er dort nicht, drum vermute ich, dass es keine Wiederholanzahl sondern Gesamtsendeanzahl darstellt. Falls es doch die Wiederholungen sind, könnte ich die natürlich auf "0" setzen.
Umgekehrt scheint grundsätzlich nicht viel verloren zu gehen, weil "receive fail" tagsüber sehr klein ist.
Hallo,
zunächst mal vielen Dank @Beta-User für die Bereitstellung der Firmware. Als quasi Neueinsteiger benötige ich leider eure Hilfe dazu.
Ausgangslage: ich habe einen HM-350. Diesen konnte ich bisher mit der AHOY-DTU-Firmware 0.4.25 erfolgreich auslesen und die Werte in FHEM per MQTT2_Device darstellen.
Nun bin ich auf diesen Thread gestoßen. Da ich die Begrenzung der Ausgangsleistung gut gebrauchen könnte, habe ich 2 der Firmware-Versionen herunter geladen: 0.5.10 und 0.5.14. Die letzte Version läuft leider nicht, keine Verbindung möglich.
Die 0.5.10 läuft. Im Setup die gleichen Daten eingegeben wie beim bisherigen Device. Neustart. Werte vom HM-350 treffen im MQTT2-Device ein. Sah also gut aus.
Dann habe ich das Template hoymiles_microinverter_hub_bridge angewendet. Danach hatte ich 2 MQTT2-Devices: MQTT2_AHOY_DTU (Hub) und MQTT2_PV_Batterie_HM_350 (Device). Die Inverter-Daten kommen im Device an. Sieht meiner Meinung nach gut aus.
Jetzt die Fragen:
1. Wie stelle ich nun das Power-Limit ein? Im Setup (Web-Interface) gibt es zwar ein Feld dafür, aber mein dort gemachter Eintrag wird ignoriert. Im FHEM-Device kan ich weder per set ... noch per Attribut ein Limit eingeben.
2. Muss ich das 2. Template (hoymiles_microinverter_inverter) anwenden? Wenn ja, worauf? Allerdings sehe ich dort auch nichts von einem Power-Limit in den setlists.
3. Kann es sein, dass die Version 0.5.10 das Limit noch nicht kann?
4. Warum wurden nun alle Versionen zwischenzeitlich gelöscht? Hätte gerne die 0.5.11, 12, 13 probiert.
5. Kann es sein, dass mein HM-350 das Power-Limit nicht beherrscht?
6. Mein FHEM ist nicht auf dem letzten Stand. Habe lediglich das mqtt2_template auf den neuesten Stand gebracht. Spielen eventuell noch andere Module / Libs eine Rolle in diesem Zusammenhang (Power-Limit)?
Wäre nett, wenn ihr mir helfen könntet.
Mobile kurz-antwort:
Das 2. attrTemplate hat setList für ab 0.5.14 und muss auf das 2. automatisch angelegte Device.
Gelöscht ist das alte Zeug, da veraltet. Da ich im Moment nicht die actions aktuell halten kann, müsst ihr das anderweitig lösen.
Sonstiges FHEM muss nicht ganz so aktuell sein.
Dumm gefragt trotz suchen im Thread: wo finde ich denn Beta-Users Firmware?
Zitat von: Tobias am 19 August 2022, 08:06:24
Dumm gefragt trotz suchen im Thread: wo finde ich denn Beta-Users Firmware?
Im Github, Link ist im Mikrocontroller-Forum.
Ist nur nicht meine. Oder suchst du was für MI-Modelle?
Ich habe 2x HM-1500 und einen HM-700
Bis jetzt messe ich nur den Ertrag über jeweils einen Shelly 1PM.
Könnte jemand den Link zum repo posten? Der Microcontroller Thread ist Kilometerlang :(
Zitat von: Tobias am 19 August 2022, 08:52:49
Könnte jemand den Link zum repo posten? Der Microcontroller Thread ist Kilometerlang :(
https://github.com/grindylow/ahoy
Hallo FHEMler,
ich bekomme zeitnah 2 x Hoymiles HM-800 und wollte diese in FHEM integrieren und verfolge dementsprechend diesen Thread.
Ich habe eine NodeMCU und das Funkmodul - allerdings noch nicht verlötet.
Ich wollte als 1. Schritt die Firmware auf den ESP32 flashen und die NodeMCU ins WLAN bringen.
Und hier scheitere ich bereits.
Ich habe versucht mit Visual Studio Code das Projekt von Github selber zu kompilieren.
Egal was ich mache - ich flashe die kompilierte .bin auf die Node MCU und es zeigt sich kein AP.
Ich sehe weder hier noch auf Github auch keine fertige BIN.
Wahrscheinlich ich habe riesengroße Tomaten auf den Augen.
Könnt Ihr mir einen Anstoss geben ??
Oder Geht die Firmware auf der NodeMCU gar nicht weil beim Start der Firmware das Funkmodul abgefragt wird ??
Besten Dank vorab,
Sprudelverduenner
Zitat von: sprudelverduenner am 20 August 2022, 20:44:35
Egal was ich mache - ich flashe die kompilierte .bin auf die Node MCU und es zeigt sich kein AP.
Mach' doch mal die serielle Konsole auf und schau' was sich dort tut. Ich hatte bei manchen Versionen auch das Problem, dass der AP nicht aufging. In der seriellen Konsole habe ich dann gesehen, dass sich das Ding permanent mit einem kryptischen WLAN verbinden wollte, aber keinen AP geöffnet hat.
Zitat von: sprudelverduenner am 20 August 2022, 20:44:35
Oder Geht die Firmware auf der NodeMCU gar nicht weil beim Start der Firmware das Funkmodul abgefragt wird ??
Zumindest der 0.4.x war das egal.
Anbei die 0.4.25 für NodeMCU von mir übersetzt. NodeMCU habe ich selbst nicht ausprobiert, aber die Version für D1-mini läuft.
Hallo TheTrumpeter,
herzlichen Dank für die Firmware.
Diese konnte ich ohne Probleme auf meine NodeMCU flashen. Im Anschluss habe ich in der Konsole auch weitere Reaktionen sehen können. Bei der Firmware die ich habe versucht zu kompilieren blieb da alles leer.
Jetzt kann ich den nächsten Schritt machen und das Funkmodul dran löten und alles testen wenn in ca. 2 Wochen die Inverter da sind.
Gibt es denn irgendwo eine Anleitung wie ich von Github selber die Firmware kompilieren kann ??
Ich blick da nicht wirklich durch ...
Beste Grüße,
Sprudelverduenner
Zitat von: sprudelverduenner am 20 August 2022, 21:32:15
Gibt es denn irgendwo eine Anleitung wie ich von Github selber die Firmware kompilieren kann ??
Ich blick da nicht wirklich durch ...
Es gibt eine "README.md", da steht es drin.
Hat bei mir auf Anhieb wie beschrieben geklappt.
Nocheinmal Danke.
Ich hatte immer nur die read.ME im Hauptverzeichnis gelesen.
Die in der ESP read.ME genannten Einstellungen haben mir geholfen.
Jetzt habe ich auch geschafft die V0.5.15 für die nodeMCU zu "backen"...
Jetzt kann es ans Löten gehen.
Schönen Sonntag.
PS: Falls Jemand die Die V0.5.15 fertig kompiliert für Wemos D1 / nodeMCU gebrauchen kann... siehe Anhang.
Ich muss nochmal wegen dem Power-Limit nachhaken: dank @sprudelverduenner läuft nun die Version 0.5.15 bei mir. MQTT-Template ist ebenfalls aktuell (vom 16.08.) und angewendet.
Bei der Eingabe eines Limits passiert aber immer noch die komische Sache im Eingabefeld mit dem vorangestellten "set". Weiterhin wird beim Limit-setzen ein Reading erzeugt z.B. "limit" mit Wert "set 100". Je nachdem welcher Limit-Typ und Wert gewählt wurde, wird ein entsprechendes Reading erzeugt mit Wert "set xxx". Das kann doch so nicht gewollt sein, oder?
Davon abgesehen funktioniert das Setzen eines Limits nicht bzw. wirkt sich nicht aus. Auch der Wert des Limits kommt nicht an. Wenn ich z.B. die Zahl 100 eingebe, dann erscheint als Power-Limit der Wert 28 oder auch 39, aber nicht 100.
Hat es denn jemand geschafft, ein Limit erfolgreich zu setzen? Wenn ja, wie?
Hast Du einen HM350?
Dann sind 100W nämlich 28%. Hab im Wechselrichter-Forum sowas gelesen, als wäre das Limit (jetzt) in %.
Grüße aus der Toskana.
Ah, jetzt. Danke HeikoE. Du hast recht, das gewünschte Limit muss in % von der max. Leistung (hier 350 W) eingegeben werden. Funktioniert einwandfrei.
Die Sache mit dem Reading: ich sehe es jetzt halt mal als Merkhilfe. Passt schon.
@Beta-User:
Habe jetzt nochmals mit den Templates 'rumgespielt.
Das Ur-MQTT-Device behält die Sensor-Daten des ESP, oder?
Die abgefragte BASE_ID ist wohl der Device name des ESP?
Das inverter-Template auf das Ur-Device angewendet erzeugt die jeweiligen Unter-Devices zu den zugehörigen Invertern?"hoymiles_microinverter_hub_bridge" wird auf das Ur-Device angewendet?
Zitat von: Beta-User am 19 August 2022, 07:56:24
Mobile kurz-antwort:[...]Das 2. attrTemplate hat setList für ab 0.5.14 und muss auf das 2. automatisch angelegte Device [angewendet werden. ...].
D.h. der erste Inverter (Ordnungszahl 0) hat Sensorwerte ohne Indices. Erst ab dem zweiten Inverter gibt es dann z.B. YieldDay1.
Habe ich nur einen Inverter muss ich das Template "hoymiles_microinverter_inverter" nicht anwenden?
Es kommt der Hinweis, dass der erste Inverter die Ordnungszahl 0 erhält, der zweite die Ordnungszahl 1 usw.
Ursprünglich heißt ein Sensorwert z.B. YieldDay.
Durch die Anwendung des Inverter-Templates wird dann (ich habe nur einen HM-300 Inverter bis jetzt) dieser Wert in YieldDay1 umbenannt. Ist das so richtig? Müsste er nicht vielmehr YieldDay0 heissen?
Es werden auch nicht alle Werte mit Indices versehen, die zum Inverter gehören.
defmod MQTT2_inverter_HM_300 MQTT2_DEVICE inverter_HM-300
attr MQTT2_inverter_HM_300 icon solar
attr MQTT2_inverter_HM_300 model hoymiles_microinverter_inverter
attr MQTT2_inverter_HM_300 readingList inverter/HM-300/ch0/U_AC:.* U_AC\
inverter/HM-300/ch0/I_AC:.* I_AC\
inverter/HM-300/ch0/P_AC:.* P_AC\
inverter/HM-300/ch0/Freq:.* Freq\
inverter/HM-300/ch0/Temp:.* temperature\
inverter/HM-300/ch0/YieldDay:.* YieldDay\
inverter/HM-300/ch0/YieldTotal:.* YieldTotal\
inverter/HM-300/ch1/I_DC:.* I_DC1\
inverter/HM-300/ch1/P_DC:.* P_DC1\
inverter/HM-300/ch1/YieldDay:.* YieldDay1\
inverter/HM-300/ch1/YieldTotal:.* YieldTotal1\
inverter/HM-300/ch1/U_DC:.* U_DC\
inverter/HM-300/ch1/Irradiation:.* Irradiation\
inverter/HM-300/ch0/P_ACr:.* P_ACr\
inverter/HM-300/ch0/ALARM_MES_ID:.* ALARM_MES_ID\
inverter/HM-300/ch0/P_DC:.* P_DC\
inverter/HM-300/ch0/Efficiency:.* Efficiency
attr MQTT2_inverter_HM_300 room MQTT2_DEVICE,balcony solar
attr MQTT2_inverter_HM_300 setList on:noArg inverter/devcontrol/0/0 on\
off:noArg inverter/devcontrol/0/1 off\
reboot:noArg inverter/devcontrol/0/2 restart\
limit inverter/devcontrol/0/11/0 $EVTPART1\
limit_pct:slider,2,1,100 inverter/devcontrol/0/11/1 $EVTPART1\
limit_persistent_abs inverter/devcontrol/0/11/256 $EVTPART1\
limit_persistent_pct:slider,2,1,100 inverter/devcontrol/0/11/257 $EVTPART1
attr MQTT2_inverter_HM_300 setStateList on off
attr MQTT2_inverter_HM_300 stateFormat now [$name:P_AC] W, today [$name:YieldDay1] Wh, [$name:temperature] °C\
<br>\
total [$name:YieldTotal1] kWh\
<br>\
last Reading [$name:P_AC:t]
setstate MQTT2_inverter_HM_300 now 0.000 W, today 1494.000 Wh, 29.400 °C\
<br>\
total 9.683 kWh\
<br>\
last Reading 2022-08-24 20:23:48
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 ALARM_MES_ID 20.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 Efficiency 0.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 Freq 50.000
setstate MQTT2_inverter_HM_300 2022-08-24 19:02:58 IODev mqttBroker
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 I_AC 0.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 I_DC1 0.060
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 Irradiation 0.294
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 P_AC 0.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 P_ACr 0.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 P_DC1 1.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 U_AC 236.500
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:47 U_DC 17.600
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 YieldDay1 1494.000
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 YieldTotal1 9.683
setstate MQTT2_inverter_HM_300 2022-08-24 19:06:29 associatedWith MQTT2_balcony
setstate MQTT2_inverter_HM_300 2022-08-24 19:06:12 attrTemplateVersion 20200816
setstate MQTT2_inverter_HM_300 2022-08-24 20:23:48 temperature 29.400
defmod MQTT2_balcony MQTT2_DEVICE balcony
attr MQTT2_balcony autocreate 1
attr MQTT2_balcony bridgeRegexp balcony/([^/]+)/ch[0-9]+/.*:.* "balcony_$1"
attr MQTT2_balcony icon mqtt_bridge_1
attr MQTT2_balcony model hoymiles_microinverter_hub_bridge
attr MQTT2_balcony readingList balcony/version:.* version\
balcony/free_heap:.* free_heap\
balcony/uptime:.* uptime\
balcony/device:.* device\
balcony:inverter/uptime:.* uptime
attr MQTT2_balcony room MQTT2_DEVICE,balcony solar
attr MQTT2_balcony setStateList on off
attr MQTT2_balcony stateFormat last Reading [$name:uptime:t]\
<br>\
uptime [$name:uptime]
setstate MQTT2_balcony last Reading 2022-08-24 23:18:00\
<br>\
uptime 43967
setstate MQTT2_balcony 2022-08-24 22:54:15 attrTemplateVersion 20200812
setstate MQTT2_balcony 2022-08-24 23:18:00 uptime 43967
Der Rückkanal funktioniert bei mir noch nicht. ESP wird z.B. nicht rebooted oder die Leistung scheint nicht begrenzt zu werden. Das reboot-Kommando ist beim bridge-Device mittlerweile verschwunden.
Da passt wohl was noch nicht mit der Auswertung der Topics, das ESP-Device ist kaputt. Wird aber etwas dauern, bis ich mit das näher ansehen kann.
Heute morgen habe ich den Rückkanal zum Inverter über das erzeugte Unterdevice ausprobiert. Das hat jetzt funktioniert. Ein-/ausschalten oder Leistung reduzieren.
Lediglich das Ur-Device überträgt nur die uptime, der reboot Befehl ist hier verschwunden.
reboot für den ESP gab es nie/noch nicht...
oh, dann habe ich das falsch aufgefasst.
Das heißt der Inverter macht einen reboot?
Wird dabei YieldDay zurückgesetzt?
Zitat von: sprudelverduenner am 20 August 2022, 21:32:15
Gibt es denn irgendwo eine Anleitung wie ich von Github selber die Firmware kompilieren kann ??
Ich blick da nicht wirklich durch ...
Zumindest für den ESP8266 gibts das fertige Binary des aktuellen Releases auf der Releaseseite im Github ;)
Ganz nach unten Scrollen zu den Assets, das zipfile ist es ;)
https://github.com/grindylow/ahoy/releases
Weis jemand, was es mit der ALARM_MES_ID auf sich hat?
Ist das ein Fehler-Zähler oder sind das Fehler Codes?
Habe jetzt das ahoy update auf 0.5.15 gemacht.
Jetzt sieht das device schon besser aus:
defmod MQTT2_balcony MQTT2_DEVICE balcony
attr MQTT2_balcony IODev mqttBroker
attr MQTT2_balcony autocreate 1
attr MQTT2_balcony bridgeRegexp balcony/([^/]+)/ch[0-9]+/.*:.* "balcony_$1"
attr MQTT2_balcony icon mqtt_bridge_1
attr MQTT2_balcony model hoymiles_microinverter_hub_bridge
attr MQTT2_balcony readingList balcony/version:.* version\
balcony/free_heap:.* free_heap\
balcony/uptime:.* uptime\
balcony/device:.* device\
balcony:inverter/uptime:.* uptime\
balcony:inverter/version:.* version\
balcony:inverter/device:.* device\
balcony:homeassistant/sensor/HM-300/ch1_U_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_I_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_P_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_YieldDay/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_YieldTotal/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_Irradiation/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_U_AC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_I_AC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_P_AC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_P_ACr/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_Freq/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_Temp/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_ALARM_MES_ID/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_P_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_Efficiency/config:.* { json2nameValue($EVENT) }\
balcony:inverter/HM-300/ch0/FWVersion:.* FWVersion\
balcony:inverter/HM-300/ch0/FWBuildYear:.* FWBuildYear\
balcony:inverter/HM-300/ch0/FWBuildMonthDay:.* FWBuildMonthDay\
balcony:inverter/HM-300/ch0/HWPartId:.* HWPartId\
balcony:inverter/HM-300/ch0/PowerLimit:.* PowerLimit
attr MQTT2_balcony room MQTT2_DEVICE,balcony ESP,balcony solar
attr MQTT2_balcony setStateList on off
attr MQTT2_balcony stateFormat Version [$name:version]\
<br>\
PowerLimit [$name:PowerLimit] %\
<br>\
last Reading [$name:uptime:t]\
<br>\
uptime [$name:uptime]
setstate MQTT2_balcony Version 0.5.15\
<br>\
PowerLimit 100.000 %\
<br>\
last Reading 2022-08-25 18:25:05\
<br>\
uptime 19966
setstate MQTT2_balcony 2022-08-25 12:53:03 FWBuildMonthDay 1209.000
setstate MQTT2_balcony 2022-08-25 12:53:03 FWBuildYear 2021.000
setstate MQTT2_balcony 2022-08-25 12:53:03 FWVersion 10014.000
setstate MQTT2_balcony 2022-08-25 12:53:03 HWPartId 102.000
setstate MQTT2_balcony 2022-08-25 12:53:33 PowerLimit 100.000
setstate MQTT2_balcony 2022-08-25 07:47:41 attrTemplateVersion 20200812
setstate MQTT2_balcony 2022-08-25 12:52:34 dev_cla power
setstate MQTT2_balcony 2022-08-25 12:52:34 dev_cu http://XXX.XXX.XXX.XXX
setstate MQTT2_balcony 2022-08-25 12:52:34 dev_ids XXXXXXXXXXXX
setstate MQTT2_balcony 2022-08-25 12:52:34 dev_mdl HM-300
setstate MQTT2_balcony 2022-08-25 12:52:34 dev_mf Hoymiles
setstate MQTT2_balcony 2022-08-25 12:52:34 dev_name HM-300
setstate MQTT2_balcony 2022-08-25 12:52:24 device balcony
setstate MQTT2_balcony 2022-08-25 12:52:34 exp_aft 95
setstate MQTT2_balcony 2022-08-25 12:52:34 name HM-300 Efficiency
setstate MQTT2_balcony 2022-08-25 12:52:34 stat_cla measurement
setstate MQTT2_balcony 2022-08-25 12:52:34 stat_t inverter/HM-300/ch0/Efficiency
setstate MQTT2_balcony 2022-08-25 12:52:34 uniq_id XXXXXXXXXXXX_ch0_Efficiency
setstate MQTT2_balcony 2022-08-25 12:52:34 unit_of_meas %
setstate MQTT2_balcony 2022-08-25 18:25:05 uptime 19966
setstate MQTT2_balcony 2022-08-25 12:52:24 version 0.5.15
Zitat von: thymjan am 25 August 2022, 12:14:21
Weis jemand, was es mit der ALARM_MES_ID auf sich hat?
Ist das ein Fehler-Zähler oder sind das Fehler Codes?
Laut microntroller Forum sind das Alarm Messages vom WR, z.B. wenn er nachts keinen DC bekommt
Nur ein Zähler, so wie ich es sehe.
LG Holger
Wenn ich das Template auswähle wir gefragt, was die BASE_ID ist. Wo finde ich die?
LG
denke, das ist der ,,device host name" vom ahoy esp.
Nein, der erste Teil des Topics. Beginnt der hier zufällig mit /?
PS: Topic beinhaltet (bei M2Server) nicht den CID-Präfix vor dem Doppelpunkt.
Also mein Topic ist
/SmartHome/Energie/Inverter
Beginnt also mit einem /
Mit dem PS gesagten fange ich leider nichts an. Was wäre denn jetzt die korrekt BASE_ID in meinem Fall?
Mit freundlichen Grüßen
Falls dein Hoymiles "Inverter" heißt, sollte
/SmartHome/Energie
passen...
Tut mir leid wenn ich mich bei diesem Thema als DAU outen muss, aber ich habe immer noch große Fragezeichen in den Augen.
Wie wäre denn die richtige Vorgehensweise um die korrekte BASE_ID zu ermitteln?
In welchem Device kann ich diese an welcher Stelle auslesen?
Mittlerweile habe ich ja die Templates schon öfters auf meine Devices angewandt und habe längere ReadingLists.
Ich sehe jetzt gerade den Wald vor lauter Bäumen nicht mehr...
Und: Kann man das nachträglich ändern/korrigieren, wenn die BASE_ID zum Abfrage-Zeitpunkt falsch eingegeben wurde?
Das ist einfach ein " Textbaustein", der eigentlich automatisch ermittelt werden sollte (was wegen dem /nichtklappt) und dann in der readingList etc. eingebaut wird. Da kannst du also auch "iegendwas" angeben und es hinterher ändern.
Zitat von: thymjan am 28 August 2022, 21:15:23
Wie wäre denn die richtige Vorgehensweise um die korrekte BASE_ID zu ermitteln?
Eigentlich sollte das automatisch richtig laufen, es wird daher demnächst noch ein kleinere update kommen, das dann hoffentlich auch die Erkennungsprobleme mit dem "/" und tiefer strukturierten Topics wie "/SmartHome/Energie" beseitigen sollte. Das Kürzel BASE_ID verwende ich in den attrTemplate ganz allgemein für den unveränderlichen "ersten Teil" des Topic-Strings.
Wenn du dir die automatisiert erstellten Teile (mit "CID" vor dem Doppelpunkt) in der readingList ansiehst, wird evtl. klarer, dass das bei dir "inverter" ist:
Zitat von: thymjan am 25 August 2022, 18:29:11
Habe jetzt das ahoy update auf 0.5.15 gemacht.
Jetzt sieht das device schon besser aus:
defmod MQTT2_balcony MQTT2_DEVICE balcony
attr MQTT2_balcony IODev mqttBroker
attr MQTT2_balcony autocreate 1
attr MQTT2_balcony bridgeRegexp balcony/([^/]+)/ch[0-9]+/.*:.* "balcony_$1"
attr MQTT2_balcony icon mqtt_bridge_1
attr MQTT2_balcony model hoymiles_microinverter_hub_bridge
attr MQTT2_balcony readingList balcony/version:.* version\
balcony/free_heap:.* free_heap\
balcony/uptime:.* uptime\
balcony/device:.* device\
balcony:inverter/uptime:.* uptime\
balcony:inverter/version:.* version\
balcony:inverter/device:.* device\
balcony:homeassistant/sensor/HM-300/ch1_U_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_I_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_P_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_YieldDay/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_YieldTotal/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch1_Irradiation/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_U_AC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_I_AC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_P_AC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_P_ACr/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_Freq/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_Temp/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_ALARM_MES_ID/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_P_DC/config:.* { json2nameValue($EVENT) }\
balcony:homeassistant/sensor/HM-300/ch0_Efficiency/config:.* { json2nameValue($EVENT) }\
balcony:inverter/HM-300/ch0/FWVersion:.* FWVersion\
balcony:inverter/HM-300/ch0/FWBuildYear:.* FWBuildYear\
balcony:inverter/HM-300/ch0/FWBuildMonthDay:.* FWBuildMonthDay\
balcony:inverter/HM-300/ch0/HWPartId:.* HWPartId\
balcony:inverter/HM-300/ch0/PowerLimit:.* PowerLimit
attr MQTT2_balcony room MQTT2_DEVICE,balcony ESP,balcony solar
attr MQTT2_balcony setStateList on off
[...]
Allerdings finde ich ganz und gar nicht, dass "sieht das device schon besser aus" zutrifft:
- "balcony" (wurde warum auch immer als BASE_ID erkannt) ist falsch, denn z.B. was unter dem branch "version" kommt, wird nochmal mit CID-Präfix automatisiert ergänzt. Aber solange das so drinsteht, wird auch attrTemplate immer wieder der Ansicht sein, das sei die BASE_ID => ändern oder diese (falsche) Zeile löschen).
- als Folgefehler paßt auch die bridgeRegexp nicht und die neuen Teile (die letzten paar Zeilen in der readingList) landen im falschen Device*
- die "homeassistant"-Zeilen sind schlicht (für FHEM) überflüssig => weg damit und diese Topics in ignoreRegexp am IO (siehe MQTT2_CLIENT-Wiki-Artikel).
*Nochmal zur Struktur:
Der ESP (mit dem nRF) wird durch ein separates Device repreäsentiert, jeder WR bekommt sein eigenes MQTT2_DEVICE. Das mag man als unnötig empfinden, wenn man nur einen WR hat, aber sobald es mehr sind/werden, ist es zwingend, das so zu machen. Die generelle Struktur entspricht dabei dem, wie das auch bei anderen Lösungen zu finden ist, in denen ein ESP oder sonst ein Dienst Daten empfängt und auswertet.
Die weiteren Topics werden dann noch in das "inverter"-attrTemplate eingebaut, dann müßte insbesondere auch der "Kreis" betr. das "limit" geschlossen werden können (vorausgesetzt, es handelt sich um einen Absolutwert, der da zurückkommt; ggf. müßte man noch % ergänzen, was dann aber weitere Angaben des Users erfordert).
Nochmal zur BASE_ID:
Die ist doch nicht beliebig, oder? Nach Auswählen des Templates "hoymiles_microinverter_hub_bridge" kommt bei der Abfrage der BASE_ID der Hinweis "as set in esp".
Ist die BASE_ID nun im ahoy-esp der "Device Host Name"/"Device Name" (bei mir jetzt "hoyhub") oder bei den MQTT Einstellungen das Topic (bei mir jetzt "inverter").
Habe als BASE_ID den Device Name "hoyhub" angegeben, ist das richtig?
Habe jetzt zwei einkanalige HM Microinverter (Name HM-300R und HM350L) am laufen.
Es wurden zwei devices dafür angelegt: MQTT2_inverter_HM_300R und MQTT2_inverter_HM_350L
Dort habe ich das Template "hoymiles_microinverter_inverter" jeweils ausgewählt und die Ordnungszahlen 0 und 1 vergeben.
Bei einkanaligen Invertern sind keine Indices erforderlich, oder?
Readingslist:
inverter/HM-300R/ch0/U_AC:.* U_AC
inverter/HM-300R/ch0/I_AC:.* I_AC
inverter/HM-300R/ch0/P_AC:.* P_AC
inverter/HM-300R/ch0/Freq:.* Freq
inverter/HM-300R/ch0/Temp:.* temperature
inverter/HM-300R/ch0/YieldDay:.* YieldDay
inverter/HM-300R/ch0/YieldTotal:.* YieldTotal
inverter/HM-300R/ch1/I_DC:.* I_DC1
inverter/HM-300R/ch1/P_DC:.* P_DC1
inverter/HM-300R/ch1/YieldDay:.* YieldDay1
inverter/HM-300R/ch1/YieldTotal:.* YieldTotal1
folgendes würde ich streichen:
inverter/HM-300R/ch0/YieldDay:.* YieldDay
inverter/HM-300R/ch0/YieldTotal:.* YieldTotal
und folgendes abändern:
inverter/HM-300R/ch1/I_DC:.* I_DC1
inverter/HM-300R/ch1/P_DC:.* P_DC1
inverter/HM-300R/ch1/YieldDay:.* YieldDay1
inverter/HM-300R/ch1/YieldTotal:.* YieldTotal1
...erforderlich eher nicht. Der Gedanke hinter der generelle Indexierung war eher, dass man dann einheitliche Readings hat und z.B. gplot-files einfacher tauschen kann. Dafür könnte man hier aber sowieso mit plotReplace arbeiten und gleich auch die 2- und 4-Kanaligen damit erwischen...
Hmm, mal schauen, streichen kann man die (Summen-) Zeilen (ch0) aber nur, wenn darüber keine Infos kommen. Sonst => {}. => kommt da was?
ne, die Werte der Summen-Zeilen kommen über ch1.
Im hub-Device laufen auch keine neuen auf.
...vielleicht sollten wir das besser dann klären und entscheiden, wenn wieder die Sonne scheint; mein (nicht direkt vergleichbarer) MI-Code tickt da anders...
Sorry, das hier hatte ich gestern übersehen:
Zitat von: thymjan am 04 September 2022, 18:06:39
Nochmal zur BASE_ID:
Die ist doch nicht beliebig, oder? Nach Auswählen des Templates "hoymiles_microinverter_hub_bridge" kommt bei der Abfrage der BASE_ID der Hinweis "as set in esp".
Ist die BASE_ID nun im ahoy-esp der "Device Host Name"/"Device Name" (bei mir jetzt "hoyhub") oder bei den MQTT Einstellungen das Topic (bei mir jetzt "inverter").
Habe als BASE_ID den Device Name "hoyhub" angegeben, ist das richtig?
Nein, es geht um dem Topic.
Allerdings sollte diese Anfrage gar nicht kommen, weil das attrTemplate das automatisch auflösen können sollte - dazu braucht es eigentlich nur den "version"-Eintrag in der readingList. War FHEM (bzw. die attrTemplate-file) aktuell? Wenn ja, würde ich gerne nochmal ein raw-listig sehen wollen (ohne die setstate-Zeilen reicht aus), um das selbst testen zu können. Oder stand da was altes drin bzw. fehlte das "version"?
Zitat
Dort habe ich das Template "hoymiles_microinverter_inverter" jeweils ausgewählt und die Ordnungszahlen 0 und 1 vergeben.
Das paßt soweit, und wenn das Device "neu" ist, kennt FHEM auch die Ordnungszahl noch nicht, daher ist diese Abfrage an der Stelle auch ok und gewollt (wenn nur die Ordnungszahl abgefragt wird und nicht sonst noch was).
Sind hier alle auf den MQTT-Zug aufgesprungen oder hat ev. auch schon jemand eine sinnvolle JSON-Konfiguration?
Zitat von: TheTrumpeter am 09 September 2022, 11:31:10
Sind hier alle auf den MQTT-Zug aufgesprungen oder hat ev. auch schon jemand eine sinnvolle JSON-Konfiguration?
Was genau meinst Du? Brauchst Du eine Umsetzung mit einem MQTT-Device, mit einem MQTT2-Device oder etwas wie JSONMOD bzw. HTTPMOD über die Ahoy-API?
LG
Zitat von: gent am 09 September 2022, 20:22:28
HTTPMOD über die Ahoy-API?
HTTPMOD auf die JSON-Seite vom Ahoy.
(HTTPMOD für die "Visualisierung" vom Ahoy habe ich, aber JSON wäre effizienter. Habe die Readings automatisch anlegen lassen, aber die Namen sind nicht so wie ich es mir vorstelle. Bevor ich nun alles umbenenne, dachte ich, ich frag' mal hier, vielleicht hat sich schon jemand die Arbeit gemacht.
Zitat von: TheTrumpeter am 10 September 2022, 13:47:27
HTTPMOD auf die JSON-Seite vom Ahoy.
(HTTPMOD für die "Visualisierung" vom Ahoy habe ich, aber JSON wäre effizienter. Habe die Readings automatisch anlegen lassen, aber die Namen sind nicht so wie ich es mir vorstelle. Bevor ich nun alles umbenenne, dachte ich, ich frag' mal hier, vielleicht hat sich schon jemand die Arbeit gemacht.
Damit kann ich Dir leider nicht helfen. Ich benutze hier nicht das beschriebene MQTT2-Device, sondern ein "normales" MQTT-Device. Dafür hätte ich Dir eine Definition schicken können. Was ich aber schon beobachtet habe ist, dass die Visualisierungs-Seite manchmal völlig unsinnige Werte anzeigt, so dass ich die nicht über HTTPMOD auslesen würde. Es wäre zu klären, ob die JSON-Seite tatsächlich vernünftige Werte liefert. Mit MQTT habe ich jedenfalls bisher keine solchen unsinnigen Werte gesehen.
LG
Zitat von: gent am 15 September 2022, 21:50:31
Was ich aber schon beobachtet habe ist, dass die Visualisierungs-Seite manchmal völlig unsinnige Werte anzeigt, so dass ich die nicht über HTTPMOD auslesen würde. Es wäre zu klären, ob die JSON-Seite tatsächlich vernünftige Werte liefert.
Das kann ich so nicht bestätigen.
Ich lese die Werte meines WRs praktisch seit dem 1. Tag über die Visualisierungsseite aus und logge das auch. In den nun ziemlich genau 3 Monaten ist mir kein ,,unvernünftiger" Wert untergekommen.
Noch mehr würde es mich wundern, wenn JSON, MQTT und die Visualisierung unterschiedliche Werte liefern würden.
Schade, ich habe doch kein Screenshot von der Visualisierung-Seite gemacht, als die unsinnigen Werte aufgetreten sind. Dann hätte ich den hier mal gepostet. Aber die waren dermaßen absurd, dass ich mir nur vorstellen konnte, dass die Visualisierung die vom HM gelieferten Daten per JavaScript aufbereitet und wenn da irgendwie der Browsercahce buggy ist, dann wäre das eine Erklärung.
Wie gesagt: Die Werte, die per MQTT an FHEM übermittelt wurden, waren OK.
LG
Hallo,
nach langer Zeit beschäftige ich mich wieder mit fhem und will meinen OpenDTU damit auslesen und vor allem visualisieren.
Das Einrichten des OpenDTU und die Anbindung per MQRR2_DEvice hat wunderbar geklappt, ich kann alle Werte auslesen. Einen Herzlichen Dank an alle die da Arbeit reingesteckt haben das dies so reibungslos funktioniert hat!
Aber bei der Visualisierung happert es leider und ich vermute das Problem sitzt vor der Tastatur, aber vielleicht kann mir jemand auf die Sprünge helfen:
Das Reading ...yieldday ist ja kumulativ und wenn ich damit einen Graphen plotten lasse bekomm ich das angehängte Bild -- aber das passt ja nicht wirklich. Man möchte ja die seit dem letzten Auslesen dazugekommen Wattstunden angezeigt bekommen -- das dann über den Tag eine ansteigende und wieder abfallende Kurve ergibt.
Wie mache ich das?
Danke für jede Hilfe!
Lg
Hallo und Herzlich Willkommen,
ich denke, da liegt eine kleine Verwechslung vor ;)
Du möchtest sicher die Leistung anzeigen, die steigt früh an und fällt abends wieder ab. Der Ertrag hingegen steigt tagsüber an und bleibt ab Sonnenuntergang auf dem Niveau.
Ja. Du hast recht. Und ich hatte recht mit meiner Vermutung daß das Problem vor der Tastatur saß ;D.
Was mir aber jetzt auffällt: Sobald die Sonne untergegangen ist und die Readings ...power und ..yieldday etc. keine neuen Werte liefern sind diese auch nicht auswählbar beim Plot Editor... Kann man dagegen etwas tun?
Lg
Gute Frage, ich habe mit dem Hoymiles noch nichts weiter gemacht, außer openDTU mit MQTT in Betrieb zu nehmen und mal am Labornetzgerät zu testen.
Zitat von: Sorcuring am 02 Oktober 2022, 20:38:51
Was mir aber jetzt auffällt: Sobald die Sonne untergegangen ist und die Readings ...power und ..yieldday etc. keine neuen Werte liefern sind diese auch nicht auswählbar beim Plot Editor... Kann man dagegen etwas tun?
Das Attribut "event-min-interval" für die entsprechenden Readings sinnvoll setzen.
Zitat von: TheTrumpeter am 03 Oktober 2022, 08:28:22
Das Attribut "event-min-interval" für die entsprechenden Readings sinnvoll setzen.
Zum einen generiert das keine Readings, und zum anderen sollten auch "alte" Readings auswählbar sein. Hier kam vielleicht der Monatswechsel dazwischen? (=>glue files im FileLog-Device aktivieren)
Zitat von: Beta-User am 03 Oktober 2022, 08:54:00
Zum einen generiert das keine Readings
Doch, selbst wenn sich ein Reading nicht ändert, wird alle x-Sekunden ein Event generiert, sodass es geloggt wird (richtige Logfile-Konfiguration mal vorausgesetzt).
Zitat von: TheTrumpeter am 03 Oktober 2022, 09:01:53
Doch, selbst wenn sich ein Reading nicht ändert, wird alle x-Sekunden ein Event generiert, sodass es geloggt wird (richtige Logfile-Konfiguration mal vorausgesetzt).
Wir können gerne eine Wette abschließen... Das ist und bleibt (bezogen auf den heutigen Code von fhem.pl) falsch. Ohne dass das betreffende Modul (!) überhaupt ein Event generiert, passiert gar nichts. Dieses Attribut führt nur dazu, dass der über event-on-change-reading definierte Filter dann nicht mehr greift, WENN (eigentlich vom Modul her) ein Event kommt.
Dein Vorschlag für einen Einsatz?
Zitat von: Beta-User am 03 Oktober 2022, 09:23:43
Ohne dass das betreffende Modul (!) überhaupt ein Event generiert, passiert gar nichts. Dieses Attribut führt nur dazu, dass der über event-on-change-reading definierte Filter dann nicht mehr greift, WENN (eigentlich vom Modul her) ein Event kommt.
DAS setze ich voraus, denn er schreibt ja weiter oben:
Zitat von: Sorcuring am 02 Oktober 2022, 20:38:51
Sobald die Sonne untergegangen ist und die Readings ...power und ..yieldday etc. keine neuen Werte liefern sind diese auch nicht auswählbar beim Plot Editor... Kann man dagegen etwas tun?
"Sobald" in dem Kontext bedeutet für mich, dass er die Updates bekommt solange die Sonne scheint... damit ist "event-on-change-reading" wohl gesetzt, sonst würd' sich da nix tun.
Zitat von: TheTrumpeter am 03 Oktober 2022, 09:39:54
"Sobald" in dem Kontext bedeutet für mich, dass er die Updates bekommt solange die Sonne scheint... damit ist "event-on-change-reading" wohl gesetzt, sonst würd' sich da nix tun.
Wir wissen es nicht. Jedenfalls "generiert" min-interval keine Events! Und genau das hattest du behauptet. (Nachtrag: ohne das Attribut bekommt man sehr wohl Events! Nur halt mehr... Es ist ein FILTER!)
Und soweit ich das verfolgt habe, ging es darum, dass der ESP schlicht nichts mehr tut, wenn es keine Sonne mehr gibt. Also auch keine (sinnlosen!) Werte mehr per MQTT sendet.
Ist aber auch egal, weil die eigentliche Ursache für das "nicht auswählen können" ziemlich sicher nicht die ist, dass keine Aktualisierungen mehr vorliegen, sondern dass da (noch) nichts im Logfile zu finden war...
Sorry das ich mich einmal einklinke. Bei mir läuft Ahoiy in der Version 0.5.17, also der im Moment aktuellsten. Nachdem heute in meinem Plot für yield total die Skala auf Logarithmisch umsprang und ich das nicht wegbekomme habe ich mir mal den preprocessed Input angesehen. Dabei ist mir aufgefallen das MQttt immer alle 3 Yield totals schickt. Jetzt bin ich nicht so tief in den Reading Geschichten drin, gibt es irgendeine Möglichkeit das Reading noch mal in 3 einzelne zu splitten? Und kann dieses Verhalten vielleicht irgendwer bestätigen? Das Verhalten gilt übrigens auch für den Yield day Plot. Bei der Skala vermute ich ein Formatproblem beim Eintrag in in DBlog. Das habe ich erst am Montag umgebaut von Text auf DB. Allerdings wäre ich auch da für Hinweise dankbar.
LG Micha
Hallo zusammen,
muss mal ein wenig "offTopic" fragen (zumindest was den Bezug zu Fhem angeht):
Wie genau verbindet sich denn der Ahoy mit dem Hoymiles Wechselrichter per Funk? Ist das Direkt, ohne dass ich dafür etwas Betätigen muss? (kann ich mir kaum vorstellen,sonst müsste ich wohl auch mal was von Nachbarn empfangen?) Oder wie genau funktioniert das?
Bin irgendwie beim Lesen grad ganz schön verwirrt ???
Für Tipps bin ich dankbar
und
Viele Grüße
Andreas
Das geht über die Seriennummer des Wechselrichters. Wenn Du die in ahoy angibst, kannst du die Daten von diesem Wechselrichter empfangen.
Vielen Dank für die schnelle Antwort :)
So isses einfach ;)
VG
Andreas
Hallo zusammen,
Ich bin seit ewigkeiten mit Fhem unterwegs. Habe auch vieles durch euch hier im Forum hinbekommen. Lese hier sehr viel mit. Danke erstmal dafür!
Nun habe ich aber folgendes Problem. Ich habe den Ahoy DTU sauber mit einem HM-1500 am laufen. Der Funkt ohne Probleme. In Fhem habe ich das Device auch als MQTT 2 Device. Siehe Screenshot Anhang
Ich bin allerdings zu dämlich die Limitierung des Wechselrichter zu steuern. Ich möchte also gerne dem Wechselrichter sagen, dass er jetzt nur 150 Watt in das Netz speisen soll. Über die AHoy DTU Website läuft es problemlos. Ahoy Firmware Version 0.5.17
Was muss ich in Fhem machen, damit ich den Wechselrichter steuern kann? Oder geht das nicht?
Villeicht kann mir ja jemand helfen.
Muss ich das über das erstellte Template MQTT2_AHOY_DTU machen?
Oder über das IODev mit set myIODEV publish "was muss hier dann stehen?"
Fhem liest folgendes aus: AHOY_DTU:inverter/HM-1500/ch0/P_AC:.* P_AC
Vielen Dank im voraus!
Gib mal für IODev das gleiche device wie LASTInputDev ein.
attr MQTT2_AHOY_DTU IODev m2s
sowas in der Art wie hier (https://github.com/lumapu/ahoy/blob/main/tools/esp8266/User_Manual.md#active-power-limit-via-mqtt) beschrieben schon versucht ?
attr setList MQTT2_AHOY_DTU ActivePower:selectnumbers,2,1,100,0,lin inverter/HM-1500/ch0/11/257 $EVTPART1
Zitat von: TomLee am 27 Oktober 2022, 22:19:55
sowas in der Art wie hier (https://github.com/lumapu/ahoy/blob/main/tools/esp8266/User_Manual.md#active-power-limit-via-mqtt) beschrieben schon versucht ?
attr setList MQTT2_AHOY_DTU ActivePower:selectnumbers,2,1,100,0,lin inverter/HM-1500/ch0/11/257 $EVTPART1
Wenn ich das ins Fhem übernehme kommt folgendes: Please define setList first
Ich dachte erst das der MQTT2 Server in Fhem nicht richtig läuft. Aber ich kann anderen Devices die ich habe, Nachrichten schicken ohne Probleme.
Wenn ich über Fhem das set m2s Publish inverter/HM-1500/ch0/11/0 150 sende, passiert einfach nichts. Ich bin aber auch ein totaler Noob in MQTT muss ich dazu sagen.
Folgendes hatte ich auch probiert.
set m2s Publish inverter/HM-1500/0/11/0 150
set m2s Publish inverter/HM-1500/0/11/0/150
Wobei der Wert 150 die Wattzahl sein soll. Passiert aber bei beidem nichts.
ZitatWenn ich das ins Fhem übernehme kommt folgendes: Please define setList first
Sry Kopierfehler, zum Test, in dem von dir gezeigten Device meinte ich so:
attr MQTT2_AHOY_DTU setList ActivePower:selectnumbers,2,1,100,0,lin inverter/devcontrol/ch0/11/257 $EVTPART1Ob jetzt Watt oder Prozent ist zum testen ja erstmal egal.
Was du am MQTT2_SERVER versucht hast, würd ich so mal probieren:
set m2s publish inverter/devcontrol/ch0/11/0 150oder so Prozentwerte:
set m2s publish inverter/devcontrol/ch0/11/257 20
Ich hab keinen Wechselrichter und bin in dem Thema hier auch nicht drin, warum aber die Topics in dem Bridge-Device landen ist seltsam und hab ich mich nicht weiter mit beschäftigt, da gehören sie definitiv nicht hin, die gehören eigentlich in ein eigenes MQTT2_DEVICE.
nach etwa 1/2 Seiten lesen der letzten Posts einfach mal ins Blaue, weil da scheint das meiste ja schon vertemplated zu sein:
wenn du nochmal das hoymiles_microinverter_hub_bridge-Template auf das Device anwendest das du im Screenshot gezeigt hast, dann den Ahoy DTU mal neu startest oder mal was an den Einstellungen änderst, wird dir dann ein neues MQTT2_DEVICE erstellt auf das dann das hoymiles_microinverter_inverter-Template eigentlich angewendet wird ?
TomLee Du bist mein Held!
mit set m2s publish inverter/devcontrol/0/11/0 150 klappt es bei mir. Der Wechselrichter ändert due Werte! ;D
das ch0 musste in 0 erstetzt werden. Mit ch0 bootet der Ahoy DTU neu. nun kann ich endlich den Wechselrichter automatisieren.
Vielen lieben Dank!!
ZitatTomLee Du bist mein Held!
Hab mir mal den ganzen Thread durchgelesen und verstehe jetzt erst richtig, hier gehts schon die ganze Zeit nur um Ahoy DTU, nicht nur die letzten Seiten, irgendwie dachte ich als du schriebst das wäre was Neues hier.
Der wahre Held hat hier Templates zu dem Teil bereitgestellt und mein Gefühl sagt mir das du mglw. irgendwas vor dir hinwurstelst, ohne eine sinnvolle Basis zu haben irgendwas zu automatisieren.
Zeig doch mal wie das jetzt bei dir aussieht.
Zitat von: TomLee am 28 Oktober 2022, 22:03:53
Hab mir mal den ganzen Thread durchgelesen und verstehe jetzt erst richtig, hier gehts schon die ganze Zeit nur um Ahoy DTU, nicht nur die letzten Seiten, irgendwie dachte ich als du schriebst das wäre was Neues hier.
Der wahre Held hat hier Templates zu dem Teil bereitgestellt und mein Gefühl sagt mir das du mglw. irgendwas vor dir hinwurstelst, ohne eine sinnvolle Basis zu haben irgendwas zu automatisieren.
Zeig doch mal wie das jetzt bei dir aussieht.
Mein Plan ist es mit einem Powerfox (ist ein Cloud Energiezähler) den aktuellen Wert auszulesen, um mit dann den Wechselrichter zu steuern für eine Nulleinspeisung. Den Powerfox lese ich aktuell per HTTMOD aus.
Gibt es da eine bessere Möglichkeit, die ich übersehe?
Für Fans von OpenDTU habe ich hier https://forum.fhem.de/index.php/topic,94495.msg1251265.html#msg1251265 (https://forum.fhem.de/index.php/topic,94495.msg1251265.html#msg1251265) einen Vorschlag für entsprechende MQTT Templates erstellt.
Gerne ausprobieren und/oder kritisch beäugen.
Gruß, Tobias
Zitat von: Beta-User am 15 Dezember 2022, 10:18:21
Moin,
da ich zwischenzeitlich auch mit openDTU rumteste (hoffentlich ab Jan. dann 6xMI-1500 3.Gen) habe ich deinen Vorschlag noch etwas modifiziert und eingecheckt (kommt mit dem morgigen update).
Allerdings kommt mir die Art und Weise noch etwas verbesserungsfähig vor, was da wann wie gesendet wird (Name alle 5 Sekunden? Kein JSON?). Werde das mal bei Gelegenheit addressieren...
...von daher bin ich noch kein 100%-iger "Fan"...
Zitat von: Beta-User am 15 Dezember 2022, 10:52:50
...von daher bin ich noch kein 100%-iger "Fan"...
und hast du deine Anlage schon in Betrieb?
Ich verstehe noch nicht ganz Vor- / Nachteile von ahoy gegenüber openDTU in Bezug auf Fhem bzw. allgemein.
Zitat von: masterpete23 am 16 Januar 2023, 23:04:07
und hast du deine Anlage schon in Betrieb?
Nur in Teilen und probeweise; der Netzbetreiber kommt mit dem Zähler nicht in die Püschen, und ich kann die Anlage auch nur nach und nach aufbauen, wie es vom Wetter und der Zeit her paßt (sind insgesamt 7 Teilbereiche, auf die die Panels zu verteilen sind...)
Zitat
Ich verstehe noch nicht ganz Vor- / Nachteile von ahoy gegenüber openDTU in Bezug auf Fhem bzw. allgemein.
Ich hatte Ahoy nur kurz mal angeschaut, und danach auf der Hardware dann ZiyatT's Code für die älteren MI im Einsatz und kann daher die Unterschiede nicht wirklich auf aktuellem Stand beurteilen.
Insgesamt scheint mir die Entwicklergemeinde rund um Ahoy zumindest kommunikativ engagierter zu sein. Wenn Ahoy (irgendwann?) mal die Daten in JSON verpackt und z.B. für jeden WR dann in einem JSON-Blob gesammelt sendet, hat aus FHEM-Sicht Ahoy die Nase vorn, weil das in FHEM effizienter zu verarbeiten ist.
Hat man (wie ich) mehr als 3 WR, muss man da aber (zumindest derzeit?) selber kompilieren. OpenDTU ist nur auf ESP32 zugeschnitten und hat schon im Standard mehr WR vorgesehen, die man einfach über das Web-Interface eintragen kann, und die Besonderheit mit den MI-3rd Gen. (Nummernkreise 10x2) ist da auch schon berücksichtigt.
Muss demnächst mal versuchen, Hardware für Ahoy aufzubauen, um den Code ggf. auch mal auf meine Belange aufzubohren und ggf. den älteren MI zu integrieren. Hat aber eine eher geringe Prio in meinem Gesamtprojekt, da OpenDTU ja im Moment läuft...
Hi Beta-User,
kann es sein, dass du im letzten Beitrag ahoy und OpenDTU genau verwechselt hast, was Kommunikation und JSON etc angeht?
Gruss
Tobias
Denke noch. OpenDTU spricht jedenfalls kein json, für ahoy habe ich keine aktuelle Info.
Jetzt habt ihr mich beide abgehangen.
Ich habe nun nen hm 600 hier liegen und überlege ob ahoy oder opendtu nun mir die Daten ins FHEM liefert.
Könnt ihr mir was empfehlen?
Ich warte auch auf Zählertausch und Wetter um die ersten Module zu montieren :)
Würde in der Situation Ahoy nehmen (und wenn (schon) möglich die JSON-Sendeoption aktivieren).
.. und solange dann mit den o.g. mqtt2 templates arbeiten?
Zitat von: masterpete23 am 18 Januar 2023, 12:21:50
.. und solange dann mit den o.g. mqtt2 templates arbeiten?
Nur, wenn JSON nicht geht. Wenn es eine JSON-Option geben sollte, wäre ich interessiert, das dann auch sauber zu vertemplaten - es ist wie bereits geschrieben "leichtgewichtiger", (jedenfalls, wenn mehrere Daten in einem Blob enthalten sind).
Danke. Dann werde ich mir auf einen esp8266 mal parallel ahoy installieren.
Weiß gar nicht wie ein WR sich verhält, wenn ich ihn (aus Versehen) mit 2 DTUs verbinde.
... Die Sonne scheint und ich warte auf den Zähler... :/
Hat jemand eine gute Lösung des Loggings und der Auswertung mit hohem WAF?
Nun habe ich Zahlen in meiner logdb und suche noch was grafisches..
Hi,
ich habe seit einer guten Woche nun endlich die OpenDTU mit meinen 3x HM1500/HM700 WR verbunden. Funktioniert wunderbar. Bisher wurde gezählt über je einen Shelly 1PM. Dieser liefert ca alle 4-5sek die Daten per MQTT.
Die OpenDTU habe ich auch auf ein 5sek Intervall eingestellt. Faktisch werden die Daten aber alle 15-16sek aktualisiert, sieht man ja gut über den sek-Zähler in der WebUI.
Hat das einen Grund oder fehlt noch eine Einstellung?
@Masterpete,
such mal nach DOIF und card. So sieht es bei mir aus:
Wow - das ist sehr schick.
Würdest du das Teilen - was meintest du mit DOIF und card? :)
Zitat von: masterpete23 am 24 Januar 2023, 20:54:09
was meintest du mit DOIF und card? :)
Danach suchen!? ???
Bitteschön: ;)
https://forum.fhem.de/index.php/topic,120088.0.html (https://forum.fhem.de/index.php/topic,120088.0.html)
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card (https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card)
Danke - das hat mir die SUche nicht ausgespuckt :)
ahoy kann nun in der neuen DEV schonmal so konfiguriert werden dass mqtt nur gesendet wird, wenn vom WR was neues kommt:
ZitatSend Inverter data in a fixed interval, even if there is no change. A value of '0' disables the fixed interval. The data is published once it was successfully received from inverter. (default: 0)
Hallo,
habe hier jetzt einiges mitgelesen und muss nun doch (dumme) Fragen stellen.
Ich habe AhoiDTU auf dem MCU und bekomme über das Web-Interface die Werte der Wechselrichter angezeigt.
MQTT ist konfiguriert, im FHEM wurde automatisch ein Gerät MQTT2_AHOY_DTU66 angelegt.
Auf dieses Gerät habe ich das Template "hoymiles_microinverter_hub_bridge" angewendet.
Daraufhin erschienen nach kurzer Zeit zwei weitere Geräte, die die einzelnen Wechselrichter repräsentieren.
Auf diese Geräte soll laut TomLees Antwort #159 in diese Thread nun das Template hoymiles_microinverter_inverter angewendet werden.
Das habe ich aber gar nicht?
FHEM ist aktuell, Ahoi ist Version 0.5.66
Mache ich was falsch, oder was habe ich übersehen?
Möglicherweise musst du etwas warten, da ist eine filter:-Anweisung aktiv.
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/ch0/U_AC:.*
Es muss also U_AC für ch0 gesendet worden sein (bzw. in der readingList vorhanden sein.
fyi: wer noch einen älteren MI hat, dürfte demnächst auch per Ahoy-MQTT Daten erhalten können...
Zitat von: Beta-User am 09 Februar 2023, 14:00:45
fyi: wer noch einen älteren MI hat, dürfte demnächst auch per Ahoy-MQTT Daten erhalten können...
oh da freue ich mich :-) habe noch einen MI-600 und mit der DTUsim klappt es bei mir leider nicht... warum auch immer.
Wenn ahoy das dann drin hat wäre richtig cool... eine Version für alle Varianten.
Was hast du für eine (ESP-) Hardware? Falls du selbst compilen kannst, könntest du meine aktuellste Fassung testen: https://github.com/rejoe2/ahoy/tree/development03 (https://github.com/rejoe2/ahoy/tree/development03). Ist zwar noch mit etwas heißer Nadel gestrickt, aber besser wie nichts...
Auf diese Geräte soll laut TomLees Antwort #159 in diese Thread nun das Template hoymiles_microinverter_inverter angewendet werden.
Das habe ich aber gar nicht?
Ich hab ich hab das mal gesehen, versuche es auch gerade nachzustellen.
Wenn man das Template aktiviert kommen Fragen wie z.B. Inverternummer,und wieviele Panels dran sind.
Wenn ich es recht verstanden habe gilt folgende Vorgehensweise:
1. AHOYDUT über MQTT mit FHEM verbinden.
2. Diesem MQTT Device das das Attribut template "Homiles-Microinverter-Hub_Bridge" zuweisten
3. Dann wird ein neues MQTT device per Autocreate angelegt.
4. Dieses Device soll dann das Attribut Template "oymiles_microinverter_inverter" bekommen. (wenn das Template da ist)
Korrigiert mich bitte wenn ich falsch liege.
Ich bleib mal dran. :)
Zitat von: Beta-User am 09 Februar 2023, 16:23:06
Was hast du für eine (ESP-) Hardware? Falls du selbst compilen kannst, könntest du meine aktuellste Fassung testen: https://github.com/rejoe2/ahoy/tree/development03 (https://github.com/rejoe2/ahoy/tree/development03). Ist zwar noch mit etwas heißer Nadel gestrickt, aber besser wie nichts...
ich nutze momentan einen ESP8266.
Deine Software habe ich mal geflasht, 0.5.83
Ich sehe den MI600 allerdings nur die Netzspannung Frequenz und die Temperatur.
Grundsätzlich funktioniert also die Kommunikation :-)
Ja, mehr habe ich vor meinem Urlaub nicht mehr geschafft. Aber vielleicht bekommt ihr das ja vollends hin, bis ich wieder dazu kommen könnte....
Hallo,
ich habe den Ahoi_DTU jetzt in Betrieb, aber noch keinen Inverter dran. Das braucht noch ein wenig.
Ich probiere gerade JsonMod auf den verschiedenen Endpoints. Die Informationen werden in Reading geschrieben. Von aussen sieht alles gut aus, so das ich ganz zuversichtlich bin/war, das ich später auch Daten erhalte, um z.B. einen Plot zu erstellen.
Leider habe ich aber im Log folgendes:
Use of uninitialized value $name in substitution (s///) at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 105.
Use of uninitialized value $name in exists at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 108.
Use of uninitialized value $name in lc at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 109.
Use of uninitialized value $find in exists at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode/Alias.pm line 25.
Use of uninitialized value $find in hash element at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode/Alias.pm line 77.
Use of uninitialized value $name in string ne at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 114.
Use of uninitialized value $name in hash element at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 118.
Dies bei jeder Abfrage, bei unterschiedlichen Endpoints. z.B. http://192.168.2.30/api/index
{"menu":{"name":["Live","Serial / Control","Settings","-","REST API","-","Update","System","-","Documentation"],"link":["/live","/serial","/setup",null,"/api",null,"/update","/system",null,"https://ahoydtu.de"],"trgt":[null,null,null,null,"_blank",null,null,null,null,"_blank"]},"generic":{"version":"0.5.66","build":"f8fe044","wifi_rssi":-77,"ts_uptime":171934,"esp_type":"ESP8266"},"ts_now":1676568809,"ts_sunrise":1676528591,"ts_sunset":1676564782,"ts_offset":0,"disNightComm":false,"inverter":[],"warnings":[],"infos":[]}
Kennt jemand, in Verbindung mit JsonMod und Ahoi_DTU, diese Thematik zufällig?
Grüße
Ralf
Hi,
ich brauche mal eure Hilfe bei der Einbindung der AhoyDTU in FHEM via MQTT.
Das MQTT2 device für die DTU habe ich angelegt und ich bekomme auch Readings für version und uptime.
Was leider nicht klappt ist das automatische Anlegen der weiteren Geräte, so dass ich das inverter Template zuweisen kann.
AhoyDTU ist 0.5.66 und hier ein paar Auszüge aus dem Log (MQTT verbose 5). Man kann sehen, dass die Daten des Inverters dort ankommen, aber scheinbar nicht ausgewertet werden:
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch1/U_DC0.7
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch1/U_DC\0000.7
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch1/I_DC0.01
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch1/I_DC\0000.01
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch1/P_DC0
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch1/P_DC\0000
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(19)/HM600/ch1/YieldDay0
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch1/YieldDay\0000
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(21)/HM600/ch1/YieldTotal0
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch1/YieldTotal\0000
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(22)/HM600/ch1/Irradiation0
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch1/Irradiation\0000
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch2/U_DC25.8
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch2/U_DC\00025.8
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch2/I_DC6.19
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch2/I_DC\0006.19
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch2/P_DC158.6
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch2/P_DC\000158.6
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(19)/HM600/ch2/YieldDay157
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch2/YieldDay\000157
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(21)/HM600/ch2/YieldTotal0.157
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch2/YieldTotal\0000.157
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(22)/HM600/ch2/Irradiation52.867
2023.02.16 17:48:38 5: myBroker: dispatch autocreate=no\000myBroker\000/HM600/ch2/Irradiation\00052.867
2023.02.16 17:48:38 5: myBroker: received PUBLISH (0)(15)/HM600/ch0/U_AC231.3
Was mache ich falsch oder muss ich tun?
Gruß, Matthias
Steht schon weiter oben:
1. AHOYDUT über MQTT mit FHEM verbinden.
2. Diesem MQTT Device das das Attribut template "Homiles-Microinverter-Hub_Bridge" zuweisten
3. Dann wird ein neues MQTT device per Autocreate angelegt.
4. Dieses Device soll dann das Attribut Template "hoymiles_microinverter_inverter" bekommen. (wenn das Template da ist) dauert etwas..
Soweit die Theorie, aber nach Schritt 2 passiert nichts mehr.
Das neue MQTT device wird nicht angelegt und ich habe keine Ahnung warum.
Autocreate steht auf 1, aber es scheint nicht zu funktionieren.
Kann ich manuell etwas machen/anlegen?
In https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele) gibt es einen Abschnitt "autocreate funktioniert anscheinend nicht?" ... vielleicht hilft's ...
So, ich habe nun auch die richtige Stelle für das autocreate gefunden und der Wechselrichter wurde erfolgreich angelegt.
Inverter Template ist zugewiesen und die Werte werden ausgelesen.
Eine Sache funktioniert allerdings noch nicht und die ist mir wichtig.
Das Schreiben des Limits klappt nicht.
Es geht weder über set inverter_name limit, noch über set IO publish Base_ID/devcontrol/0/11/0 50
Muss ich noch was an der setList anpassen?
Über die Ahoy Webgui funktioniert es.
Bitte code-tags verwenden.
Falls da "Base_ID" steht, ist es falsch. Muss HM600 sein.
Ich habe Base_ID nur als allgemeinen Wert hingeschrieben.
Muss es der Name des Topics sein, dann wäre es DTU, so wie ich es auch verwende.
Oder muss es der Name des inverters sein? Dann wäre HM600 richtig.
Wenn man die funktionierende readingList sehen würde, wäre es einfacher, so tippe ich weiter auf "/HM600"....
Kein Problem,
hier ist die funktionerende Readinglist:
DTU/HM600/ch0/U_AC:.* U_AC
DTU/HM600/ch0/I_AC:.* I_AC
DTU/HM600/ch0/P_AC:.* P_AC
DTU/HM600/ch0/Freq:.* Freq
DTU/HM600/ch0/Temp:.* temperature
DTU/HM600/ch0/YieldDay:.* YieldDay
DTU/HM600/ch0/YieldTotal:.* YieldTotal
DTU/HM600/ch0/FWVersion:.* FWVersion
DTU/HM600/ch0/FWBuildYear:.* FWBuildYear
DTU/HM600/ch0/FWBuildMonthDay:.* FWBuildMonthDay
DTU/HM600/ch0/HWPartId:.* HWPartId
DTU/HM600/ch0/PowerLimit:.* limit
DTU/HM600/ch1/I_DC:.* I_DC1
DTU/HM600/ch1/P_DC:.* P_DC1
DTU/HM600/ch1/YieldDay:.* YieldDay1
DTU/HM600/ch1/YieldTotal:.* YieldTotal1
DTU/HM600/ch2/I_DC:.* I_DC2
DTU/HM600/ch2/P_DC:.* P_DC2
DTU/HM600/ch2/YieldDay:.* YieldDay2
DTU/HM600/ch2/YieldTotal:.* YieldTotal2
DTU/HM600/ch0/FWBuildHourMinute:.* FWBuildHourMinute
DTU/HM600/ch1/U_DC:.* U_DC
DTU/HM600/ch1/Irradiation:.* Irradiation
DTU/HM600/ch2/U_DC:.* U_DC
DTU/HM600/ch2/Irradiation:.* Irradiation
DTU/HM600/ch0/Q_AC:.* Q_AC
DTU/HM600/ch0/F_AC:.* F_AC
DTU/HM600/ch0/PF_AC:.* PF_AC
DTU/HM600/ch0/ALARM_MES_ID:.* ALARM_MES_ID
DTU/HM600/ch0/P_DC:.* P_DC
DTU/HM600/ch0/Efficiency:.* Efficiency
DTU/HM600/ch0/active\x20PowerLimit:.* active_PowerLimit
DTU/HM600/ch0/LastAlarmCode:.* LastAlarmCode
Ich habe noch etwas anderes probiert, weil ich in der Anleitung gesehen habe, dass es noch einen anderen Weg gibt, um das Limit zu setzen.
(https://github.com/lumapu/ahoy/blob/main/User_Manual.md)
Neben devcontrol geht es wohl auch mit topic/ctrl/limit_nonpersistent_absolute/inverter_id Wert.
Ich war also mit folgendem Kommando erfolgreich:
DTU/ctrl/limit_nonpersistent_absolute/0 50
Wo nun genau der unterschied zwischen devcontrol und ctrl liegt und warum das eine funktioniert und das andere nicht, kann ich nicht erklären.
Schön wäre, wenn ich es auch über das set limit aus der template hinbekommen könnte, im Notfall mache ich es aber nun manuell über ein einzelnes mqtt Kommando.
Zitat von: RalfP am 16 Februar 2023, 19:05:41
Hallo,
ich habe den Ahoi_DTU jetzt in Betrieb, aber noch keinen Inverter dran. Das braucht noch ein wenig.
Ich probiere gerade JsonMod auf den verschiedenen Endpoints. Die Informationen werden in Reading geschrieben. Von aussen sieht alles gut aus, so das ich ganz zuversichtlich bin/war, das ich später auch Daten erhalte, um z.B. einen Plot zu erstellen.
Leider habe ich aber im Log folgendes:
Use of uninitialized value $name in substitution (s///) at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 105.
Use of uninitialized value $name in exists at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 108.
Use of uninitialized value $name in lc at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 109.
Use of uninitialized value $find in exists at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode/Alias.pm line 25.
Use of uninitialized value $find in hash element at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode/Alias.pm line 77.
Use of uninitialized value $name in string ne at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 114.
Use of uninitialized value $name in hash element at /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line 118.
Dies bei jeder Abfrage, bei unterschiedlichen Endpoints. z.B. http://192.168.2.30/api/index
{"menu":{"name":["Live","Serial / Control","Settings","-","REST API","-","Update","System","-","Documentation"],"link":["/live","/serial","/setup",null,"/api",null,"/update","/system",null,"https://ahoydtu.de"],"trgt":[null,null,null,null,"_blank",null,null,null,null,"_blank"]},"generic":{"version":"0.5.66","build":"f8fe044","wifi_rssi":-77,"ts_uptime":171934,"esp_type":"ESP8266"},"ts_now":1676568809,"ts_sunrise":1676528591,"ts_sunset":1676564782,"ts_offset":0,"disNightComm":false,"inverter":[],"warnings":[],"infos":[]}
Kennt jemand, in Verbindung mit JsonMod und Ahoi_DTU, diese Thematik zufällig?
Grüße
Ralf
Die Ursache ist, im Zusammenspiel mit JsonMod, das im Response Header
HTTP/1.0 200 OK
Content-Length: 919
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: content-typekein "charset=xxx" vorkommt. Unter https://github.com/lumapu/ahoy/issues/597 wurde dies, meines Erachtens, schon angesprochen. Ich hoffe mal, das dieser Punkt in eines der nächsten Releases mit einfließt. Ich habe mir vorerst die JsonMod etwas abgeändert und den Entwickler von JsonMod mal angeschrieben.
Grüße
Ralf
Hallo,
jetzt muss ich mich hier auch mal dranhängen...
Seit gestern habe ich meinen Inverter, einen HM-600.
Leider noch keine Panels, dauert noch ein wenig :-\
Dachte mir aber ich fange schon mal mit der Integration an :)
Hab auf 2 Testsystemen schon einiges rumprobiert, schaffe es aber auch nicht, ein Inverter-Device zu erhalten... :-\
(oder geht das nur, wenn schon mal mit dem Inverter kommuniziert wurde, geht ja leider noch nicht, solange keine Panels dran hängen, wenn ich das richtig verstanden habe)
Meine Ahoy-Konfiguration ist wie folgt:
Device-Name: AHOY-DTU (Standard, nichts geändert)
Inverter
Serial Number: Seriennummer des Inverters (sollte aber für mqtt-Anbindung irrelevat sein?)
Name: HM-600
Max Module Power (Wp): 380 380 (ist aber ja optional?)
Module Name: 01 02 (hatte ich bislang leer)
MQTT
Topic: HM600
Verbindungsdaten passend zu meinem jeweiligen Test-fhem
Mehr gibt es ja nicht einzustellen?
---------------------------- meine Tests ------------------------------
Dann auf meinem 1. Testsystem mit dem bereits vorhandenen MQTT2Server getestet:
Zunächst falsches Template (openDTUbrigde) -> ok, gelöscht
Dann richtiges Template (hoymiles_microinverter_hub_bridge), dabei wurde nach DEVICE_ID gefragt, ich habe "HM600" angegeben.
Es kamen auch Daten aber es wurde kein Wechselrichter-/Inverter-Device angelegt... :-\
Gut dachte ich: löschen und neuen MQTT2Server angelegt (anderer Port), evtl. ist der vorhandene durch diverse Tests etwas "verkonfiguriert". Aber damit dann dasselbe Spiel... :-\
Wieder MQTT2_Device gelöscht und neu, ESP gebootet, diesmal bzw. ab irgendwann mal wurde beim Anwenden des Templates gar nicht mehr gefragt...
Dann, um sicher zu gehen, mein neuestes Testsystem genommen (bislang nur zum Test von Weather), einen MQTT2Server angelegt und den ESP/AHOY damit verbunden.
MQTT2_Device wird angelegt. AttrTemplate angewendet: keine Frage? Es kam nur "Erfolgreich angewendet..."
Dann weiter nichts :-\
Jetzt sieht es auf meinem saubersten Testsystem wie folgt aus:
list MQTT2Server:
Internals:
CFGFN
CONNECTS 3
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 4
FUUID 63f0b323-f33f-a014-e09d-94b5a1ef90970039
NAME MQTT2Server
NR 47
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
eventCount 5
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-02-18 12:31:34 nrclients 1
2023-02-18 12:14:43 state Initialized
clients:
MQTT2Server_192.168.10.210_54215 1
retain:
Attributes:
und "copy for Forum":
define MQTT2Server MQTT2_SERVER 1883 global
# CFGFN
# CONNECTS 3
# Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
# ClientsKeepOrder 1
# DEF 1883 global
# FD 4
# FUUID 63f0b323-f33f-a014-e09d-94b5a1ef90970039
# NAME MQTT2Server
# NR 47
# PORT 1883
# STATE Initialized
# TYPE MQTT2_SERVER
# eventCount 5
# MatchList:
# 1:MQTT2_DEVICE ^.
# 2:MQTT_GENERIC_BRIDGE ^.
# READINGS:
# 2023-02-18 12:31:34 nrclients 1
# 2023-02-18 12:14:43 state Initialized
# clients:
# MQTT2Server_192.168.10.210_54215 1
# retain:
#
setstate MQTT2Server 2023-02-18 12:31:34 nrclients 1
setstate MQTT2Server 2023-02-18 12:14:43 state Initialized
Und hier list/RawDef des MQTT2_Device:
Internals:
CFGFN
CID AHOY_DTU
DEF AHOY_DTU
FUUID 63f0b419-f33f-a014-af24-fcf85cc91aeece88
IODev MQTT2Server
LASTInputDev MQTT2Server
MQTT2Server_CONN MQTT2Server_192.168.10.210_54215
MQTT2Server_MSGCNT 93
MQTT2Server_TIME 2023-02-18 12:42:12
MSGCNT 93
NAME MQTT2_AHOY_DTU
NR 50
STATE ???
TYPE MQTT2_DEVICE
eventCount 118
OLDREADINGS:
READINGS:
2023-02-18 12:20:12 attrTemplateVersion 20200812
2023-02-18 12:32:12 available 0
2023-02-18 12:31:19 comm_start 1676701276
2023-02-18 12:31:19 comm_stop 1676738346
2023-02-18 12:31:15 device AHOY-DTU
2023-02-18 12:31:19 dis_night_comm false
2023-02-18 12:42:12 free_heap 187752
2023-02-18 12:32:12 last_success 0
2023-02-18 12:31:15 mqtt connected
2023-02-18 12:32:12 status 0
2023-02-18 12:31:19 sunrise 1676701276
2023-02-18 12:31:19 sunset 1676738346
2023-02-18 12:42:12 uptime 660
2023-02-18 12:31:15 version 0.5.66
2023-02-18 12:42:12 wifi_rssi -65
Attributes:
autocreate 1
bridgeRegexp HM600/([^/]+)/ch[0-9]+/.*:.* "HM600_$1"
icon solar
model hoymiles_microinverter_hub_bridge
readingList HM600/version:.* version
HM600/free_heap:.* free_heap
HM600/uptime:.* uptime
HM600/device:.* device
AHOY_DTU:HM600/wifi_rssi:.* wifi_rssi
AHOY_DTU:HM600/HM-600/available:.* available
AHOY_DTU:HM600/HM-600/last_success:.* last_success
AHOY_DTU:HM600/status:.* status
AHOY_DTU:HM600/mqtt:.* mqtt
AHOY_DTU:HM600/sunrise:.* sunrise
AHOY_DTU:HM600/sunset:.* sunset
AHOY_DTU:HM600/comm_start:.* comm_start
AHOY_DTU:HM600/comm_stop:.* comm_stop
AHOY_DTU:HM600/dis_night_comm:.* dis_night_comm
room MQTT2_DEVICE
setStateList on off
defmod MQTT2_AHOY_DTU MQTT2_DEVICE AHOY_DTU
attr MQTT2_AHOY_DTU autocreate 1
attr MQTT2_AHOY_DTU bridgeRegexp HM600/([^/]+)/ch[0-9]+/.*:.* "HM600_$1"
attr MQTT2_AHOY_DTU icon solar
attr MQTT2_AHOY_DTU model hoymiles_microinverter_hub_bridge
attr MQTT2_AHOY_DTU readingList HM600/version:.* version\
HM600/free_heap:.* free_heap\
HM600/uptime:.* uptime\
HM600/device:.* device\
AHOY_DTU:HM600/wifi_rssi:.* wifi_rssi\
AHOY_DTU:HM600/HM-600/available:.* available\
AHOY_DTU:HM600/HM-600/last_success:.* last_success\
AHOY_DTU:HM600/status:.* status\
AHOY_DTU:HM600/mqtt:.* mqtt\
AHOY_DTU:HM600/sunrise:.* sunrise\
AHOY_DTU:HM600/sunset:.* sunset\
AHOY_DTU:HM600/comm_start:.* comm_start\
AHOY_DTU:HM600/comm_stop:.* comm_stop\
AHOY_DTU:HM600/dis_night_comm:.* dis_night_comm
attr MQTT2_AHOY_DTU room MQTT2_DEVICE
attr MQTT2_AHOY_DTU setStateList on off
setstate MQTT2_AHOY_DTU 2023-02-18 12:20:12 attrTemplateVersion 20200812
setstate MQTT2_AHOY_DTU 2023-02-18 12:32:12 available 0
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:19 comm_start 1676701276
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:19 comm_stop 1676738346
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:15 device AHOY-DTU
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:19 dis_night_comm false
setstate MQTT2_AHOY_DTU 2023-02-18 12:43:12 free_heap 187828
setstate MQTT2_AHOY_DTU 2023-02-18 12:32:12 last_success 0
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:15 mqtt connected
setstate MQTT2_AHOY_DTU 2023-02-18 12:32:12 status 0
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:19 sunrise 1676701276
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:19 sunset 1676738346
setstate MQTT2_AHOY_DTU 2023-02-18 12:43:12 uptime 720
setstate MQTT2_AHOY_DTU 2023-02-18 12:31:15 version 0.5.66
setstate MQTT2_AHOY_DTU 2023-02-18 12:43:12 wifi_rssi -69
Habe ich etwas falsch gemacht?
Oder geht das erst, wenn der Inverter auch Daten liefert (was ja ohne Panels nicht passiert?)?
Was ich nicht verstehe: mal kommt die Frage nach "DEVICE_ID" und mal nicht und v.a. bei meinem frischen, sauberen Testsystem kam sie nie! (bei den Tests auf dem anderen Testsystem: ok, da ist so viel rumprobiert worden mit mqtt...)
Vielen Dank schon mal!!
Gruß, Joachim
So, etwas weiter (denke ich?): ich habe die latest FW aufgespielt (nachdem ich gesehen hatte, dass die aktuelle stable 2 Monate alt ist?).
Danach wurde ein weiteres MQTT2_Device angelegt...
Leider kann ich in der AttrTemplate-Liste das notwendige Template (noch) nicht finden...
Irgendwie bin ich verwirrt (was bei mqtt oft vorkommt, leider).
Ich habe nun (einfach) auf das neu angelegte MQTT2_Device ebenfalls das AttrTemplate (hoymiles_microinverter_hub_bridge) angewendet, war das richtig?
Wenn ja: warum habe ich nun 2 "Bridge-Devices"?
Woher kommt das _CD1294 im Namen des neuen Devices?
Konnte in der Konfiguration von AHOY nichts finden.
Devicename ist immer noch AHOY-DTU...
Ich habe beim mqtt mal eingestellt alle 10s senden, dachte vielleicht hilft das (habe ja leider immer noch keine Panels)...
...werde ich aber wieder auf 0 setzen (also deaktivieren / nur senden, wenn es auch was zu senden gibt)...
Hier aktuelle lists/RawDefs:
"altes Device"
defmod MQTT2_AHOY_DTU MQTT2_DEVICE AHOY_DTU
attr MQTT2_AHOY_DTU autocreate 1
attr MQTT2_AHOY_DTU bridgeRegexp HM600/([^/]+)/ch[0-9]+/.*:.* "HM600_$1"
attr MQTT2_AHOY_DTU icon solar
attr MQTT2_AHOY_DTU model hoymiles_microinverter_hub_bridge
attr MQTT2_AHOY_DTU readingList HM600/version:.* version\
HM600/free_heap:.* free_heap\
HM600/uptime:.* uptime\
HM600/device:.* device\
AHOY_DTU:HM600/wifi_rssi:.* wifi_rssi\
AHOY_DTU:HM600/HM-600/available:.* available\
AHOY_DTU:HM600/HM-600/last_success:.* last_success\
AHOY_DTU:HM600/status:.* status\
AHOY_DTU:HM600/mqtt:.* mqtt\
AHOY_DTU:HM600/sunrise:.* sunrise\
AHOY_DTU:HM600/sunset:.* sunset\
AHOY_DTU:HM600/comm_start:.* comm_start\
AHOY_DTU:HM600/comm_stop:.* comm_stop\
AHOY_DTU:HM600/dis_night_comm:.* dis_night_comm
attr MQTT2_AHOY_DTU room MQTT2_DEVICE
attr MQTT2_AHOY_DTU setStateList on off
setstate MQTT2_AHOY_DTU 2023-02-18 12:20:12 attrTemplateVersion 20200812
setstate MQTT2_AHOY_DTU 2023-02-18 13:42:14 available 0
setstate MQTT2_AHOY_DTU 2023-02-18 13:41:21 comm_start 1676701276
setstate MQTT2_AHOY_DTU 2023-02-18 13:41:21 comm_stop 1676738346
setstate MQTT2_AHOY_DTU 2023-02-18 13:51:56 device AHOY-DTU
setstate MQTT2_AHOY_DTU 2023-02-18 13:41:21 dis_night_comm false
setstate MQTT2_AHOY_DTU 2023-02-18 14:00:56 free_heap 189140
setstate MQTT2_AHOY_DTU 2023-02-18 13:42:14 last_success 0
setstate MQTT2_AHOY_DTU 2023-02-18 13:44:47 mqtt not connected
setstate MQTT2_AHOY_DTU 2023-02-18 13:42:14 status 0
setstate MQTT2_AHOY_DTU 2023-02-18 13:41:21 sunrise 1676701276
setstate MQTT2_AHOY_DTU 2023-02-18 13:41:21 sunset 1676738346
setstate MQTT2_AHOY_DTU 2023-02-18 14:00:56 uptime 559
setstate MQTT2_AHOY_DTU 2023-02-18 13:51:56 version 0.5.89
setstate MQTT2_AHOY_DTU 2023-02-18 13:44:14 wifi_rssi -69
"neues Device" nach attrTemplate
defmod MQTT2_AHOY_DTU_CD1294 MQTT2_DEVICE AHOY_DTU_CD1294
attr MQTT2_AHOY_DTU_CD1294 autocreate 1
attr MQTT2_AHOY_DTU_CD1294 bridgeRegexp HM600/([^/]+)/ch[0-9]+/.*:.* "HM600_$1"
attr MQTT2_AHOY_DTU_CD1294 icon solar
attr MQTT2_AHOY_DTU_CD1294 model hoymiles_microinverter_hub_bridge
attr MQTT2_AHOY_DTU_CD1294 readingList HM600/version:.* version\
HM600/free_heap:.* free_heap\
HM600/uptime:.* uptime\
HM600/device:.* device\
AHOY_DTU_CD1294:HM600/wifi_rssi:.* wifi_rssi\
AHOY_DTU_CD1294:HM600/total/P_AC:.* P_AC\
AHOY_DTU_CD1294:HM600/total/YieldTotal:.* YieldTotal\
AHOY_DTU_CD1294:HM600/total/YieldDay:.* YieldDay\
AHOY_DTU_CD1294:HM600/total/P_DC:.* P_DC
attr MQTT2_AHOY_DTU_CD1294 room MQTT2_DEVICE
attr MQTT2_AHOY_DTU_CD1294 setStateList on off
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:03:27 P_AC 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:03:27 P_DC 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:03:27 YieldDay 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:03:27 YieldTotal 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 13:52:53 attrTemplateVersion 20200812
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:02:56 free_heap 189140
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:02:56 uptime 679
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:02:56 wifi_rssi -62
EDIT: Update, RawDef des "neuen Devices" nach reboot (Umstellen von 10s senden auf 0 -> deaktiviert)
defmod MQTT2_AHOY_DTU_CD1294 MQTT2_DEVICE AHOY_DTU_CD1294
attr MQTT2_AHOY_DTU_CD1294 autocreate 1
attr MQTT2_AHOY_DTU_CD1294 bridgeRegexp HM600/([^/]+)/ch[0-9]+/.*:.* "HM600_$1"
attr MQTT2_AHOY_DTU_CD1294 icon solar
attr MQTT2_AHOY_DTU_CD1294 model hoymiles_microinverter_hub_bridge
attr MQTT2_AHOY_DTU_CD1294 readingList HM600/version:.* version\
HM600/free_heap:.* free_heap\
HM600/uptime:.* uptime\
HM600/device:.* device\
AHOY_DTU_CD1294:HM600/wifi_rssi:.* wifi_rssi\
AHOY_DTU_CD1294:HM600/total/P_AC:.* P_AC\
AHOY_DTU_CD1294:HM600/total/YieldTotal:.* YieldTotal\
AHOY_DTU_CD1294:HM600/total/YieldDay:.* YieldDay\
AHOY_DTU_CD1294:HM600/total/P_DC:.* P_DC\
AHOY_DTU_CD1294:HM600/ip_addr:.* ip_addr\
AHOY_DTU_CD1294:HM600/mqtt:.* mqtt\
AHOY_DTU_CD1294:HM600/sunrise:.* sunrise\
AHOY_DTU_CD1294:HM600/sunset:.* sunset\
AHOY_DTU_CD1294:HM600/comm_start:.* comm_start\
AHOY_DTU_CD1294:HM600/comm_stop:.* comm_stop\
AHOY_DTU_CD1294:HM600/dis_night_comm:.* dis_night_comm\
AHOY_DTU_CD1294:HM600/comm_disabled:.* comm_disabled\
AHOY_DTU_CD1294:HM600/comm_dis_ts:.* comm_dis_ts
attr MQTT2_AHOY_DTU_CD1294 room MQTT2_DEVICE
attr MQTT2_AHOY_DTU_CD1294 setStateList on off
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:07 P_AC 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:07 P_DC 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:07 YieldDay 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:07 YieldTotal 0
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 13:52:53 attrTemplateVersion 20200812
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:39 comm_dis_ts 1676725660
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:39 comm_disabled false
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 comm_start 1676701276
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 comm_stop 1676738346
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 device AHOY-DTU
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 dis_night_comm false
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:08:35 free_heap 188788
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 ip_addr 192.168.10.210
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 mqtt connected
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 sunrise 1676701276
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 sunset 1676738346
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:08:34 uptime 79
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:07:35 version 0.5.89
setstate MQTT2_AHOY_DTU_CD1294 2023-02-18 14:08:35 wifi_rssi -61
Das scheint wohl jetzt das "gültige" Bridge-Device zu sein?
Das "alte" zeigt "mqtt disconnected" (klar die Messages kommen ja jetzt unter "AHOY_DTU_CD1294" statt "AHOY_DTU", frage mich aber immer noch wo die "_CD1294" herkommt / konnte in der AHOY Konfig dazu nirgends etwas finden :-\ )...
Gruß, Joachim
So ist die Vorgehensweise:
1. AHOYDTU über MQTT mit FHEM verbinden ( das ist das Empfangsdevice für die DTUs Solar Inverter die du hast)
2. Diesem MQTT Device das das Attribut template "Homiles-Microinverter-Hub_Bridge" zuweisten
3. Diese Bridge empfängt nun Signale vom Homiles Inverter.. Daher wird wird ein neues MQTT device per Autocreate angelegt.
4. Dieses Device soll dann das Attribut Template "Homymiles_microinverter_inverter" bekommen. (das hat bei mir einen Tag gedauert bis das Template verfügbar war)
Gruss Gerd
Zitat von: GeZi3560 am 18 Februar 2023, 17:58:27
So ist die Vorgehensweise:
1. AHOYDTU über MQTT mit FHEM verbinden ( das ist das Empfangsdevice für die DTUs Solar Inverter die du hast)
2. Diesem MQTT Device das das Attribut template "Homiles-Microinverter-Hub_Bridge" zuweisten
3. Diese Bridge empfängt nun Signale vom Homiles Inverter.. Daher wird wird ein neues MQTT device per Autocreate angelegt.
4. Dieses Device soll dann das Attribut Template "Homymiles_microinverter_inverter" bekommen. (das hat bei mir einen Tag gedauert bis das Template verfügbar war)
Gruss Gerd
Vorgehen gelesen und auch so gemacht.
ABER: Punkt 3 und 4 passieren eben NICHT!
UND: warum habe ich nach FW-Update (latest Dev) "plötzlich" ein weiteres "Bridge-Device", mit dem Anhängsel "_CD1294"?
Wie geschrieben: ich habe noch keine Panels :-\
So ich gelesen habe sendet wohl der Inverter erst, wenn er mit einem Panel verbunden ist und das auch Strom liefert...
Wenn das so ist und auch erst dann das weitere MQTT2Device angelegt wird ist es klar...
(ist dem so?)
Bleibt halt immer noch das mit dem "_CD1294" aber egal, sofern es nicht bei jedem FW-Update ein neues MQTT2Device-Device gibt kann ich damit leben bzw. kann ich auch einfach wieder mit der Stable-Version ins Rennen gehen...
Muss ich wohl auf die Panels warten :-\
Dachte ich könnte schon vorher etwas tun/testen, mich würde ja auch interessieren, ob der HM-600 funktioniert...
...wenn ich den ohne Panels einstecke, passiert grad gar nichts...
Also kein Blinken etc. nicht mal ein "Fehler-Blinken"...
Ist das normal so?
Danke, Joachim
Um das nachzustellen müsste ich meine Konfig löschen und die Panels abklemmen.
Sorry, kann ich nicht helfen.
ZitatSo ich gelesen habe sendet wohl der Inverter erst, wenn er mit einem Panel verbunden ist und das auch Strom liefert...
Wenn das so ist und auch erst dann das weitere MQTT2Device angelegt wird ist es klar...
(ist dem so?)
Hab mir letztes Jahr schon die gleichen Fragen gestellt, Wechselrichter hab ich schon, aber immer noch keine Panels und auch immer noch nicht mit beschäftigt ::)
Beta-User meinte dazu folgendes:
ZitatDer WR ist nur funktechnisch zu erreichen, wenn DC was anliegt (ca. 16-18V), AC ist dem egal und entscheidet nur darüber, ob er produziert ;) .
Und weiter (wegen der Platine):
ZitatAber wenn du einen hast mit "guter" Nummer (Beginnt afaik mit 1141), sollte das kein Problem sein, und das GW kannst du mit MiLight-Hub (oder MySensors-nRF-GW) auf Funktion testen (mehr oder weniger dieselbe Hardware).
Also ich warte bis Panels da sind.
Zitat
Der WR ist nur funktechnisch zu erreichen, wenn DC was anliegt (ca. 16-18V), AC ist dem egal und entscheidet nur darüber, ob er produziert ;) .
Gut, dann ist das geklärt...
Da ich eh vorhabe einen Akku zu nutzen (https://forum.fhem.de/index.php/topic,128142.msg1234332.html#msg1234332) werde ich den Teil schon mal zum Testen nehmen:
Akku -> DC-DC Konverter (ist schon bestellt) -> Inverter
Bis die Panels kommen...
Gruß, Joachim
Meine Frage ist leider noch nicht beantwortet, bzw. mein Problem nicht gelöst.
Warum kann ich meinen Wechselrichter via MQTT und dem Befehl /ctrl/ steuern, aber mit /devcontrol/ nicht?
Wenn ich ctrl nutze, dann sehe ich auch unter Serial/Control auf der DTU, dass ein topic empfangen wurden, bei /devcontrol/ passiert gar nichts.
Und dann habe ich noch drei Fragen:
1) Gibt es einen Grund, dass die Spannung der beiden Kanäle nicht unterschieden wird?
DTU/HM600/ch1/U_DC:.* U_DC
DTU/HM600/ch1/Irradiation:.* Irradiation
DTU/HM600/ch2/U_DC:.* U_DC
DTU/HM600/ch2/Irradiation:.* Irradiation
Ich habe nur einen Kanal belegt und wollte die Spannung dort überwachen. Der Wert wurde aber von dem nicht genutzten Kanal überschrieben.
Ich habe es selber gelöst, in dem ich U_DC1 und U_DC2 draus gemacht habe, aber kann das im template aufgenommen/angepasst werden?
2) Funktoniert auch OpenDTU mit fhem? Kann ich damit das gleiche tun? Welches sind die Vorteile von AhoyDTU gegenüber OpenDTU?
3) AhoyDTU läuft leider nicht stabil und rebooted alle 1-3 Stunden. Einen Kondensator habe ich schon verbaut, hat aber nicht geholfen. Liegt es nur an der Leistung des angeschlossesn Moduls?
@MadMax-FHEM: was meinst du mit FW Update?
Wo hast du was wovon geupdatet?
Zitat von: masterpete23 am 20 Februar 2023, 12:20:41
@MadMax-FHEM: was meinst du mit FW Update?
Wo hast du was wovon geupdatet?
Ahoy:
Zitat
2023-02-18 12:31:15 version 0.5.66
Zitat
2023-02-18 13:51:56 version 0.5.89
Die 0.5.66 ist wohl die letzte/aktuellste "stable" (laut git oder so aber 2 Monate alt?)...
...die 0.5.89 ist wohl die aktuellste "nightly"/"developer"...
Es gibt bei der neuen etwas mehr Einstellungen, ansonsten habe ich ohne laufenden/funkenden Inverter noch nichts gemerkt...
Heute ist der DC-DC Stepup gekommen und die Anschlusskabel :)
Wenn Zeit ist, werde ich mal versuchen damit den Wechselrichter zum Funken zu bewegen...
Gruß, Joachim
Zitat von: masterpete23 am 23 Januar 2023, 21:07:48
Hat jemand eine gute Lösung des Loggings und der Auswertung mit hohem WAF?
Nun habe ich Zahlen in meiner logdb und suche noch was grafisches..
Keine Ahnung was genau Du Dir da vorstellst... ich hab' 3 Plots mit unterschiedlichen Informationen, siehe Anhang.
Zitat von: fritzhugo123 am 19 Februar 2023, 11:01:50
Warum kann ich meinen Wechselrichter via MQTT und dem Befehl /ctrl/ steuern, aber mit /devcontrol/ nicht?
Wenn ich ctrl nutze, dann sehe ich auch unter Serial/Control auf der DTU, dass ein topic empfangen wurden, bei /devcontrol/ passiert gar nichts.
Ist vermutlich (noch) ein bug der firmware oder es wurde endgültig was geändert, muss ich nochmal checken, diese Teile wurden relativ früh hier aufgenommen.
Zitat
Und dann habe ich noch drei Fragen:
1) Gibt es einen Grund, dass die Spannung der beiden Kanäle nicht unterschieden wird?
Das scheint einfach im Lauf der Zeit dazugekommen zu sein, das attrTemplate ist jetzt erweitert (morgiges update), dann sollte das auch unterschieden werden.
Zitat
2) Funktoniert auch OpenDTU mit fhem? Kann ich damit das gleiche tun? Welches sind die Vorteile von AhoyDTU gegenüber OpenDTU?
Das kann auch MQTT, also kann es in FHEM eingebunden werden, es gibt auch ein (rudimentäres?) attrTemplate dazu.
AhoyDTU wird (hoffentlich!) mittelfristig die für FHEM günstigere MQTT-Implementierung (insbes. JSON) bieten und hat (zum. übergangsweise) bei den älteren MI-Modellen die Nase vorn (habe heute noch etwas am Code gebastelt, siehe discord-channel).
Zitat
3) AhoyDTU läuft leider nicht stabil und rebooted alle 1-3 Stunden. Einen Kondensator habe ich schon verbaut, hat aber nicht geholfen. Liegt es nur an der Leistung des angeschlossesn Moduls?
Falls du einen ESP8266 nutzt: Das liegt evtl. an einer ungünstigen PIN-Belegung va. was den interrupt-PIN angeht. Ggf. ändern. Kondensator hilft nur gegen schlechte Sende-Leistungen des nRF, hat aber mit reboots nichts zu tun.
Mein ESP32 lief bisher mit jeder Version ohne Zicken, reboots kenne ich da nur, wenn ich die absichtlich verursache, das Ding lief zuletzt auch schon mal 2 Wochen ohne irgendwelche komischen Effekte. (Ich habe "ein paar" Inverter im Einsatz, daher der ESP32).
Grundsätzlich sind Fragen zum ESP-Code an sich besser auf discord bzw. dem mikrocontroller-Forum aufgehoben!
habe jetzt mal die 0.5.92 drauf... ich bin leider nicht dazu gekommen den code anzusehen. Aber du Arbeitest ja schon fleissig daran.
Mir ist aufgefallen das ich bei der Ansicht die YieldTotal eigentlich YieldDay werte drin hat.
Ansonsten sind bei den beiden Panels Spannung Strom Leistung und Irradiation schon mal befülllt...
MQTT passt aber nichts :-)
in der Seriellen sieht es so aus:
11:23:54 I: Iv: 0
11:23:54 I: MI600/ch1/U_DC: 35.900 V
11:23:54 I: MI600/ch1/I_DC: 3.400 A
11:23:54 I: MI600/ch1/P_DC: 119.700 W
11:23:54 I: MI600/ch1/YieldTotal: 277.000 kWh
11:23:54 I: MI600/ch1/Irradiation: 32.351 %
11:23:54 I: MI600/ch2/U_DC: 36.100 V
11:23:54 I: MI600/ch2/I_DC: 3.100 A
11:23:54 I: MI600/ch2/P_DC: 110.400 W
11:23:54 I: MI600/ch2/YieldTotal: 257.000 kWh
11:23:54 I: MI600/ch2/Irradiation: 29.838 %
11:23:54 I: MI600/ch0/U_AC: 232.700 V
11:23:54 I: MI600/ch0/F_AC: 50.010 Hz
11:23:54 I: MI600/ch0/Temp: 18.900 °C
11:23:54 I: MI600/ch0/ALARM_MES_ID: 271.000
11:23:54 I: MI600/ch0/YieldTotal: 534.000 kWh
11:23:54 I: MI600/ch0/P_DC: 230.100 W
Gehe bitte auf das artifact von lumapu (0.5.93). Damit sollte das schon wieder besser passen, hatte da noch was geändert zwischen Unterversion 0.5.932 und 0.5.933.(in 0.5.93 sind dann die 9.33-Änderungen und etwas mehr drin).
ok, hab jetzt die GIT SHA: 71ea715 :: 0.5.93
jetzt sehe ich das hier
12:37:51 I: Iv: 0
12:37:51 I: MI600/ch1/U_DC: 35.200 V
12:37:51 I: MI600/ch1/I_DC: 3.700 A
12:37:51 I: MI600/ch1/P_DC: 126.500 W
12:37:51 I: MI600/ch1/YieldDay: 431.000 Wh
12:37:51 I: MI600/ch1/Irradiation: 34.189 %
12:37:51 I: MI600/ch0/U_AC: 237.100 V
12:37:51 I: MI600/ch0/F_AC: 50.010 Hz
12:37:51 I: MI600/ch0/Temp: 20.400 °C
12:37:51 I: MI600/ch0/YieldDay: 431.000 Wh
12:37:51 I: MI600/ch0/P_DC: 126.500 W
also Channel 2 fehlt jetzt, also das 2 Panel....
YieldDay würde wohl passen :-)
wir nähern uns an
Super, lumapu hat in der Version auch gleich das Darstellungsproblem gefixt :) .
Dass für Kanal 2 noch keine Werte kommen, ist vermutlich "nur" ein Problem der (zu) wenigen Messages, das ist der nächste größere Punkt.
PS: Es gibt noch status-Infos, die aber (noch) nicht per bridgeRegexp im Inverter-Device landen. Kannst du die mal händisch "umhängen"?
weis jetzt nicht genau was du meinst
bridgeRegexp
inverter/([^/]+)/ch[0-9]+/.*:.* "inverter_$1"
das habe ich jetzt drin.
Den ganzen Tag war nur 1 Panel zu sehen, jetzt wo die Sonne schwächer wird ist das 2 aufgetaucht...
16:39:33 I: Iv: 0
16:39:33 I: MI600/ch1/U_DC: 34.900 V
16:39:33 I: MI600/ch1/I_DC: 0.300 A
16:39:33 I: MI600/ch1/P_DC: 12.500 W
16:39:33 I: MI600/ch1/YieldDay: 671.000 Wh
16:39:33 I: MI600/ch1/Irradiation: 3.378 %
16:39:33 I: MI600/ch2/U_DC: 34.200 V
16:39:33 I: MI600/ch2/I_DC: 0.300 A
16:39:33 I: MI600/ch2/P_DC: 12.500 W
16:39:33 I: MI600/ch2/YieldDay: 573.000 Wh
16:39:33 I: MI600/ch2/Irradiation: 3.378 %
16:39:33 I: MI600/ch0/U_AC: 234.600 V
16:39:33 I: MI600/ch0/F_AC: 49.970 Hz
16:39:33 I: MI600/ch0/Temp: 14.600 °C
16:39:33 I: MI600/ch0/YieldDay: 1244.000 Wh
16:39:33 I: MI600/ch0/P_DC: 25.000 W
Zitat von: laserrichi am 03 März 2023, 16:40:29
weis jetzt nicht genau was du meinst
So herum ist es evtl. einfacher: Nachher kommt mal wieder ein update für den attrTemplate-Satz, der zwei neue Readings korrekt zuordnet.
Zitat
Den ganzen Tag war nur 1 Panel zu sehen, jetzt wo die Sonne schwächer wird ist das 2 aufgetaucht...
Das Problem ist weniger die Sonne, sondern eher die Struktur des Codes iVm. relativ wenigen Antworten...
Bin da prinzipiell dran, habe mir aber beim Umstrukturieren des Codes ein C-Problem eingefangen. Näheres in discord.
Zitat von: fritzhugo123 am 19 Februar 2023, 11:01:50
Warum kann ich meinen Wechselrichter via MQTT und dem Befehl /ctrl/ steuern, aber mit /devcontrol/ nicht?
Die MQTT-Schnittstelle scheint insgesamt auf /ctrl/ umgebaut worden zu sein, on/off sind entfallen (k.A., warum) und auch die Syntax hat sich geändert.
Habe daher gestern für Stände ab 0.5.99 die attrTemplate aktualisiert.
Bei Gelegenheit schaue ich mir dann mal die JSON-Variante an :) .
News zum Thema AhoyDTU: es gibt eine neue "stable", Version 0.6.0. Damit sollten dann auch die aktuell verteilten attrTemplate zusammenpassen.
Falls hier noch ein MI-User mitliest, der noch nicht auf den letzten dev-Versionen von Ahoy war: Zumindest MI-300 bis MI-800 sollten damit auch auslesbar sein. 4-kanalige MI (Mi-1000 bis MI-1500) könnten auch funktionieren, Rückmeldung steht da aber noch aus...
Zitat von: Beta-User am 28 März 2023, 12:06:33News zum Thema AhoyDTU: es gibt eine neue "stable", Version 0.6.0. Damit sollten dann auch die aktuell verteilten attrTemplate zusammenpassen.
Falls hier noch ein MI-User mitliest, der noch nicht auf den letzten dev-Versionen von Ahoy war: Zumindest MI-300 bis MI-800 sollten damit auch auslesbar sein. 4-kanalige MI (Mi-1000 bis MI-1500) könnten auch funktionieren, Rückmeldung steht da aber noch aus...
Ich bin beim template und ahoy noch auf einem älteren Stand. Welchen Weg empfiehlst du umzu aktualisieren?
Welche MQTT Config emfiehlst du in ahoy - scheint ja einiges neu zu sein laut Changelog (https://github.com/lumapu/ahoy/releases/tag/ahoy_v0.6.0)
Hmm, auf die Schnelle:
- FHEM-update für die aktuellen attrTemplate. Dann (am besten bei Nacht) mal das Zentraldevice auf den aktuellen template-Stand heben;
- Dann den ESP updaten (ggf. muss die Konfig neu gemacht werden, v.a. beim ESP32 muss man die SPI-PINs zum Teil ergänzen)
- zum Schluss die "Inverter"-MQTT2_DEVICEs anpassen (neue attrTemplate).
Grundsätzlich sind die Unterschiede nicht gewaltig, aber es funktionieren halt bestimmte Zweige nicht mehr, und manche Topics sind dazugekommen, die das alte Zentraldevice nicht sauber weiterverteilt.
Ach so: bzgl. 4-kanaligen MI gibt es noch einen kleinen bug, aber prinzipiell kann man auch die jetzt zumindest auswerten...
8)
(Wer einen älteren TSUN mit 10x1-er Nummer hat: Das ist auch MI-type).
Bei der Limitierung kann es sein, dass die als relative Limitierung mit den "größeren MI" ebenfalls schon klappt, bei den kleineren kann es sein, dass das gar nicht geht.
Falls jemand Zeit und Lust hat, devStateIcon-Code (für die DTU und/oder die Inverter) beizusteuern: feel free!
Was die Inverter angeht: Mir würde vorschweben, "pah-color" zu nutzen, um die einzelnen Panels anzuzeigen und auf Basis der Irridation zu färben, dazu die aktuelle Gesamtleistung, den heutigen Ertrag und den "allgemeinen Status", also offline, erreichbar oder in Produktion (rot/orange/grün).
@Beta-User : du verwaltest doch auch das OpenDTU MQTT Template ->
Bei der Beschreibung von hoymiles_opendtu_microinverter steht :
Use this with "opendtu" firmware for ESP8266+nRF24L01+OpenDTU läuft aber im Gegensatz zu Ahoy nur auf dem ESP32 :)
( Ich lese hier schon seit Wochen mit, habe aber erst seit einer Woche meinen HM-800 in Betrieb.
Zum Test einen 8266 mit Ahoy und einen ESP32 mit OpenDTU. Da ich mit MQTT nie so richtig glücklich werde bevorzuge ich z.Z. noch die REST API Abfrage via HTTPMOD )
Danke für den Hinweis, ändere ich mit dem nächsten update.
Bin mit MQTT in dem Fall (bzgl. Ahoy) auch (noch) nicht so richtig glücklich, aber es geht jetzt schon mal in die Richtung voran, dass updates für einen Inverter nur noch dann kommen, wenn was via nRF empfangen wurde. Das fanden dann doch auch noch andere einen berechtigten Einwand...
Wenn dann noch alle Produktionsdaten je Inverter in einem JSON kommen, liegt mir das sehr viel näher als HTTPMOD. Damit bin ich immer noch nicht warm geworden...
Ich versuche gerade eine neue 8266 AHOY DTU an mein Testsystem zu bringen. ( FHEM ist tagesaktuell, DTU 6.0 läuft)
Was ich auch versuche, Daten des HM600 kommen rein aber der Inverter wird nicht angelegt.
Bei zuweisen des Attr. Templates kommt die Frage nach der BASE_ID.. was ist damit genau gemeint?
Danke Gerd
Wie in der Frage vorne angedeutet: Das, was du als "Basispfad" auf dem ESP eingestellt hast...
Die Frage kommt übrigens, weil anscheinend der "version"-Topic nicht da ist (also nicht in der readingList steht). Eigentlich sollte der nach dem reboot des ESP irgendwann übermittelt werden und dann auch auslesbar sein.
Mangels ("raw-") list kann ich aber dazu nicht mehr sagen...
Danke für die Antwort.
Mann muss einfach nur Geduld haben un ein paar Stunden warten.
Dann funktioniert es.
Zitat von: Beta-User am 31 März 2023, 11:09:34Falls jemand Zeit und Lust hat, devStateIcon-Code (für die DTU und/oder die Inverter) beizusteuern: feel free!
Was die Inverter angeht: Mir würde vorschweben, "pah-color" zu nutzen, um die einzelnen Panels anzuzeigen und auf Basis der Irridation zu färben, dazu die aktuelle Gesamtleistung, den heutigen Ertrag und den "allgemeinen Status", also offline, erreichbar oder in Produktion (rot/orange/grün).
Habe gestern was in diese Richtung eingeckeckt, falls jemand testen will...
Irgendwas stimmt da noch nicht, siehe Bilder.
Oder hab ich ein Konfig oder Verständnissproblem?
Wurde nach der Anzahl Channels gefragt? Auf die Schnelle wirkt das so, als würed das als single behandelt.
Ein (raw-) list würde evtl. mehr zeigen, falls es das nicht war....
Bingo, das war es. Nur ein Channel ausgewählt ich Depp.
Hab ich wohl falsch geklickt.
Danke
Frage,
ich denke über einen Herstellerwechsel nach. Deye zu Hoymiles. 3 gegen 3. Kann die OpenDTU mehr als einen Wechselrichter verwalten?
Gruß schwatter
Sowohl OpenDTU wie AhoyDTU können mehrere Inverter (default 10 oder so).
Meiner bisherigen Erkenntnis nach (das sind jetzt 5 Tage Erfahrung) bekommt die Ahoy-DTU (0.6.9) Probleme zu pollen umso größer das gewählte Intervall eingestellt wird.
Nehm ich 30 oder 60 Sekunden, ist die Kommunikation mit dem Inverter immer ausnahmslos OK, wähl ich 240 oder 300 Sekunden fangen die Probleme an und die Kommunikation "hängt" ab und an.
Ich frage auch deshalb da ich heute einen 100μF Kondensator eingelötet hab und sich am Verhalten nichts geändert hat (bisher war das mein Milight-Gatway und da war ein 2,4μF verbaut weil ich damals keinen 100er da hatte)
Kann diesbezüglich wer was sagen oder verlinken was ich genau zu lesen habe das ich diesbezüglich die Zusammenhänge besser verstehe ?
Glaube nicht, dass der Effekt irgendwo sauber dokumentiert ist. Meine Theorie:
Die Hoymiles-WR synchronisieren sich mit dem "Takt", den die/eine DTU vorgibt, und lauschen eben _vorwiegend_ auf dem Kanal, der sich als nächstes aus diesem Takt ergibt.
Zumindest für die "alten MI" waren das bei der originalen DTU eher Anfragen im 200ms-Sekunden-Takt, die dann eben auf die vorhandenen Inverter verteilt wurden... Zum Syncen braucht es anscheinend nicht Anfragen an einen speziellen Inverter, solange die alle vom "zentralen Anfrager" kommen (i.d.R. eben eine DTU).
Kommt "zu lange" nichts, fallen die Inverter afaik wieder in einen "chaotischen" Lauschzustand zurück, in dem sie eher schlechter hören als bei geringfügigen Abweichungen vom erwarteten Takt.
Ahoy und afaik auch OpenDTU senden zwar deutlich seltener Anfragen als eine originale DTU, aber es scheint hilfreich zu sein, wenn die nicht zu selten sind. Wer also Probleme hat, sollte ÖFTER anfragen (und eben dafür sorgen, dass ausreichend Power zum Senden da ist).
Nach meinen Erfahrungen ist 5 Sekunden ausreichend, wobei das in meinem setup (7 Inverter) trotzdem zu lange ist, bis alle Daten einmal rundrum aktualisiert werden. Daher fahre ich grade mit 2 Sekunden.
Darf man erfahren wie dein Ansatz ist diese (teilweise auch unnötigen) Massen von Events zu handeln, wenn du einen 5 Sekunden Intervall verwendest oder nutzt du kein MQTT und frägst nur die relevanten Werte regelmäßig ab ?
Ich hab seit heute Mittag das erste Mal 120 eingestellt und es kam laut Log seitdem nicht einmal ein Inverter #0: Hoymiles_600_1 (v0) is available but no data was received until nowund das mit Power Level LOW, ich hab ja aber auch nur einen Wechselrichter.
Mit 240 oder 300 kommt die Meldung regelmäßig, es wird gefühlt mit der Zeit besser aber mMn. zu oft.
Na ja, im Moment lebe ich noch mit der "Fülle" an Events, die via MQTT so kommt - geloggt wird sowieso "schon immer" eigentlich nur das, was die "zentrale Messdose" ermittelt (aktuell ein 3-phasiger ZigBee-Aktor für die Hutschiene)...
"Irgendwann mal" wollte ich mich mal dann mit der JSON-Variante beschäftigen und ggf. damit eine taugliche eocr-Variante für myUtils bauen (falls nicht jemand schneller ist...). Wird eher noch Monate dauern, bis ich dazu kommen werde (und Lust habe). Bis dahin kann ich erst mal damit leben, dass meine regelmäßigen Blicke auf das aktuelle Gesamtbild keine Probleme aufzeigen - aber dafür deutlich bestätigen, dass meine Wechselrichter-Wahl für diesen "konkreten Anwendungsfall" (unser Hausdach) genau richtig gewesen zu sein scheint 8) .
(Über den Tag weg gibt es praktisch immer (mind.) irgendein Panel, das die anderen auf dieser Seite "ausbremsen" könnte, da (teil-) beschattet. Insgesamt ist die Ausbeute aber (teils deutlich!) besser wie erhofft...).
Zitat von: Beta-User am 29 Mai 2023, 17:34:32(aktuell ein 3-phasiger ZigBee-Aktor für die Hutschiene)...
Kurze Zwischenfrage: Welcher ist das?
Zitat von: masterpete23 am 31 Mai 2023, 10:12:22Zitat von: Beta-User am 29 Mai 2023, 17:34:32(aktuell ein 3-phasiger ZigBee-Aktor für die Hutschiene)...
Kurze Zwischenfrage: Welcher ist das?
Gibt wohl bei Ali unterschiedlich gelabelte Varianten. deconz wirft "_TZE200_hkdl5fmv" als Bezeichnung aus.
Meiner hat noch den Schutzschalter integriert, und bisher klappt das noch nicht mit dem auslesen des/der power-Werte. Für die kumulierte Wh-Ausgabe muss man eine ddf bereitstellen.
Wenn' s mal fertig ist, schreibe ich dann mal mehr dazu...
Hallo, Freunde der Sonne,
habt Ihr hier im Thread vielleicht eine Idee, wie man dem HM-800 per OpenDTU das Limit setzt?
Ausgelesen kriege ich alles über ein MQTT-Device mit Template hoymiles_bridge.
Es wird auch brav ein frisches MQTT-Device für den angeschlossenen Inverter angelegt.
Auf beiden kreige ich Readings im 5-Sekunden-Takt, wie es sein soll.
Aber:
1.) Was sollte das Inverter-Device dann für ein Template haben?
2.) Was muß in die SetList, damit ich da einen Wert gesetzt kriege? (Die Topics müßten diese hier sein: https://github.com/tbnobody/OpenDTU/blob/master/docs/MQTT_Topics.md).
Ideen?
EDIT: Zwischenzeitlich hab' ich's raus, schreib' aber für die Nachwelt kurz hier auf, wie das mit OpenDTU geht:
1.) fhem muss mqtt sprechen. Das muss man einrichten.
2.) OpenDTU muss mqtt sprechen. Das muss man dort einrichten, ist aber über das WebGUI dort ein Quickie.
3.) fhem empfängt dann den mqtt-Stream und legt per autocreate ein Device an.
4.) Diesem Device muss man - ggf. nach Update und Neustert fhem - das Template "hoymiles_opendtu_hub_bridge" zuweisen und ein wenig warten.
5.) fhem kanalisiert dann den mqtt-Stream und legt per autocreate ein weiteres Device an.
6.) Diesem Device muss man - geht nur, wenn 4 gemacht ist - das Template "hoymiles_opendtu_microinverter" zuweisen und wieder ein wenig warten.
Ergebnis: Der Wechselrichter sendet an das unter 6 gesehene Device und lässt sich darüber auch steuern!
fhem rockt mal wieder "out of the box". Chapeau!
Hi FSausF, Dank dir für die Zusammenfassung.
ab wann ist den das AttrTemplate "hoymiles_opendtu_microinverter" (unter 6 bei Dir angesprochen) vorhanden. Habe bei mir nachgesehen und das ist das Template noch nicht da.
Grüße aus Hessen
Der Jochen
Zitat von: Jochen_M am 11 Juni 2023, 13:30:13Hi FSausF, Dank dir für die Zusammenfassung.
ab wann ist den das AttrTemplate "hoymiles_opendtu_microinverter" (unter 6 bei Dir angesprochen) vorhanden. Habe bei mir nachgesehen und das ist das Template noch nicht da.
Grüße aus Hessen
Der Jochen
Hallo Sonnenfreund,
damit das Ganze klappt, muß man natürlich - wie immer - erst Mal fhem updaten und neu starten.
Dadurch werden die aktuellen MQTT-Templates ins System gespült.
Dann muß man dieses Bridge-Device für den Hoymiles einrichten.
Denn das ist - so steht es in dem anderen Template - Voraussetzung.
Wenn das Bridge-Device nicht da ist, wird das andere Template in der Auswahl nicht angezeigt.
Es muß auch das richtige Bridge-Device sein. Hoymiles-Bridge ist das falsche, das mit "OpenDTU" im Namen ist das richtige.
...und dann hat das bei mir funktioniert...
Hallo,
seit wenigen Tagen habe ich ein Balkonkraftwerk mit Hoymiles HM-800 und OpenDTU auf einem ESP32. FHEM läuft schon seit vielen Jahren bei mir auf einem RasPi.
Ich habe hier in den vorangegangenen Seiten (uff, 17 Seiten bei mir) gelesen, dass eine Visualisierung und Datenspeicherung via MQTT über Autocreate eingerichtet werden kann.
Eine vollständige Definition habe ich in den vielen Seiten zu vor leider nicht gesehen. Nichts desto trotz würde ich gerne bevor ich daran gehe mal eine vollständige Definition für diese oder eine ähnliche Konstellation sehen.
Im Netz gibt es auch Ansätze mit influxdb und grafana. Ich weiß noch nicht für was ich mich begeistern soll.
Ich würde mich freuen, wenn mal jemand seinen vollständigen Auszug für FHEM aus der fhem.cfg hier posten würde und auch ein Bildschirmhardcopy, wie das dann aussieht.
Vielen Dank Euch!
...aber attrTemplate sagt dir was....?
(Ist für OpenDTU wohl verbesserungsfähig, aber auch vorhanden.)
Ja, attrTemplate sagt mir was. Mit attrTemplate und über das Protokoll MQTT habe ich meine Tasmota-Sonoff und Tasmota-Shelly eingebunden.
Ich würde mich dennoch freuen, wenn jemand seinen vollständigen Definitionsauszug für die OpenDTU Einbindung in FHEM aus der fhem.cfg hier posten würde und auch ein Bildschirmhardcopy, wie das dann aussieht.
...was ich dazu bisher hier gesehen habe basiert auf den betreffenden attrTemplate zu OpenDTU (bzw. die wurden daraus entwickelt).
Also: wie findest du das, was man damit in FHEM erhält bzw. welche Hinderungsgründe sprechen dagegen, diesen Weg selbst zu testen?!?
Hallo Beta-User,
die Erklärung ist:
Zitat von: Bracew am 05 Juli 2023, 19:35:52Eine vollständige Definition habe ich in den vielen Seiten zu vor leider nicht gesehen. Nichts desto trotz würde ich gerne bevor ich daran gehe mal eine vollständige Definition für diese oder eine ähnliche Konstellation sehen.
Im Netz gibt es auch Ansätze mit influxdb und grafana. Ich weiß noch nicht für was ich mich begeistern soll.
Aber, manchmal wäre es einfacher, nicht alles hinterfragt zu bekommen und nicht alles begründen zu müssen.
Es ist einfach eine Bitte. Ich möchte niemanden zwingen und es muss niemand über meine Gründe spekulieren. Einfach so! Einfach aus lauter Freundlichkeit meiner Bitte zu entsprechen.
Dann begründe nicht, sondern TESTE.
Dann bekommst du nämlich ziemlich genau das, nach was du gefragt hattest und kannst den Screenshot selber machen, falls du ihn dann noch benötigst....
Also gut, habe ich gemacht.
Kommt aber nur folgendes bei raus:
Screenshot 2023-07-06 191349.jpg
Gibt es keine Visualisierung?
Hallo an Alle,
ich möchte nochmals nachfragen, ob nicht jemand seinen vollständigen Definitionsauszug für die OpenDTU Einbindung in FHEM aus der fhem.cfg hier posten würde oder per PN mir sendet und teilt. Auch ein Bildschirmhardcopy, wie das dann aussieht, wäre toll.
Irgendwie komme ich sonst nicht weiter.
Liebe Grüße Bracew
Zitat von: Bracew am 06 Juli 2023, 19:15:35Also gut, habe ich gemacht.
Kommt aber nur folgendes bei raus:
Screenshot 2023-07-06 191349.jpg
Gibt es keine Visualisierung?
Hallo Bracew,
Ich nutze Ahoy. Kann dir bezüglich openDTU nix zeigen.
Wir soll man die Frage nach der Visualisierung Verstehen?
Meinst du eine Grafik des Ertrages oder des MQTT-Device?
Gruß Gerd
Hallo Gerd,
Zitat von: Maista am 09 Juli 2023, 17:20:50Ich nutze Ahoy. Kann dir bezüglich openDTU nix zeigen.
Auch mit Ahoy vermute ich, wirst Du die Daten Deines Wechselrichter per MQTT empfangen und in FHEM als Grafik darstellen.
Zitat von: Maista am 09 Juli 2023, 17:20:50Wir soll man die Frage nach der Visualisierung Verstehen?
Ich würde gerne die per MQTT empfangenen Daten innerhalb FHEM so aufbereitet sehen, dass ich grafische Auswertungen, zum Beispiel der Erträge der letzten Tage (oder Stunden, oder Wochen, oder, oder, oder) sehe.
Zitat von: Maista am 09 Juli 2023, 17:20:50Meinst du eine Grafik des Ertrages oder des MQTT-Device?
Ich meine zum Beispiel den Ertrag. Was kann ich bei MQTT-Device sehen? Oder was hast Du bzw. andere bereits ansonsten visualisiert?
Deshalb meine Frage nach dem Bildschirmhardcopy, dort würde ich sehen, was mich daraus interessiert und im fhem.cfg wie ich es sinngemäß bei mir umsetzen könnte. Ich weiß halt nicht was man könnte und auch nicht wie.
Wie gesagt, OpenDTU läuft bei mir und FHEM speicht in den Logfiles die ankommenden MQTT Daten. Was davon und wie kann ich diese auswerten und grafisch darstellen?
Zitat von: Bracew am 09 Juli 2023, 20:04:38Wie gesagt, OpenDTU läuft bei mir und FHEM speicht in den Logfiles die ankommenden MQTT Daten. Was davon und wie kann ich diese auswerten und grafisch darstellen?
Das entscheidest Du selbst, wie/wo/was Du sehen möchtest. Wir sind hier bei den Grundlagen, das hat mit MQTT und openDTU nichts mehr zu tun. Wenn ich was Neues einbinde, schaue ich mir das gerne bei eigenen bereits funktionierenden Geräten oder hier im Forum ab. Dazu habe ich eine gewisse Herangehensweise entwickelt:
- welche Daten kommen überhaupt rein, was davon will ich sehen und nutzen (eventOnChangeReading, eventOnUpdateReading, diverse Filtermöglichkeiten)
- was davon möchte ich loggen, wie genau/häufig benötige ich die Daten (Logfile erstellen, userreading mit allen Daten in einer Zeile, filelog-event-min-interval setzen)
- ist das Gerät bidiektional, muss ich was schalten, steuern, regeln (setlist, webcmd, readingsProxy usw. erstellen)
- "hübsch machen", d.h. stateFormat mit den gewünschten Daten füttern und verständlich darstellen, Symbole bei Bedarf ergänzen, alias, room, group, ...
Hat man das alles gemacht, entsteht ein ansehnliches Gerät, welches das System wenig belastet, alle Nötige zeigt und so aussieht, wie ich möchte (oder besser gesagt: Wie meine nicht vorhandenen Programmierkenntnisse es zulassen :D ). Zu openDTU kam ich, da konnte man weder die Leistung steuern, noch gab es hier ein Template, zu der Zeit war ahoj instabil und nur auf dem ESP8266 verfügbar. Die Entscheidung für das modernere Design, ESP32 und die Stabilität war dann entsprechend getroffen. Mein Code wäre aufgrund der anderen Struktur hier nur bedingt anwendbar, 1:1 schon gar nicht.
Aussehen tut es aktuell so:
hm600.png
Die Steuerung erfolgt mit zwei readingsProxy, loggen tu ich vom Inverter lediglich die Leistung und den Totalverbrauch, daraus lässt sich mit
statistics alles ableiten. Das "Auto-Limit" ist inaktiv, damit hatte ich mal was getestet. Dahinter verbirgt sich direkt ein doIF, um Anzeige und Schaltelemente erweitert.
Dir jetzt einfach den Code dazu hier "abzuladen" halte ich für wenig erfolgreich, wenn meine Intention dahinter fehlt. Ich stelle es bei Gelegenheit trotzdem vor- manche Dinge sind relativ einfach, hab ich im Nachhinein bemerkt ;D
Viele Grüße,
Ricardo
Hallo Ricardo,
danke für Deine Antwort.
Zitat von: kpwg am 10 Juli 2023, 07:14:17Wir sind hier bei den Grundlagen
Falls ich mich hier am falschen Thread angehängt habe, bitte ich um einen Hinweis. Ich würde dann ggf. einen neuen eröffnen.
Zitat von: kpwg am 10 Juli 2023, 07:14:17Wenn ich was Neues einbinde, schaue ich mir das gerne bei eigenen bereits funktionierenden Geräten oder hier im Forum ab.
Ja, das ist genau das, was ich auch machen wollte! Ich suche Beispiele als Bild und Code, denen ich folgen kann und welche ich auf meine Situation anpassen kann.
Deshalb
Zitat von: Bracew am 09 Juli 2023, 20:04:38Deshalb meine Frage nach dem Bildschirmhardcopy, dort würde ich sehen, was mich daraus interessiert und im fhem.cfg wie ich es sinngemäß bei mir umsetzen könnte.
Die OpenDTU Darstellung bei mir ist ähnlich folgender:
0.jpg
In dieser sehe ich die Werte, wie Du Sie auch in Deinem Screenshot dargestellt hast.
Ich suche jetzt eine FHEM Umsetzung ähnlich folgenden im Netz gefundenen Beispielen:
1.png2.png3.png
Also, zum Beispiel einer Visualisierung der Tageserträge, da es diese in OpenDTU so nicht gibt.
Ich möchte nichts am Wechselrichter steuern oder ändern (z.B. Limit), da ich dies in OpenDTU einstellen kann, sondern in FHEM nur eine grapische Umsetzung der im Logfile gespeicherten Textdaten.
glaube du verwechselst da jetzt etwas, was du meinst ist ja mehr logging und svg plot.
hab zwar ahoy am laufen aber damit kannst du auch nichts anfangen:
defmod MQTT2_inverter_MI600 MQTT2_DEVICE inverter_MI600
attr MQTT2_inverter_MI600 event-on-change-reading .*
attr MQTT2_inverter_MI600 model hoymiles_microinverter_inverter
attr MQTT2_inverter_MI600 readingList inverter/MI600/ch1/U_DC:.* U_DC1\
inverter/MI600/ch1/I_DC:.* I_DC1\
inverter/MI600/ch1/P_DC:.* P_DC1\
inverter/MI600/ch1/YieldDay:.* YieldDay1\
inverter/MI600/ch1/YieldTotal:.* YieldTotal\
inverter/MI600/ch1/Irradiation:.* Irradiation\
inverter/MI600/ch2/U_DC:.* U_DC2\
inverter/MI600/ch2/I_DC:.* I_DC2\
inverter/MI600/ch2/P_DC:.* P_DC2\
inverter/MI600/ch2/YieldDay:.* YieldDay2\
inverter/MI600/ch2/YieldTotal:.* YieldTotal\
inverter/MI600/ch2/Irradiation:.* Irradiation\
inverter/MI600/ch0/U_AC:.* U_AC\
inverter/MI600/ch0/I_AC:.* I_AC\
inverter/MI600/ch0/P_AC:.* P_AC\
inverter/MI600/ch0/Q_AC:.* Q_AC\
inverter/MI600/ch0/F_AC:.* F_AC\
inverter/MI600/ch0/PF_AC:.* PF_AC\
inverter/MI600/ch0/P_DC:.* P_DC\
inverter/MI600/ch0/Temp:.* Temp\
inverter/MI600/ch0/ALARM_MES_ID:.* ALARM_MES_ID\
inverter/MI600/ch0/YieldDay:.* YieldDay\
inverter/MI600/ch0/YieldTotal:.* YieldTotal\
inverter/MI600/ch0/Efficiency:.* Efficiency\
inverter/MI600/ch0/active_PowerLimit:.* limit\
inverter/MI600/ch0/FWVersion:.* FWVersion\
inverter/MI600/ch0/FWBuildYear:.* FWBuildYear\
inverter/MI600/ch0/FWBuildMonthDay:.* FWBuildMonthDay\
inverter/MI600/ch0/FWBuildHourMinute:.* FWBuildHourMinute\
inverter/MI600/ch0/HWPartId:.* HWPartId\
inverter/MI600/available:.* available\
attr MQTT2_inverter_MI600 setStateList on off
attr MQTT2_inverter_MI600 stateFormat YieldDay Wh P_DC W
deine Definitionen sind anders, dein WR ist anders und deine Readings...
Was du dann ins Filelog schreibst und daraus wieder in sachen svg plots aufarbeitest das kann dir hier keiner abnehmen.
Da suche und schau dir im wiki mal beispiele über logging und svg an, gibt auch einige wiki einträge für solar und auch forecast und svg Beispiele.
Anbei zum Beitrag #251 von mir der Code. Ohne Logging ::)
Alles nix Neues, aber vielleicht kann es jemand gebrauchen oder auch optimieren.
Der HM-600. Hier habe ich nur ein wenig mit stateFormat gearbeitet sowie zum testen den Slider drin. Das Userreading macht Berechnungen im Nachgang einfacher.
define DTU2 MQTT2_DEVICE OpenDTU_8850748
attr DTU2 alias HM-600
attr DTU2 autocreate 0
attr DTU2 bridgeRegexp 1141831xxxxx/([^/]+)/ch[0-9]+/.*:.* "1141831xxxxx_$1"
attr DTU2 devStateIcon .*:.*:noFhemwebLink
attr DTU2 devStateStyle style="text-align:left;;;;font-weight:narrow;;;;"
attr DTU2 event-min-interval .*:60
attr DTU2 event-on-change-reading .*
attr DTU2 group 2_BKW
attr DTU2 readingList OpenDTU_8850748:solar/dtu/uptime:.* uptime\
OpenDTU_8850748:solar/dtu/ip:.* ip\
OpenDTU_8850748:solar/dtu/hostname:.* hostname\
OpenDTU_8850748:solar/dtu/rssi:.* rssi\
OpenDTU_8850748:solar/1141831xxxxx/name:.* solar_1141831xxxxx_name\
OpenDTU_8850748:solar/1141831xxxxx/device/bootloaderversion:.* bootloaderversion\
OpenDTU_8850748:solar/1141831xxxxx/device/fwbuildversion:.* fwbuildversion\
OpenDTU_8850748:solar/1141831xxxxx/device/fwbuilddatetime:.* fwbuilddatetime\
OpenDTU_8850748:solar/1141831xxxxx/device/hwpartnumber:.* hwpartnumber\
OpenDTU_8850748:solar/1141831xxxxx/device/hwversion:.* hwversion\
OpenDTU_8850748:solar/1141831xxxxx/status/limit_relative:.* limit_relative\
OpenDTU_8850748:solar/1141831xxxxx/status/limit_absolute:.* limit_absolute\
OpenDTU_8850748:solar/1141831xxxxx/status/reachable:.* reachable\
OpenDTU_8850748:solar/1141831xxxxx/status/producing:.* producing\
OpenDTU_8850748:solar/1141831xxxxx/status/last_update:.* last_update\
OpenDTU_8850748:solar/1141831xxxxx/0/powerdc:.* 1141831xxxxx_0_powerdc\
OpenDTU_8850748:solar/1141831xxxxx/0/yieldday:.* 1141831xxxxx_0_yieldday\
OpenDTU_8850748:solar/1141831xxxxx/0/yieldtotal:.* 1141831xxxxx_0_yieldtotal\
OpenDTU_8850748:solar/1141831xxxxx/0/voltage:.* 1141831xxxxx_0_voltage\
OpenDTU_8850748:solar/1141831xxxxx/0/current:.* 1141831xxxxx_0_current\
OpenDTU_8850748:solar/1141831xxxxx/0/power:.* 1141831xxxxx_0_power\
OpenDTU_8850748:solar/1141831xxxxx/0/frequency:.* 1141831xxxxx_0_frequency\
OpenDTU_8850748:solar/1141831xxxxx/0/temperature:.* 1141831xxxxx_0_temperature\
OpenDTU_8850748:solar/1141831xxxxx/0/powerfactor:.* 1141831xxxxx_0_powerfactor\
OpenDTU_8850748:solar/1141831xxxxx/0/efficiency:.* 1141831xxxxx_0_efficiency\
OpenDTU_8850748:solar/1141831xxxxx/0/reactivepower:.* 1141831xxxxx_0_reactivepower\
OpenDTU_8850748:solar/1141831xxxxx/1/name:.* 1141831xxxxx_1_name\
OpenDTU_8850748:solar/1141831xxxxx/1/voltage:.* 1141831xxxxx_1_voltage\
OpenDTU_8850748:solar/1141831xxxxx/1/current:.* 1141831xxxxx_1_current\
OpenDTU_8850748:solar/1141831xxxxx/1/power:.* 1141831xxxxx_1_power\
OpenDTU_8850748:solar/1141831xxxxx/1/yieldday:.* 1141831xxxxx_1_yieldday\
OpenDTU_8850748:solar/1141831xxxxx/1/yieldtotal:.* 1141831xxxxx_1_yieldtotal\
OpenDTU_8850748:solar/1141831xxxxx/1/irradiation:.* 1141831xxxxx_1_irradiation\
OpenDTU_8850748:solar/1141831xxxxx/2/name:.* 1141831xxxxx_2_name\
OpenDTU_8850748:solar/1141831xxxxx/2/voltage:.* 1141831xxxxx_2_voltage\
OpenDTU_8850748:solar/1141831xxxxx/2/current:.* 1141831xxxxx_2_current\
OpenDTU_8850748:solar/1141831xxxxx/2/power:.* 1141831xxxxx_2_power\
OpenDTU_8850748:solar/1141831xxxxx/2/yieldday:.* 1141831xxxxx_2_yieldday\
OpenDTU_8850748:solar/1141831xxxxx/2/yieldtotal:.* 1141831xxxxx_2_yieldtotal\
OpenDTU_8850748:solar/1141831xxxxx/2/irradiation:.* 1141831xxxxx_2_irradiation
attr DTU2 room Energie
attr DTU2 setExtensionsEvent 0
attr DTU2 setList limit_persistent solar/1141831xxxxx/cmd/limit_persistent_absolute $EVTPART1\
limit_nonpersistent:slider,0,20,600 solar/1141831xxxxx/cmd/limit_nonpersistent_absolute $EVTPART1\
off:noArg solar/1141831xxxxx/cmd/power 0\
on:noArg solar/1141831xxxxx/cmd/power 1\
restart:noArg solar/1141831xxxxx/cmd/restart 1
attr DTU2 sortby 03
attr DTU2 stateFormat { sprintf("%.1f W aktuell, %.0f W gesetzt<br> %.1f V / %.2f Hz / %.1f °C <br> %.3f kWh heute",\
ReadingsVal($name,"1141831xxxxx_0_power","?") ,\
ReadingsVal($name,"limit_absolute","?") ,\
ReadingsVal($name,"1141831xxxxx_0_voltage","?") ,\
ReadingsVal($name,"1141831xxxxx_0_frequency","?") ,\
ReadingsVal($name,"1141831xxxxx_0_temperature","?"),\
ReadingsVal($name,"1141831xxxxx_0_yieldday","?")/1000) }
attr DTU2 userReadings limit_calc {ReadingsVal("DTU2","producing",'') eq "1" ? ReadingsNum("DTU2","1141831xxxxx_0_power",'') : 0 }
attr DTU2 webCmd :
Dazu das on/off, welches sich mit aufgehender bzw. untergehender Sonne selbst schaltet. Man KÖNNTE aber an der Stelle eingreifen.
define rp_DTU2prod readingsProxy DTU2:producing
attr rp_DTU2prod alias BKW aktiv
attr rp_DTU2prod devStateIcon 1:on 0:off
attr rp_DTU2prod group 2_BKW
attr rp_DTU2prod room Energie
attr rp_DTU2prod setFn {($CMD eq "on")?fhem("set $DEVICE on"):fhem("set $DEVICE off");; return undef}
attr rp_DTU2prod setList on off
attr rp_DTU2prod sortby 02
Weiterhin der Slider, mit dem man regeln könnte. Besonderheit daran ist, das ich hier limit_nonpersistent mit Werten zwischen 0 und $limit beschreiben kann, wobei in diesem Beispiel $limit = 600 beträgt. Für die Anwendung einer Nulleinspeisung lässt sich somit zyklisch direkt der Wert aus dem Energiemonitor (z.B. Shelly 3EM) als einzuspeisende Leistung schreiben, nur eben eingeschränkt auf zulässige Werte.
define rp_DTU2lim readingsProxy DTU2:limit_nonpersistent
attr rp_DTU2lim alias BKW Limit
attr rp_DTU2lim group 2_BKW
attr rp_DTU2lim room Energie
attr rp_DTU2lim setFn {\
my $pow = $ARGS;;\
my $limit = ReadingsVal('rp_DTU2lim','limit','');;\
if ($pow > $limit) { $pow = $limit}\
elsif ($pow < 1) { $pow = 0}\
fhem ("set $DEVICE limit_nonpersistent $pow") }
attr rp_DTU2lim setList limit_nonpersistent:slider,0,10,600
attr rp_DTU2lim sortby 01
attr rp_DTU2lim stateFormat ;
attr rp_DTU2lim webCmd limit_nonpersistent
setreading rp_DTU2lim limit 600
Hallo,
ich habe nochmals neu angesetzt und ohne attrTemplate ist folgendes herausgekommen:
Screenshot 2023-07-13.jpg
Danke an alle helfenden Hinweisgeber.
Gruß Bracew
Vielleicht eine prinzipielle Anmerkung: Wenn man nur einen Inverter hat, erschließt es sich vielleicht nicht gleich, warum per attrTemplate mindestens zwei Geräte erstellt werden. Das hat damit zu tun, dass m.E. eben die DTU (bzw. der ESP) eine eigene logische Einheit darstellt, und jeder Inverter für sich wieder eine andere Einheit.
@kpwg
Warum verwendest du eine andere (scheinbar nicht wirksame) bridgeRegexp als das attrTemplate und dann stattdessen readingsProxy, um die aus der fehlenden Trennung enstehenden Probleme zu lösen?
@Bracew:
Wenn du die gplot-Definition und das SVG-Device (als raw-list oder "copy for forum") zeigen würdest, kann ich das ggf. leichter mit per attrTemplate verteilen.
Ansonsten könnt ihr euch auch gerne mal den devStateIcon-Code für Ahoy anschauen, das sollte sich relativ einfach an OpenDTU anpassen lassen. Kommt dann sowas raus (das erste ist ein 2-kanaliger MI, der keinen Gesamtertrag liefert, und im Momment sind die einzelnen Panels eben manges viel Sonne noch "kalt", also blau):
Zitat von: Beta-User am 15 Juli 2023, 06:45:06Warum verwendest du eine andere (scheinbar nicht wirksame) bridgeRegexp als das attrTemplate und dann stattdessen readingsProxy, um die aus der fehlenden Trennung enstehenden Probleme zu lösen?
Kurze Antwort: Weil es funktioniert.
Ausführlich: Meine Erfahrung mit Templates verschiedener Autoren ist "durchwachsen", daher bin ich mit eigenen Lösungen oft besser gefahren. Zudem gab es kein Template, als ich meinen HM-600 eingerichtet habe, eine nochmalige Anpassung an fremde Vorgaben ohne Mehrwert ist daher unnötig. Ich finde das readingsProxy eine sehr einfache/verständliche und elegante Art, einzelne Parameter vom "Grundgerät" zu entkoppeln und anzupassen. Die Idee hinter den logischen Einheiten bei Erstellung mit dem Template kann ich dennoch gut nachvollziehen; das macht auch absolut Sinn.
Moin zusammen,
nachdem es in den 0.7.xx-Versionen von AhoyDTU einige Neuerungen auf der MQTT-Seite gab, habe ich vorhin die betr. attrTemplate aktualisiert.
Feedback ist willkommen.
Zitat von: kpwg am 16 Juli 2023, 14:00:40Zitat von: Beta-User am 15 Juli 2023, 06:45:06Warum verwendest du eine andere (scheinbar nicht wirksame) bridgeRegexp als das attrTemplate und dann stattdessen readingsProxy, um die aus der fehlenden Trennung enstehenden Probleme zu lösen?
Kurze Antwort: Weil es funktioniert.
Ausführlich: Meine Erfahrung mit Templates verschiedener Autoren ist "durchwachsen", daher bin ich mit eigenen Lösungen oft besser gefahren. Zudem gab es kein Template, als ich meinen HM-600 eingerichtet habe, eine nochmalige Anpassung an fremde Vorgaben ohne Mehrwert ist daher unnötig. Ich finde das readingsProxy eine sehr einfache/verständliche und elegante Art, einzelne Parameter vom "Grundgerät" zu entkoppeln und anzupassen. Die Idee hinter den logischen Einheiten bei Erstellung mit dem Template kann ich dennoch gut nachvollziehen; das macht auch absolut Sinn.
Danke für die Rückmeldung, ist soweit nachvollziehbar.
Die attrTemplate sind "nur ein Vorschlag", und es ist und bleibt weiter Ziel, die weiterzuentwickeln. Wenn also was (immerhin!) "durchwachsen" funktioniert, ist in der Regel keiner beleidigt, wenn Verbesserungsvorschläge kommen...
Zitat von: Beta-User am 17 August 2023, 07:31:05Die attrTemplate sind "nur ein Vorschlag", und es ist und bleibt weiter Ziel, die weiterzuentwickeln. Wenn also was (immerhin!) "durchwachsen" funktioniert, ist in der Regel keiner beleidigt, wenn Verbesserungsvorschläge kommen...
Sehr gerne! Ich habe ja auch Interesse daran, die Dinge langfristig sauberer abzubilden und nicht "einfach so" zu belassen, nur weil es mit dem aktuellen Verständnis funktioniert. Ich schreibe, da ich an anderer Stelle (Einbindung Bresser 7in1-Wetterstation über ESP/MQTT) genau an diesem Punkt stehe und dieses mal mit bridgeRegexp hantiere, aber keine oder keine sinnvollen SubDevices erhalte. Dazu würde ich mich an anderer Stelle nochmal melden, denn hier ist das ot.
Hallo,
ich habe eine Frage zu den Templates für die Hoymiles Wechselrichter.
Ich habe 3 WR im Einsatz, einen neuen 1600er und zwei ältere 400er.
Die neuesten Templates nach Update habe ich angewand.
Der 1600er gibt folgendes aus:
1. 993.6 W / 598 Wh / 6.1 kWh
2. 271.2 W / 148 Wh / 1.6 kWh
3. 276.7 W / 167 Wh / 1.4 kWh
4. 234.3 W / 121 Wh / 1.4 kWh
5. 263.5 W / 162 Wh / 1.8 kWh
(1. Zeile Gesamt Gerät, 2-5. Zeile die Werte der einzelnen WR-Anschlüsse (Solarmodule)).
Die Werte sind alle plausibel.
Die beiden 400er geben folgendes aus:
1. 152.1 W / 54 Wh / 229.4 kWh
2. 0 W / 113 Wh
1. 156.7 W / 26 Wh / 238.3 kWh
2. 0 W / 102 Wh
Die Werte des Gerätes (jeweils 1. Zeile) sind plausibel, aber die Werte der zweiten Zeile (Module) sind nicht richtig.
Was mache ich falsch?
Gruß
Michael
Zitat von: Audi_Coupe_S am 21 Oktober 2023, 11:43:16Die Werte des Gerätes (jeweils 1. Zeile) sind plausibel, aber die Werte der zweiten Zeile (Module) sind nicht richtig.
Was mache ich falsch?
Vermutlich nichts; der Code ist entstanden, ohne die "Spezialitäten" der 1ch-Devices zu berücksichtigen...
Muss mal schauen, ob da was machen kann, ein (raw-) list wäre hilfreich, das wird aber etwas dauern.
Hallo,
wenn ich was beitragen kann, gerne. Dann musst du mir aber genau sagen, was ich dir liefern soll, da bin ich nicht der Profi.
Gruß
Michael
Hallo,
ich habe die attrTemplate´s ersteinmal wieder herausgenommen, da sie mir zuverlässing innerhalb von 2-3 Tagen den Speicher gefüllt haben und zu "cannot fork......." geführt haben.
Zitat von: Audi_Coupe_S am 24 Oktober 2023, 17:19:29Hallo,
ich habe die attrTemplate´s ersteinmal wieder herausgenommen, da sie mir zuverlässing innerhalb von 2-3 Tagen den Speicher gefüllt haben und zu "cannot fork......." geführt haben.
Seltsamer Effekt. Das sind zwar schon ein paar kB, aber dass das dann das Fass zum überlaufen bringt, ist afaik eher selten.
Jedenfalls habe ich mal den Versuch eingecheckt, das auch für die Einkanaligen passend zu machen, die betr. myUtils file bekommst du ggf. auch isoliert mit
{ Svn_GetFile('contrib/AttrTemplate/99_attrT_Ahoy_Utils.pm', 'FHEM/99_attrT_Ahoy_Utils.pm', sub(){ CommandReload(undef, '99_attrT_Ahoy_Utils') }) }
Hi kpwg,
Vielen Dank für den Code, aber
bei meinem openDTU tut zwar das stateFormat korrekt:
FHEM_BKW.jpg
aber es führt laufend zu folgenden Fehlern, deswegen musste ich es auskommentieren;
2024.01.30 09:07:26 1: PERL WARNING: Argument "?" isn't numeric in sprintf at (eval 41982) line 1.
2024.01.30 09:07:26 3: eval: sprintf("%.1f W aktuell, %.0f W gesetzt<br> %.1f V / %.2f Hz / %.1f °C <br> %.3f kWh heute",
ReadingsVal($name,"1164804xxxx_0_power","?") ,
ReadingsVal($name,"limit_absolute","?") ,
ReadingsVal($name,"1164804xxxx_0_voltage","?") ,
ReadingsVal($name,"1164804xxxx_0_frequency","?") ,
ReadingsVal($name,"1164804xxxx_0_temperature","?"),
ReadingsVal($name,"1164804xxxx_0_yieldday","?")/1000)
2024.01.30 09:07:26 1: PERL WARNING: Argument "?" isn't numeric in sprintf at (eval 41984) line 1.
2024.01.30 09:07:26 3: eval: sprintf("%.1f W aktuell, %.0f W gesetzt<br> %.1f V / %.2f Hz / %.1f °C <br> %.3f kWh heute",
ReadingsVal($name,"1164804xxxx_0_power","?") ,
ReadingsVal($name,"limit_absolute","?") ,
ReadingsVal($name,"1164804xxxx_0_voltage","?") ,
ReadingsVal($name,"1164804xxxx_0_frequency","?") ,
ReadingsVal($name,"1164804xxxx_0_temperature","?"),
ReadingsVal($name,"1164804xxxx_0_yieldday","?")/1000)
2024.01.30 09:07:26 1: PERL WARNING: Argument "?" isn't numeric in sprintf at (eval 41986) line 1.
2024.01.30 09:07:26 3: eval: sprintf("%.1f W aktuell, %.0f Wa gesetzt<br> %.1f V / %.2f Hz / %.1f °C <br> %.3f kWh heute",
ReadingsVal($name,"1164804xxxx_0_power","?") ,
ReadingsVal($name,"limit_absolute","?") ,
ReadingsVal($name,"1164804xxxx_0_voltage","?") ,
ReadingsVal($name,"1164804xxxx_0_frequency","?") ,
ReadingsVal($name,"1164804xxxx_0_temperature","?"),
ReadingsVal($name,"1164804xxxx_0_yieldday","?")/1000)
1164804xxxx ist natürlich die korrekte Serial des INverters
Woran kann das liegen?
Vielen Dank!
Zitat von: kpwg am 11 Juli 2023, 13:56:03Anbei zum Beitrag #251 von mir der Code. Ohne Logging ::)
Alles nix Neues, aber vielleicht kann es jemand gebrauchen oder auch optimieren.
Der HM-600. Hier habe ich nur ein wenig mit stateFormat gearbeitet sowie zum testen den Slider drin. Das Userreading macht Berechnungen im Nachgang einfacher.
...
attr DTU2 stateFormat { sprintf("%.1f W aktuell, %.0f W gesetzt<br> %.1f V / %.2f Hz / %.1f °C <br> %.3f kWh heute",\
ReadingsVal($name,"1141831xxxxx_0_power","?") ,\
ReadingsVal($name,"limit_absolute","?") ,\
ReadingsVal($name,"1141831xxxxx_0_voltage","?") ,\
ReadingsVal($name,"1141831xxxxx_0_frequency","?") ,\
ReadingsVal($name,"1141831xxxxx_0_temperature","?"),\
ReadingsVal($name,"1141831xxxxx_0_yieldday","?")/1000) }
attr DTU2 userReadings limit_calc {ReadingsVal("DTU2","producing",'') eq "1" ? ReadingsNum("DTU2","1141831xxxxx_0_power",'') : 0 }
attr DTU2 webCmd :
Zitat von: joachimS am 30 Januar 2024, 14:41:47ReadingsVal($name,"1141831xxxxx_0_power","?") ,\
Habe die Lösung gefunden:
Der ReadingsVal Parameter muss in diesem Fall numerisch sein, habe einfach "0" genommen.
Habe leider keine ReadingsVal Doku gefunden, nur Beispiele, auch mit ?.
ReadingsVal("DeviceName", "ReadingName", "Ersatzwert")
EDIT: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#ReadingsVal
Ersatzwert: wenn beim Auslesen was "schief" geht, dann wird eben der Wert zurückgegeben.
Beim Fragezeichen oder "n.a." oder anderem "Blödsinn" erkennst du halt sofort, dass das Auslesen nicht geklappt hat.
Mit deiner "0" denke ich "verschleierst" du das nur und denkst es geht...
EDIT: und wenn es numerisch sein soll/ist, dann besser ReadingsNum
Gruß, Joachim
Zitat von: MadMax-FHEM am 03 Februar 2024, 10:27:22ReadingsVal("DeviceName", "ReadingName", "Ersatzwert")
Danke für den Link, konnte ich im Wiki nicht finden.
Allerdings fehlt auch der Parametertyp, in meinem Fall wohl numerisch.
Besser verschleiern als endlose Fehler, ausserdem hatten die Readings vermutlich Werte. Wenn dann kann das nur ganz am ANfang passieren.
Zitat von: Bracew am 13 Juli 2023, 19:47:39Hallo,
ich habe nochmals neu angesetzt und ohne attrTemplate ist folgendes herausgekommen:
[url="https://forum.fhem.de/index.php?action=dlattach;attach=172276;type=preview;file"]Screenshot 2023-07-13.jpg[/url]
Danke an alle helfenden Hinweisgeber.
Gruß Bracew
Hi Bracew,
könntest du bitte deinen FileLog REGEX sharen?
Ich bekomme folgenden Fehler:
Could not optimize the regexp:
OpenDTU:.*(0_yieldday|0_power|1_power|2_power|4_power).*
How I tried (notifyRegexpCheck):
OpenDTU:.*(0_yieldday: device OpenDTU (OK)
0_power: unknown (ignored)
1_power: unknown (ignored)
2_power: unknown (ignored)
4_power).*: no match (ignored)Meine Readings:
11648041xxxx_0_power 59.3 2024-02-03 10:44:35
11648041xxxx_1_power 21.6 2024-02-03 10:44:35
11648041xxxx_2_power 18.7 2024-02-03 10:45:56
11648041xxxx_4_power 20.2 2024-02-03 10:46:31Ich weiss allerdings nicht ob ich das richtige Template habe. Wie listet man das und welches brauche ich für opendtu/MQTT client?
Ich vermute das für MQTT client. Meine Readings sehen ja gut aus, also müsste es passen.
Habe auch di_counter_new am Start, das tut bis jetzt für 0_yieldtotal, morgen weiss ich mehr.
Merci und LG
Joachim
Zitat von: joachimS am 03 Februar 2024, 10:54:01könntest du bitte deinen FileLog REGEX sharen?
Würde ich Dir gerne liefern, wenn ich wüsste was Du damit meinst. Kannst Du das bitte für mich Dummy übersetzen? Oder, mir erklären, was ich tun soll?
Zitat von: joachimS am 03 Februar 2024, 10:54:01Ich weiss allerdings nicht ob ich das richtige Template habe.
Wie von mir zuvor geschrieben, habe ich das Template
nicht verwendet, sondern in der fhem.cfg den Code aus Beispielen im Internet zusammengebröselt.
Zitat von: joachimS am 03 Februar 2024, 10:54:01MQTT client
Ich nutze den FHEM eigenen MQTT2 (https://wiki.fhem.de/wiki/MQTT#MQTT2_CLIENT):
define Solar MQTT2_DEVICE OpenDTU_16xxxxxx
Danke für deine Antwort.
Tatsächlich funktioniert das Logging trotz des o.g. Fehlers. Den SVG Graph habe ich auch hinbekommen.
Ich vermute der REGEXP checker des FILELOGs ist bei meinem REGEXP überfordert.
Wäre trotzdem interessant deine FILELOG Definition zu sehen.
Der REGEXP ist der Parameter nach dem File:
define Sonne FileLog /volume2/Joachim/fhem/logs/OpenDTU-%Y.log OpenDTU:.*(0_yieldday|0_power|1_power|2_power|4_power).*
Zitat von: joachimS am 03 Februar 2024, 22:20:54Wäre trotzdem interessant deine FILELOG Definition zu sehen.
Auszug aus der fhem.cfg:
#
# Logfile fuer PV-Daten
#
define LogfileSolar FileLog ./log/Solar-%Y.log Solar
setuuid LogfileSolar 64abc-aaaa-.......
attr LogfileSolar logtype BracewPV:window,text
attr LogfileSolar room hidden
attr LogfileSolar group Balkonkraftwerk
attr LogfileSolar sortby 5
Danke,
Ich nehme an Solar ist deine opendtu.
Dann loggst du aber vermutlich alle Readings und filterst dann erst beim svg.
Dein Logfile dürfte dann ziemlich groß werden.
Ja, Solar ist meine OpenDTU via MQTT2, hatte ich im Beitrag #270 zu vor schon im Codebeispiel.
Ja, ich logge alle Readings, da ich möglicherweise vielleicht in Zukunft im Logfile mal etwas aus der Vergangenheit nachsehen wollen könnte oder in einem anderen Tool (ggf. Excel) auswerten können möchte (viel Konjunktiv!).
Ja, mein Logfile wird übers Jahr gesehen groß. Ist mir aber bisher egal. Das hat bisher keine negativen Auswirkungen.
Ich schränke die Gesprächigkeit mit
attr Solar event-on-change-reading .* etwas ein und ich könnte mit weiteren Möglichkeiten (https://forum.fhem.de/index.php) weiter reduzieren.
Weitere Möglichkeit wäre beim Log von Jahren auf Monate überzugehen und alte Monate zu löschen.
Das mit dem NOTIFYDEF-kompatiblen Aufschrieben der passenden trigger-regexp klappt selten, wenn man runde Klammern und "regex-or" zusammen verwendet...
Ungetestet könnte es so klappen, wobei vermutlich zwei Punkte zwischen Device und "Restreading-Namen" ausreichend sein könnten.
define Sonne FileLog /volume2/Joachim/fhem/logs/OpenDTU-%Y.log OpenDTU:.*0_yieldday|OpenDTU:.*_power.*
Zitat von: Bracew am 04 Februar 2024, 15:10:53Ich schränke die Gesprächigkeit mit
attr Solar event-on-change-reading .*
etwas ein und ich könnte mit weiteren Möglichkeiten (https://forum.fhem.de/index.php) weiter reduzieren.
Weitere Möglichkeit wäre beim Log von Jahren auf Monate überzugehen und alte Monate zu löschen.
Bei mir bringt event-on-change-reading wohl nichts, habe den Eindruck, dass meistens nur Änderungen zu Events führen.
Pro Panel gibt es 7 Readings:
name:.*
voltage:.*
current:.*
power:.*
yieldday:.*
yieldtotal:.
irradiation:
Selbst mit event-on-change-reading wird ein nicht angeschlossener MPPT immer wieder mal gesendet.
Habe in OpenDTU das Veröffentlichungsintervall auf 30 Sekunden erhöht da es 5 Sekunden war
Zitat von: joachimS am 04 Februar 2024, 20:27:24Habe in OpenDTU das Veröffentlichungsintervall auf 30 Sekunden erhöht da es 5 Sekunden war
Ich brauche nicht alle paar Sekunden neue Log Einträge und habe deshalb 305 Sekunden für MQTT Übertragung gewählt.