Wechselrichter Hoymiles HM-600 mit FHEM verbinden anstelle mit WLAN Stick DTU-W1

Begonnen von josburg, 25 Mai 2021, 18:03:41

Vorheriges Thema - Nächstes Thema

masterpete23

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.

Beta-User

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...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Beta-User

Denke noch. OpenDTU spricht jedenfalls kein json, für ahoy habe ich keine aktuelle Info.
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

masterpete23

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 :)

Beta-User

Würde in der Situation Ahoy nehmen (und wenn (schon) möglich die JSON-Sendeoption aktivieren).
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

masterpete23


Beta-User

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).
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

masterpete23

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... :/

masterpete23

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..

Tobias

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:
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

masterpete23

Wow - das ist sehr schick.

Würdest du das Teilen - was meintest du mit DOIF und card? :)

kabanett

Hardware: Fhem auf Raspi3 / selbtsbau CUL 433 und 868 MHz / MAX Thermostate / IT-Dosen nur noch Weihnachten / diverse ESP Aktoren/Sensoren / X10 Fernbedienung / Shelly 1, 1L, 2, 2.5, Dimmer, RGB2 / LaCrosseGateway / Zigbee2531 / diverse Zigbee Aktoren/Sensoren

masterpete23


masterpete23

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)