NEWS
Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard
-
Du hast keinen Fehler gemacht --> aber ich, weil es einfach einen Schreibfehler gab. Jetzt kommt was ...
debug 6 ist allerdings still.
erster Switch:
@hape1 Ja das ist doch richtig! - Es soll ja nur entweder oder rauskommen.
Debug 6 darf ja nur was bekommen, wenn SoC >= 99 und der Status EVCS Status 3 ist. Sonst immer debug 7
Es würde JA KEINEN SINN machen, wenn 2 Nachrichten aufeinmal kommen!! (aus jedem Ast). Erstens willst Du ja nur 1 Nachricht alle 10 s und das macht ja sonst auch keinen Sinn, das alles abzuprüfen
Wie gesagt wenn Du meinen Flow importiert hättest, dann schaut der 1. Switch so aus:
-
@hape1 Ja das ist doch richtig! - Es soll ja nur entweder oder rauskommen.
Debug 6 darf ja nur was bekommen, wenn SoC >= 99 und der Status EVCS Status 3 ist. Sonst immer debug 7
Es würde JA KEINEN SINN machen, wenn 2 Nachrichten aufeinmal kommen!! (aus jedem Ast). Erstens willst Du ja nur 1 Nachricht alle 10 s und das macht ja sonst auch keinen Sinn, das alles abzuprüfen
Wie gesagt wenn Du meinen Flow importiert hättest, dann schaut der 1. Switch so aus:
oh sorry, ich habe den gar nicht gesehen ...
Ich sehe, das das System in den mqtt-node etwas schreibt, aber eigentlich müßte er unter den bestehenden Bedingungen:
Batterie unter 99%
EVCS ungleich 31600 W in den mqtt-node schreiben ... ?
Statt dessen pendelt der Wert um die 1W
-
oh sorry, ich habe den gar nicht gesehen ...
Ich sehe, das das System in den mqtt-node etwas schreibt, aber eigentlich müßte er unter den bestehenden Bedingungen:
Batterie unter 99%
EVCS ungleich 31600 W in den mqtt-node schreiben ... ?
Statt dessen pendelt der Wert um die 1W
@hape1 Nein es wird ja der Wert geschrieben, den Du aus der Summe berechnet hast (und der aus der range Node kommt). Wenn Du hier volle 1600 haben willst - egal was du vorher berechnet hast, dann spielt die berechnete Summe ja gar keine Rolle. Dann änderst Du halt zum Schluss die payload auf 1600. Du könntest also die Berechnung der Summe auch erst auf den oberen Ast ziehen. Aber wie gesagt kannst es erst mal so lassen, das kannst Du später immer noch optimoeren.
-
@hape1 Nein es wird ja der Wert geschrieben, den Du aus der Summe berechnet hast (und der aus der range Node kommt). Wenn Du hier volle 1600 haben willst - egal was du vorher berechnet hast, dann spielt die berechnete Summe ja gar keine Rolle. Dann änderst Du halt zum Schluss die payload auf 1600. Du könntest also die Berechnung der Summe auch erst auf den oberen Ast ziehen. Aber wie gesagt kannst es erst mal so lassen, das kannst Du später immer noch optimoeren.
-
@mickym
das verstehe ich leider nicht ...Wenn das System nun um die 1W pendelt, obwohl es unter den jetzigen Bedingungen 1600 eintragen müßte, kann doch irgendwo etwas nicht stimmen, oder?
@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:
@mickym
das verstehe ich leider nicht ...Na was aus der range Node rauskommt wird doch jetzt egal welchen Ast Du nimmst unverändert in die mqtt Node geschrieben. Sprich debug 5 ist debug 7.
Wenn Du im unteren Ast immer 1600 in die mqtt node schreiben willst dann ändere die payload auf 1600 - dann wird immer 1600 geschrieben, wenn der untere Ast aktiv ist.
-
@mickym
das verstehe ich leider nicht ...Wenn das System nun um die 1W pendelt, obwohl es unter den jetzigen Bedingungen 1600 eintragen müßte, kann doch irgendwo etwas nicht stimmen, oder?
@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:
@mickym
das verstehe ich leider nicht ...Wenn das System nun um die 1W pendelt, obwohl es unter den jetzigen Bedingungen 1600 eintragen müßte, kann doch irgendwo etwas nicht stimmen, oder?
Vom Flow her schon wenn das nicht Deiner Logik entspricht, dann setze unten auf 1600. Wie gesagt Du musst wissen, was Du willst. Vom Flow her stimmt alles. ;)
-
@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:
@mickym
das verstehe ich leider nicht ...Wenn das System nun um die 1W pendelt, obwohl es unter den jetzigen Bedingungen 1600 eintragen müßte, kann doch irgendwo etwas nicht stimmen, oder?
Vom Flow her schon wenn das nicht Deiner Logik entspricht, dann setze unten auf 1600. Wie gesagt Du musst wissen, was Du willst. Vom Flow her stimmt alles. ;)
-
@hape1 Nun wenn Du willst, dass die Summe keine Rolle spielt, sondern Du immer wenn Soc < 99% und EVCS_Status ungleich 3 ist, 1600 an Deine mqtt Node senden willst füge da eine Change Node ein und setze die payload einfach auf 1600.
-
@hape1 Nun wenn Du willst, dass die Summe keine Rolle spielt, sondern Du immer wenn Soc < 99% und EVCS_Status ungleich 3 ist, 1600 an Deine mqtt Node senden willst füge da eine Change Node ein und setze die payload einfach auf 1600.
-
@hape1 genau - nun sollte immer 1600 geschickt werden, solange die Bedingungen für den unteren Ast erfüllt sind. Bei über 99% und Status 3 dann wird die berechnete Summe geschickt, die Du vorher aus deinen 3 Datenpunkten berechnet hast.
Im Prinzip kannst Du nun die Summenberechnung auch nur auf den Fall durchführen, wenn SoC >99% ist.
-
@hape1 genau - nun sollte immer 1600 geschickt werden, solange die Bedingungen für den unteren Ast erfüllt sind. Bei über 99% und Status 3 dann wird die berechnete Summe geschickt, die Du vorher aus deinen 3 Datenpunkten berechnet hast.
Im Prinzip kannst Du nun die Summenberechnung auch nur auf den Fall durchführen, wenn SoC >99% ist.
-
Jo, jetzt steht im mqtt der Wert 1600, so soll es sein.
Mache jetzt Schluss, muss morgen früh raus.
Nochmal ein ausdrückliches Danke für Deine unerschütterliche Hilfe!
VG
Hape@hape1 Dann gute Nacht. Wie gesagt Du musst eine Art Kochbiuch formulieren, wie Du es gerne hättest, ich kann das nicht beurteilen. Ich kann Dir nur helfen, das was DU WILLST versuchen umzusetzen. Du musst Dich halt mal fragen, für was die Summierung überhaupt gut ist, wenn die Batterie voll ist.
Und ich erinnere auch noch an meine Fusszeile - wenn irgendwas kaputt geht, weil das vielleicht überlädt - Du bist dafür verantwortlich - ich kann Dir inhaltlich nicht helfen. Wenn das so OK ist - dann kappe lieber mal den oberen Ast, wenn dadurch die Gefahr einer Überladung erfolgt.
Gerade am Anfang macht es vielleicht Sinn erst mal zu schauen, was in den Debug Nodes rauskommt, bevor man diese Werte dann an irgendwelche Geräte schickt.
-
@hape1 Dann gute Nacht. Wie gesagt Du musst eine Art Kochbiuch formulieren, wie Du es gerne hättest, ich kann das nicht beurteilen. Ich kann Dir nur helfen, das was DU WILLST versuchen umzusetzen. Du musst Dich halt mal fragen, für was die Summierung überhaupt gut ist, wenn die Batterie voll ist.
Und ich erinnere auch noch an meine Fusszeile - wenn irgendwas kaputt geht, weil das vielleicht überlädt - Du bist dafür verantwortlich - ich kann Dir inhaltlich nicht helfen. Wenn das so OK ist - dann kappe lieber mal den oberen Ast, wenn dadurch die Gefahr einer Überladung erfolgt.
Gerade am Anfang macht es vielleicht Sinn erst mal zu schauen, was in den Debug Nodes rauskommt, bevor man diese Werte dann an irgendwelche Geräte schickt.
@mickym Hi, melde mich zurück:
Bin heute mal in Kombination mit dem Energie produzierenden Microwechselrichter und dem super Wetter dazu gekommen, den Flow in Live testen zu können.
Leider funtktioniert das setzen des reduzierten Wertes nicht, bzw. der letzte Payload im flow setzt zwar den Wert, aber der Wert wird nicht in den mqtt-Datenpunkt des Wechselrichters/opendtu übernommen.
Ich mache mal ein paar Screeshots, damit man hoffentlich besser versteht, was ich ich meine:
Hier sieht man im Datenpunkt "limit_nonpersistent_relativ" 100%, aber im "korrospondierenden" Datenpunkt "current_limit_relativ" stehen 10%.
Schreibe ich aber direkt im Datenpunkt "limit_nonpersistent_relativ" den Wert 10%, dann wird dieser auch im"current_limit_relativ" übernommen.
Ich verstehe nicht, wo der Fehler liegt.
Bzw. mir ist jetzt wo ich so schreibe, gar nicht klar, welchen Datenpunkt man zum Regeln der opendtu/Wechselrichter überhaupt benutzten soll?
-
@mickym Hi, melde mich zurück:
Bin heute mal in Kombination mit dem Energie produzierenden Microwechselrichter und dem super Wetter dazu gekommen, den Flow in Live testen zu können.
Leider funtktioniert das setzen des reduzierten Wertes nicht, bzw. der letzte Payload im flow setzt zwar den Wert, aber der Wert wird nicht in den mqtt-Datenpunkt des Wechselrichters/opendtu übernommen.
Ich mache mal ein paar Screeshots, damit man hoffentlich besser versteht, was ich ich meine:
Hier sieht man im Datenpunkt "limit_nonpersistent_relativ" 100%, aber im "korrospondierenden" Datenpunkt "current_limit_relativ" stehen 10%.
Schreibe ich aber direkt im Datenpunkt "limit_nonpersistent_relativ" den Wert 10%, dann wird dieser auch im"current_limit_relativ" übernommen.
Ich verstehe nicht, wo der Fehler liegt.
Bzw. mir ist jetzt wo ich so schreibe, gar nicht klar, welchen Datenpunkt man zum Regeln der opendtu/Wechselrichter überhaupt benutzten soll?
-
@hape1 Na das kann ich Dir auch nicht sagen welchen Punkt Du beschreiben musst. Aber Du schreibst auch keine Zahl sondern einen Text.
@mickym Habe ich auf "number" geändert und zum Test ein timestamp gesetzt
Dennoch ist es so, das der eingetragene Wert zwar übertragen und gesetzt wird (kann man im Datenpunkt sehen, aber der Wert wird nicht umgesetzt.
Gehe ich nun her und schreibe den Wert direkt im mqtt-Datenpunkt
dann wird er auch im current_limit_absolute Datenpunkt übernommen ... .
und sind auch im Webbrowser der opendtu wiederfindbar
Hast Du hierfür eine Erklärung?
-
@mickym Habe ich auf "number" geändert und zum Test ein timestamp gesetzt
Dennoch ist es so, das der eingetragene Wert zwar übertragen und gesetzt wird (kann man im Datenpunkt sehen, aber der Wert wird nicht umgesetzt.
Gehe ich nun her und schreibe den Wert direkt im mqtt-Datenpunkt
dann wird er auch im current_limit_absolute Datenpunkt übernommen ... .
und sind auch im Webbrowser der opendtu wiederfindbar
Hast Du hierfür eine Erklärung?
@hape1 Arbeitet Dein mqtt Adapter als Server/Broker und gibr es irgendwelche Einträge im Log, dass eine Nachricht nach x Retries gelöscht wird? Ich hatte früher so was https://forum.iobroker.net/post/441763 - seitdem bin ich aber auf mosquitto umgestiegen und nutze nur noch mosquitto als Broker und den Adapter als Client.
Und ggf. schauen, dass alle Haken in der mqtt Adapterkonfig NICHT gesetzt sind.
-
@hape1 Arbeitet Dein mqtt Adapter als Server/Broker und gibr es irgendwelche Einträge im Log, dass eine Nachricht nach x Retries gelöscht wird? Ich hatte früher so was https://forum.iobroker.net/post/441763 - seitdem bin ich aber auf mosquitto umgestiegen und nutze nur noch mosquitto als Broker und den Adapter als Client.
Und ggf. schauen, dass alle Haken in der mqtt Adapterkonfig NICHT gesetzt sind.
-
@hape1 Ja wie gesagt - alle Haken rausmachen - aber ich würde auf mosquitto umsteigen und den Adapter als Client nutzen. Mich hat das damals Monate gekostet, weil ich den Fehler bei mir gesucht habe und dann habe ich gewechselt und es war kein Problem mehr.
Schau mal im Log ob Du solche Nachrichten hast, dass eine Nachricht nach xxx Retries gelöscht wurde (xxx kann für 11 oder eine beliebige Zahl stehen).
Auch sowas ist super gefährlich:
Der Adapter hat nämlich grundsätzlich ein Problem mit retained Nachrichten umzugehen - und wenn ein Client - kann auch NodeRed sein, sich ggf. neu verbindet kann es hier zu Kollisionen kommen. Also wie gesagt ich lasse den mqtt-Adapter als Client laufen und nutze mosquitto als Broker und damit waren all diese Probleme weg.
-
@hape1 Ja wie gesagt - alle Haken rausmachen - aber ich würde auf mosquitto umsteigen und den Adapter als Client nutzen. Mich hat das damals Monate gekostet, weil ich den Fehler bei mir gesucht habe und dann habe ich gewechselt und es war kein Problem mehr.
Schau mal im Log ob Du solche Nachrichten hast, dass eine Nachricht nach xxx Retries gelöscht wurde (xxx kann für 11 oder eine beliebige Zahl stehen).
Auch sowas ist super gefährlich:
Der Adapter hat nämlich grundsätzlich ein Problem mit retained Nachrichten umzugehen - und wenn ein Client - kann auch NodeRed sein, sich ggf. neu verbindet kann es hier zu Kollisionen kommen. Also wie gesagt ich lasse den mqtt-Adapter als Client laufen und nutze mosquitto als Broker und damit waren all diese Probleme weg.
@mickym Ich habe in den logs geschaut, da ist nix mit Retries gelöscht ...
Was mosquitto anbelangt, wenn ich nach dem Adapter suche, kommt kein Ergebnis?
Aber selbst wenn, dann verstehe ich nicht, wofür dann der bestehende mqtt-adapter noch gut ist?
-
@mickym Ich habe in den logs geschaut, da ist nix mit Retries gelöscht ...
Was mosquitto anbelangt, wenn ich nach dem Adapter suche, kommt kein Ergebnis?
Aber selbst wenn, dann verstehe ich nicht, wofür dann der bestehende mqtt-adapter noch gut ist?
@hape1 Mit dem bestehenden Adapter kannst Du erst mal alle States auslesen und unabhängig von mqtt diese States auslesen. Mqtt schickt nämlich nur states speichert die aber nicht bzw. nur solange bis alle clients diesen State gelesen haben. Mosquitto installierst Du ausserhalb vom iobroker. Wenn Du Dich dazu entschließt kann ich Dir schon helfen.
Alternativ als kurzfristige Lösung kannst Du natürlich auch direkt via iobroker-out Node den Datenpunkt direkt beschreiben, so wie Du es manuell auch gemacht hast. Achte nur darauf, dass Du es als command beschreibst.
Wie gesagt, wenn Du mit den mqtt-Nodes was an den Broker/Server schickst und das tut nicht liegt es mit großer Wahrscheinlichkeit eher am Adapter als an den Nodes.
Support us
807
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge