Limits per MQTT setzen

[FEV1337]

Hallo zusammen,

ich habe mir nun viele Beiträge bezüglich dem setzten der Limits per MQTT angeschaut.
Diverses habe ich ebenso probiert und bekomme das Problem einfach nicht gelöst. Wahrscheinlich ist es wie so oft eine Kleinigkeit.

Um es einfach zu halten, lasse ich den ioBroker erstmal raus.
Also einfach nur mein Mosquitto 1.4.10 auf einer Debian VM, die OpenDTU und mein Client mit dem MQTT Explorer.

Das Basic-Topic der openDTU lautet "/W52/WR/"
Demnach müsste der Pfad für "limit_nonpersistent_absolute" wie folgt sein:
"/W52/WR/SERIAL/cmd/limit_nonpersistent_absolute"

Egal was ich im MQTT Explorer setze, es kommt bei der openDTU/dem WR (Hoymiles HM-1500) einfach nicht an.
Erkennt Ihr etwas, was ich grundlegend falsch mache?

Vielen Dank im Voraus für eure Rückmeldung!
Gruß Florian

[FEV1337]

[Omega13x]

Wird am Topic liegen. Zu viele " / "!

[DPO99]

Darf der Pfad mit nem "/" losgehen? Das klingt i.wie falsch....ändere das mal in "W52/WR/". Ich glaube nicht, dass es per se zu viele slash sind.

[therunner87]

Das mit den zu vielen "/" war vermutlich so gemeint, dass es möglicherweise nur einen Basic-Topic geben kann/darf.
Ob das tatsächlich so ist, weiß ich aber nicht.

Aber um die Eingangsfrage hier zu beantworten:
Nach dem ich mir heute den ganzen Tag einen Wolf gesucht habe, glaube ich die Ursache gefunden zu haben.

Und zwar scheinen die Subscriptions von OpenDTU, der in der Doku genannten cmd-Topics, alle hardcoded zu sein.
Bedeutet:

1. OpenDTU nimmt Befehle nur unter dem vordefinierten Basis-Topic "solar" entgegen.
2. Der Aufruf/Topic um der DTU z. B. ein Limit zu senden müsste dann wie folgt aussehen:
   solar/SERIAL/cmd/limit_nonpersistent_relative

Hier mal ein Auszug aus dem Log meines mosquitto Servers, wo die Subscriptions der DTU zu sehen sind, obwohl ich im Webinterface den Basis-Topic verändert habe (balkonkraftwerk):
2023-10-08T19:12:27: New connection from 192.168.178.56:51288 on port 1883.
2023-10-08T19:12:27: New client connected from 192.168.178.56:51288 as OpenDTU-SERIAL (p2, c1, k15, u'basti').
2023-10-08T19:12:27: Will message specified (7 bytes) (r1, q2).
2023-10-08T19:12:27: balkonkraftwerk/dtu/status
2023-10-08T19:12:27: Sending CONNACK to OpenDTU-SERIAL (0, 0)
2023-10-08T19:12:27: Received PUBLISH from OpenDTU-SERIAL (d0, q0, r1, m0, 'balkonkraftwerk/dtu/status', ... (6 bytes))
2023-10-08T19:12:27: Sending PUBLISH to mqtt-explorer-8896e150 (d0, q0, r0, m0, 'balkonkraftwerk/dtu/status', ... (6 bytes))
2023-10-08T19:12:27: Received SUBSCRIBE from OpenDTU-SERIAL
2023-10-08T19:12:27: solar/+/cmd/limit_persistent_relative (QoS 0)
2023-10-08T19:12:27: OpenDTU-SERIAL 0 solar/+/cmd/limit_persistent_relative
2023-10-08T19:12:27: Sending SUBACK to OpenDTU-SERIAL
2023-10-08T19:12:27: Received SUBSCRIBE from OpenDTU-SERIAL
2023-10-08T19:12:27: solar/+/cmd/limit_persistent_absolute (QoS 0)
2023-10-08T19:12:27: OpenDTU-SERIAL 0 solar/+/cmd/limit_persistent_absolute
2023-10-08T19:12:27: Sending SUBACK to OpenDTU-SERIAL
2023-10-08T19:12:27: Received SUBSCRIBE from OpenDTU-SERIAL
2023-10-08T19:12:27: solar/+/cmd/limit_nonpersistent_relative (QoS 0)
2023-10-08T19:12:27: OpenDTU-SERIAL 0 solar/+/cmd/limit_nonpersistent_relative
2023-10-08T19:12:27: Sending SUBACK to OpenDTU-SERIAL
2023-10-08T19:12:27: Received SUBSCRIBE from OpenDTU-SERIAL
2023-10-08T19:12:27: solar/+/cmd/limit_nonpersistent_absolute (QoS 0)
2023-10-08T19:12:27: OpenDTU-SERIAL 0 solar/+/cmd/limit_nonpersistent_absolute
2023-10-08T19:12:27: Sending SUBACK to OpenDTU-SERIAL
2023-10-08T19:12:27: Received SUBSCRIBE from OpenDTU-SERIAL
2023-10-08T19:12:27: solar/+/cmd/power (QoS 0)
2023-10-08T19:12:27: OpenDTU-SERIAL 0 solar/+/cmd/power
2023-10-08T19:12:27: Sending SUBACK to OpenDTU-SERIAL
2023-10-08T19:12:27: Received SUBSCRIBE from OpenDTU-SERIAL
2023-10-08T19:12:27: solar/+/cmd/restart (QoS 0)

