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

gent

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

fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

gent

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
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

gent

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
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

Sorcuring

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

kpwg

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.

Sorcuring

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

kpwg

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.

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Beta-User

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)
Server: HP-elitedesk@Debian 12, 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

TheTrumpeter

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).
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Beta-User

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?
Server: HP-elitedesk@Debian 12, 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

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Beta-User

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...
Server: HP-elitedesk@Debian 12, 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