UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[axel]

@glasfaser Das war ja ganz einfach Drüberbügeln, Einstellungen machen (Anleitung aud Github) und tut. Auch leich werdne die Daten in ioBroker übernommen.

Danke an die große Hilfe !

[chris299]

@IdleBit
ich sehe im Log eine Warn-meldung, die vermutlich fehlerhaft ist:

State value to set for "opendtu.0.112483748174.power_control.current_limit_absolute" has value "-1" less than min "0"

Mein Inverter steht auf "100%", insofern ist da -1 vermutlich richtig. (das ist auch noch der default)

update: nach firmware update auf 23.7.22 kommen da richtige Werte.... lag wohl an meinem Modell das erst jetzt unterstützt wird (HMS-400)

[IdleBit]

Hi @chris299,
es scheint so das über die API versucht wird opendtu.0.xxxxxxxxx.power_control.current_limit_absolute auf den Wert -1 zu setzten das wird aber Durch ioBroker angemeckert da dieser Datenpunkt als min den Wert 0 definiert hat.

Warum da "falsche" Daten vom DTU kommen kann ich dir so erstmal nicht sagen.

[Friedhofsblond]

@idlebit
Moin,
wo wir schon mal beim Thema sind.
Ich bräuchte mal bitte ein paar Denkanstösse, damit ich weiß wo ich suchen muß.
(der OpenDTU-Adapter läuft stabil)
Also ich habe zwei WR einer für Ost (350W) und einer für Süd-West (600w).
Da kommt es in der Spitze schon mal auf 950W.
Grundlast ist bei mir meist ca. 150W, trotzdem kommt es manchmal vor, daß ich kurz über mal 850W einspeise. (z.B. am 28.5.) Das will ich verhindern. (wenn ich erst einen neuen Zähler habe, wird das sicher irgendwo gespeichert)
Ohne große "0"-Einspeisungberechnung usw. einfach nur nach Zeit.
Also ab 11:00 Ost auf 250W und 16:00 wieder 350W oder 100% - so ungefähr.
Da brauche ich den Mqtt Adapter - ja? - Was noch ?
Sorry, habe keinen Schimmer, schubst mich mal an.
Danke

[Laser]

Habe wieder mal eine Frage, die ich ähnlich schon gestellt habe. Evtl. gibt es ja neue Erkenntnisse. Wenn ich die virtuelle Debug-Konsole der opendtu geöffnet habe, scrollen Meldungen durch. Muß ein angesetzer Befehl (z.B. in den Objekten ausgelöst) in dieser Konsole erscheinen?

[IdleBit]

@friedhofsblond ich würde an deiner Stelle für das Vorhaben einfach ein Script schreiben.
Ich wüsste jetzt nicht wo für Du da jetzt mqtt brauchst.

[xbow42]

Danke für den Adapter!
Ich hätte gerne noch die peak-Werte vom Adapter bereitgestellt, um Rückschlüsse auf Alterung der Module, Auslastung und für die Leistungsregulierung zu nutzen.

opendtu.0.1xxxxxxxxxxx.ac.phase_x.power_peak
opendtu.0.1xxxxxxxxxxx.dc.input_x.power_peak
opendtu.0.total.power_peak

Fände ich praktischer als alles selbst in die Datenbank wegzuschreiben und dann wieder auszulesen, bzw per Script abzufragen.
Wie seht ihr das, @IdleBit kommt das noch?

Edit: ggf auch writable, damit man die z.B. zum 1.1.2xxx auf 0 Watt zurücksetzen kann.

[IdleBit]

@xbow42 sagte in Test Adapter OpenDTU:

Wie seht ihr das, @IdleBit kommt das noch?

Nein, der Adapter gibt nur die Datenpunkte wieder die von OpenDTU über die Websocket API bereitgestellt werden.

[xbow42]

@idlebit danke für die schnelle Antwort. Schade, dann muss ich doch ein Script dafür laufen lassen.

[axel]

Hallo, seit ein paar Tagen läut meine DTU auch sehr stabil. Da ich mich auf den Adapter verlasse, habe ich Deine Beiträge interessiert verfolgt. Ich habe einen TSun WR mit 4 Kanälen und an jedem Kanal ein Modul, Risen 405 Watt. Welche Daten kann ich denn über den Adapter hinaus abgreifen und wie mache ich das? Bin kein richtiger Programmierprofi.

[IdleBit]

@axel Ich verstehe deine Frage nicht.
Alle Daten die in der OpenDTU sind eigentlich auch im Adapter

[axel]

@idlebit wahrscheinlich kann der WR mehr Daten lierfern…

[IdleBit]

@axel Wenn die Date nicht in der OpenDTU verarbeitet werden kannst Du diese auch nicht abrufen.

[Friedhofsblond]

@idlebit
Muß mal schauen - das war nur gefährliches Halbwissen

[Friedhofsblond]

@xbow42
Moin,
ich denke die OpenDTU liest schon alles aus was der Normalouser sehen darf.
Ich sehe das in der Grafik:

[schoeppi_1]

hallo zusammen,
ich bin relativ neu hier unterwegs und habe eine Frage....
Seit ca. 3 Monaten habe ich eine Nachteinspeisung laufen.
Batterie -> HM-300 -> WLAN Steckdose. Die Leistung gebe ich konstant über OpenDTU vor. Die Steckdose schaltet den WR zu und ab. Der WR ist also immer unter Spannung.
Vor ca. einer Woche bin ich auf den OpenDTU Adapter aufmerksam geworden (DANKE dafür ), da ich eine Lösung für eine Nacht-Nulleinspeisung gesucht habe, um die Energie aus der Batterie möglichst effizient zu nutzen. Daher habe ich MQTT deaktiviert (Datenpunkte sind noch nicht gelöscht) und den OpenDTU Adapter V0.1.7 installiert, um mittels Blockly eine Regelung zu realisieren. Das hat auch alles soweit funktioniert.
Nur.... Wenn ich das Blockly aktiviere, werden für einige Minuten die errechneten Sollwerte an die OpenDTU übertragen und plötzlich hängt sie sich auf. Zum Laufen bekomme ich sie nur wieder, wenn ich den Netzstecker ziehe. Ich habe versucht im Blockly alles abzufangen, damit keine inkorrekten Sollwerte geschrieben werden. Was ich beobachten konnte, im Debugfenster unter dem Blocklyfenster werden die Meldungen bei jedem Intervall (15sec) einige Male einfach geschrieben und plötzlich bei jedem Durchlauf um + eins erhöht.
Hat jemand eine Idee wo der Fehler liegen könnte? Eventuell frage bzw. beschreibe ich falsche Datenpunkte?
Anbei das Blockly:

Vielen Dank schon mal für hilfreichen Input. Stephan

[Codierknecht]

@schoeppi_1
Welchen Wert setzt Du? "persistent" oder "non-persistent"?

[schoeppi_1]

@codierknecht
das geht schnell ... Danke:-) nonpersistant-> dieser Datenpunkt

[Codierknecht]

@schoeppi_1
Das ist so richtig.

Du hast im Blockly aber Trigger in Trigger. Das funzt nicht.

[schoeppi_1]

@codierknecht said in Test Adapter OpenDTU:

@schoeppi_1
Das ist so richtig.

Du hast im Blockly aber Trigger in Trigger. Das funzt nicht.

O.K. Das ändere ich ab. DANKE. Neuling Fehler.. die geschachtelte Triggerabfrage hat trotz allem funktioniert. Ich glaube nicht, dass das die Ursache des Problems ist. Aber Versuch macht Klug