Hinweis:
Das "+" in den Topic-Pfaden ist ein Wildcard/Platzhalter und steht dann vermutlich für die Seriennummer vom Wechselrichter.

Ob es mit dem Senden über den oben beispielhaft genannten Topic funktioniert, konnte ich leider noch nicht so richtig testen.
Zumindest wurde bei mir keine Änderung in OpenDTU angezeigt.

Ob das jetzt daran liegt, dass es dunkel ist und die Änderung vom Wechselrichter nicht umgesetzt wird, oder was evtl. noch klemmt, konnte ich noch nicht feststellen.
Werde morgen nochmal schauen.

[DPO99]

Das glaube ich nicht. Ich nutze 2 DTU. Einmal "solar/" und einmal "solar2/". Anderseits ist der Log Auszug ja Recht eindeutig....@tbnobody Idee?Bug?

Ich teste das morgen nochmal, bin mir nicht 100%ig sicher ob ich unter dem solar2/ schonmal ein Limit gesendet habe.

EDIT: Wie sieht denn das Log der DTU aus? Also wohin Published er und kommt da ggf. was an? Nicht, dass der Broker einfach über den falschen Pfad was schickt.

[DPO99]

Bei mir sieht das alles fein aus, wenn ich auf einem anderen Pfad ein Limit sende...

DTU Konsole:
Received MQTT message on topic: solar2/XXX/cmd/limit_nonpersistent_absolute
21:38:24.034 > Limit Non-Persistent: 590 W
21:38:37.263 > Received MQTT message on topic: solar2/XXX/cmd/limit_nonpersistent_absolute
21:38:37.263 > Limit Non-Persistent: 600 W

[therunner87]

Hi,

ich bin leider noch nicht wieder dazu gekommen, etwas zu testen, glaube aber langsam, dass es eher daran liegt, wie der Wert an die OpenDTU gesendet wird.

Da würde mich mal interessieren, wie (in welcher Form) du die Werte an die OpenDTU übermittelst.
Machst du das mit Home Assistant (habe da glaube ich schon einige Beiträge von dir zu gesehen?)?

Weil ich (und vermutlich auch der Diskussionseröffner) machen das nämlich nicht darüber.
Und ich will mir auch nicht extra ein Home Assisstant installieren, nur um einen einzelnen Zahlenwert irgend wo hin zu schicken.

Ich habe bisher lediglich versucht, einen einfachen Zahlewert z. B. 200W über mqtt an die OpenDTU zu übertragen.
Das ganze habe ich wie im Eingangsbeitrag auch beschrieben lediglich über NodeRed über einen Button (Inject-Node, msg.payload vom Typ "Number", wo ich den jeweiligen Wert manuell eintrage) und die mqtt-Node mit dem entsprechenden Topic gemacht.
Auch mit dem vermeitlich "richtigen" Topic wurde der Wert aber bisher nicht umgesetzt.
Ob der in der Konsole von OpenDTU auftaucht, konnte ich wie gesagt noch nicht testen.

Ich vermute aktuell, dass es eher daran liegt, dass ich den Wert in der falchen Form übermittele, also der übergebene Datentyp nicht passt (Integer, String, JSON, etc.).
Soweit ich das bisher nachvollziehen konnte scheint Home Assistant hier nämlich ganze JSON-Objekte über mqtt zu verschicken.
Wenn also OpenDTU das nur in Form von JSON-Objekten verarbeiten kann, aber nicht als einfachen Integer/Number (Zahlenwert), dann wird das eventuell das Problem sein.

Aber nur nochmal zum Verständis und damit wir vom selben reden.
Der mqtt-Broker ist der mqtt-Server, der die mqtt-Nachrichten nur verteilt, dieser bearbeitet sie aber nicht.
In meinem Fall ist das ein Mosquitto-Server der in einem Container läuft.

Der Publischer in meinem Fall, ist wie oben beschrieben NodeRed mit der Inject- und mqtt-Node.
Solange der Topic in der mqtt-Node korrekt eingetragen ist, sollte die Nachricht also auch ankommen.
Weil die Nachricht muss ja nur an den Topic gesendet (published) werden, der auch von der OpenDTU abboniert (subscribed) wurde.
Und das die Nachricht zumindest am mqtt-Broker (Mosquitto) ankommt, konnte ich im Log auf meinem Mosquitto-Server aucb bereits sehen.
Nur wurde sie anscheinen eben nicht an OpenDTU weitergeleitet, weil zumindest in meinem Fall der Publish (NodeRed) und die Subscription (OpenDTU) unterschiedlich waren/sind.

Deswegen hatte ich in meinem vorigen Beitrag auch die Vermutung geäußert, dass die unterschiedlichen publisch- und subscribe-Kanäle die Ursache sein könnten.
Open DTU ist hier nämlich sowohl Publisher, als auch Subscriber gleichzeitig.
Warum das wie im Log zu sehen auf unterschiedlich benannten Topics erfolgt konnte ich mir bisher außer, dass es hard-coded sein könnte leider nicht erklären.
Aber das war auch nur eine Vermutung, also sorry, falls ich da jemandem auf die Füße getreten bin.

[DPO99]

hmm also das sind ja viele Punkte aber mal Stück für Stück.

Ich habe als Setup den Iobroker welcher als Server/Broker und in einer anderen Instanz auch als Client/Subscriber arbeitet. Zusätzlich kann ich das ganze aber ja auch über die Software MQTT Explorer an meinen MQTT Server/Broker schicken (also nicht nur Iobroker an Iobroker, sondern auch MQTT Explorer an iobroker).

Von den Befehlen her dürfte es eigentlich kein unterschied sein. Natürlich ist es in der Praxis ein anderes Vorgehen, aber sowohl der IoBroker als auch der MQTT Explorer sendet bei mir einen Befehl über folgenden Pfad:

Hier einmal iobroker Logik:
send2Server mqtt.1.solar.xxx.cmd.limit_nonpersistent_absolute[solar/xx/cmd/limit_nonpersistent_absolute]

Das kommt dann auch in der DTU an:
21:03:03.576 > Received MQTT message on topic: solar/xx/cmd/limit_nonpersistent_absolute
21:03:03.626 > Limit Non-Persistent: 583 W

Hier einmal über den MQTT Explorer:
solar/xx/cmd/limit_nonpersistent_absolute

Das ganze kommt dann auch in der DTU an:
21:01:57.326 > Received MQTT message on topic: solar/xx/cmd/limit_nonpersistent_absolute
21:01:57.326 > Limit Non-Persistent: 790 W

Ich kann daher nur vermuten, dass irgendetwas am Mosquitto nicht passt (aber da kenne ich mich nicht aus). Versuchs doch mal über den MQTT Explorer, ggf. liegts ja auch an NodeRed.

Ich kann das ganze gerne nochmals so auch über den anderen Pfad solar2 machen aber das kommt ja auch in der DTU an (das hab ich schon (auch wenn nicht so im Detail) nachgestellt).

EDIT:
Hier mal der andere Pfad beim Connect. Sieht auch sauber aus, und die DTU published bzw. subscribed hier m.E. alles richtig:

2023-10-15 20:36:05.168 - info: mqtt.0 (959) Client [OpenDTU-xx] subscribes on "solar2/+/cmd/limit_persistent_relative" with regex /solar2.[^.].cmd.limit_persistent_relative/
2023-10-15 20:36:05.169 - info: mqtt.0 (959) Client [OpenDTU-xx] subscribes on "solar2/+/cmd/limit_persistent_relative" with regex /mqtt.0.solar2.[^.].cmd.limit_persistent_relative/
2023-10-15 20:36:05.173 - info: mqtt.0 (959) Client [OpenDTU-xx] subscribes on "solar2/+/cmd/limit_persistent_absolute" with regex /solar2.[^.].cmd.limit_persistent_absolute/
2023-10-15 20:36:05.174 - info: mqtt.0 (959) Client [OpenDTU-xx] subscribes on "solar2/+/cmd/limit_persistent_absolute" with regex /mqtt.0.solar2.[^.].cmd.limit_persistent_absolute/
2023-10-15 20:36:05.176 - info: mqtt.0 (959) Client [OpenDTU-xx] subscribes on "solar2/+/cmd/limit_nonpersistent_relative" with regex /solar2.[^.].cmd.limit_nonpersistent_relative/
2023-10-15 20:36:05.178 - info: mqtt.0 (959) Client [OpenDTU-xx] subscribes on "solar2/+/cmd/limit_nonpersistent_relative" with regex /mqtt.0.solar2.[^.].cmd.limit_nonpersistent_relative/

[therunner87]

Hey, danke für die weitere Ausführung/Beschreibung.

Der Screenshot vom MQTT-Explorer hilft mir glaube ich schonmal.

Du hast also JSON als Format ausgewählt.
Ich nehme mal an, du hast dann einfach nur den Zahlenwert in das Textfeld eingetragen, sonst nichts, also z. B. einfach nur "790"?
Weil da auf dem Screenshot nichts weiter zu sehen ist.

Das mit dem MQTT-Explorer hatte ich zwar auch schon ausprobiert, hatte da aber auch nicht funktioniert.
Der Publisch kam zwar über den MQTT-Server/Broker wieder im MQTT-Explorer an (weil der ja einfach alles subscribed), aber auf der OpenDTU ist nichts passiert.
Das war allerdings, bevor ich den Unterschied im Publish und Subscribe bei mir festgestellt hatte.
Werde ich nochmal testen.
Komme ich aber voraussichtlich erst nächstes Wochenende zu.

[DPO99]

Ja genau da steht einfach nur eine Zahl. JSON wird generell im Mqtt Adapter des iobroker verwendet. Ggf hilft dir ja die Doku auf GitHub weiter.

https://github.com/ioBroker/ioBroker.mqtt

[Jakob58]

Hallo zusammen,
ich hole diese alte Geschichte nochmal hoch, da ich das selbe Problem habe. OpenDTU, HomeAssistant, Hoymiles HM600 Wechselrichter.
Ich möchte mit einem Script in HA den Wert 'Limit non persistence absolut' verändern, aber egal wie ich den Wert verändere, der auch im Mqtt Explorer an der richtigen Stelle ankommt, es kommt keine Änderung am Wechselrichter an. Jetzt die Frage, hat sich bei Euch dahingehend irgendetwas ergeben?

[therunner87]

Hallo Jakob58,

ich hatte hier nicht mehr geschrieben, weil der Thread zwischenzeitlich geschlossen wurde, dachte ich.
Und weil ich auch lange nicht dazu gekommen bin, weiter zu suchen.

Letztendlich war bei mir aber dann doch nur der physikalische Layer das Problem.

Die Verbindung der OpenDTU und dem
Wechselrichter war also einfach zu schlecht, sodass die Befehle wohl unterwegs verloren gegangen sind oder nicht verarbeitet werden konnten.
Die OpenDTU war einfach zu weit entfernt vom Wechselrichter, zu viele (dicke) Wände dazwischen, schlechter Winkel, oder vielleicht zu viele Störquellen, vielleicht wegen dem WLAN (ist ja das gleiche Funkband/Bandbreite; 2,4GHz), such dir was aus.

Genau kann ich es nicht sagen, aber nachdem ich die OpenDTU, also den Micrcontroller auf dem OpenDTU läuft, näher an den Wechselrichter gebracht hatte, hat es bei mir dann problemlos funktioniert.

Also wenn du dir nicht sicher bist, dass das nicht das Problem ist, würde ich vielleicht da nochmal schauen.

Was HA betrifft, kann ich leider nicht weiterhelfen, weil ich kein HA habe.
Ich wollte es direkt über mqtt und NodeRed ansteuern, was wie oben beschrieben nach dem umsetzen der OpenDTU-Einheit ja auch funktioniert hat.
Für mich hat sich das mit dem regulieren der Einspeisung aber mittlerweile auch erledigt, weil durch die Änderung der Regularien ist die Einspeisung in meinem Fall irrelevant.

Viel Erfolg weiterhin.

[Jakob58]

Hallo tbnobody. vielen Dank für deine rasche Antwort, es ist kaum zu glauben aber das war die Lösung. Ich habe die openDTU näher an mein WLAN platziert und schon geht’s. Mit der Veränderung des ‚non persistent Limits‘ möchte ich in Verbindung mit einem Hichi Lesekopf mein Zendure Solarflow steuern. Vielen Dank und viele Grüße, Jakob Feldl Von: therunner87 ***@***.***> Gesendet: Mittwoch, 17. Juli 2024 12:54 An: tbnobody/OpenDTU ***@***.***> Cc: Jakob58 ***@***.***>; Comment ***@***.***> Betreff: Re: [tbnobody/OpenDTU] Limits per MQTT setzen (Discussion #1158) Hallo Jakob58, ich hatte hier nicht mehr geschrieben, weil der Thread zwischenzeitlich geschlossen wurde, dachte ich. Und weil ich auch lange nicht dazu gekommen bin, weiter zu suchen. Letztendlich war bei mir aber dann doch nur der physikalische Layer das Problem. Die Verbindung der OpenDTU und dem Wechselrichter war also einfach zu schlecht, sodass die Befehle wohl unterwegs verloren gegangen sind oder nicht verarbeitet werden konnten. Die OpenDTU war einfach zu weit entfernt vom Wechselrichter, zu viele (dicke) Wände dazwischen, schlechter Winkel, oder vielleicht zu viele Störquellen, vielleicht wegen dem WLAN (ist ja das gleiche Funkband/Bandbreite; 2,4GHz), such dir was aus. Genau kann ich es nicht sagen, aber nachdem ich die OpenDTU, also den Micrcontroller auf dem OpenDTU läuft, näher an den Wechselrichter gebracht hatte, hat es bei mir dann problemlos funktioniert. Also wenn du dir nicht sicher bist, dass das nicht das Problem ist, würde ich vielleicht da nochmal schauen. Was HA betrifft, kann ich leider nicht weiterhelfen, weil ich kein HA habe. Ich wollte es direkt über mqtt und NodeRed ansteuern, was wie oben beschrieben nach dem umsetzen der OpenDTU-Einheit ja auch funktioniert hat. Für mich hat sich das mit dem regulieren der Einspeisung aber mittlerweile auch erledigt, weil durch die Änderung der Regularien ist die Einspeisung in meinem Fall irrelevant. Viel Erfolg weiterhin. — Reply to this email directly, view it on GitHub <#1158 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEDTQ74IAJDEH2OI7JRUH3TZMZEMBAVCNFSM6AAAAABLADR5U2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBXGIZDOOI> . You are receiving this because you commented.Message ID: ***@***.***>