openhabforum.de

Nach etlichen Versuchen und viel Verzweiflung, komme ich nun nicht mehr weiter.

Bestand:
-DSM mit OH3.4.0 als Docker
-Mosquitto als Broker
-Mitsubishi Heavy SRK25 ZS-W
-MHI2MQTT von Github ( https://github.com/rjdekker/MHI2MQTT )

Es laufen bereits mehrere Komponenten wie z.b. Zigbee2MQTT oder Shelly`S über Mosquitto. Broker -> i.O..
ESP-01 und Arduino Pro wie im Githubprojekt beschrieben geflasht. Daten vom ESP-01 kann ich in OH einlesen (z.b. beim starten "debug"). Jedoch kann ich den ESP nicht über OH3 ansprechen. Ich habe erstmal versucht mit einer Rule den OperationMode mit "State" zu setzten, jedoch erfolglos. Über den MQTT Explorer habe ich händisch einen Publish befehl ausgeführt. Dies konnte ich dann auch in MQTT.fx sehen. Auch in OH3 kann ich den "State" auslesen, wenn ich ihn händisch setzte über MQTT Explorer. Deklariert ist Thing, sowie Item als Number. Nun stellt sich die Frage, wie ich den State aus OH setzten kann.

Roomname wurde nicht verändert. Aus Aircon wurde Wohnzimmer. Somit sollte sich als MQTT Name ergeben: Roomname/Wohnzimmer/State.

Zeig doch mal bitte die konkreten Topics in MQTT.fx, die jeweilige funktionierende Payload sowie Deine Thing Definition (Code Ansicht aus der UI).

Habe drei Bilder in den Anhang. Hoffe das ist so wie du es gemeint hast. Die Rule selbst hat aktuell keinen Trigger. Zum Testen drücke ich immer oben rechts auf das Play-Symbol.

Mehh, ich hätte es gerne als Text gehabt... Wann immer möglich, sollte Text als Text gepostete werden (als Code markiert, damit die Forensoftware keinerlei Änderungen am Text vornimmt). Aber sei's drum...

Ich gehe mal davon aus, dass das Item Klima_Wohnzimmer_State vom Typ Number und mit dem Channel verlinkt ist, und dass die 4 durchaus im Item ankommt?
Das stateTopic ist rein ankommend, wenn Du so willst, readonly. Wenn Du einen Befehl schicken willst, braucht es dazu noch ein commandTopic.

ACHTUNG! Das commandTopic ist keinesfalls identisch mit dem stateTopic. Kommunikation in MQTT ist gewöhnlich immer unidirektional, ein Client sendet auf einem Topic und empfängt auf einem anderen Topic, beides gleichzeitig passiert eigentlich nie. Also, NIE.

Aber für den Hinterkopf: selbstverständlich kannst Du auf einem Topic senden und empfangen (weshalb das readonly oben halt nur ein quasi readonly ist).

Ach so... Das commandTopic wirst Du am ehesten aus den Unterlagen der beteiligten Gerät finden, denn das Gerät selbst wird ja niemals auf dem Topic etwas senden.

Oh sorry, war mein erstes mal hier im Forum, aber macht natürlich sinn, was du sagst.

Ich gehe mal davon aus, dass das Item Klima_Wohnzimmer_State vom Typ Number und mit dem Channel verlinkt ist, und dass die 4 durchaus im Item ankommt?

Genau.

ACHTUNG! Das commandTopic ist keinesfalls identisch mit dem stateTopic. Kommunikation in MQTT ist gewöhnlich immer unidirektional, ein Client sendet auf einem Topic und empfängt auf einem anderen Topic, beides gleichzeitig passiert eigentlich nie. Also, NIE.

D.h. Wenn ich den Channel anlege, muss ich anstelle MQTT State Topic, als MQTT Command Topic anlegen? Das werde ich gleich mal testen.

Während dem Schreiben habe ich es jetzt doch gleich getestet. Nun bekomme ich den Wert auch im MQTT Explorer.

Vielen dank für deine schnelle Hilfe. Jetzt kann ich mich weiter durchschlagen auf der MQTT Seite.

caycay hat geschrieben: ↑13. Apr 2023 21:10 D.h. Wenn ich den Channel anlege, muss ich anstelle MQTT State Topic, als MQTT Command Topic anlegen? Das werde ich gleich mal testen.

Ja, aber nein.
Das Ding ist ja: Das Gerät muss das Topic ja auch lesen, was bei dem Topic Roomname/Wohnzimmer/State keinesfalls sein kann (wir erinnern uns... unidirektional)

Ich hatte das oben gerade eben ergänzt...

Das commandTopic wirst Du am ehesten aus den Unterlagen der beteiligten Gerät finden, denn das Gerät selbst wird ja niemals auf dem Topic etwas senden.

Hier ein Auszug aus der Arduino IDE:

Code: Alles auswählen

//Access point that WiFiManager starts for configuration. Name and password should be set below before flashing. This is hardcoded and cannot be changed later.
#define configSSID  "MHI Wohnzimmer"                                                                                 //AP name (give every unit a unique name before flashing)
#define configPW    "mitsubishi"                                                                                   //Password to connect to the AP

//Variables below are initial values that can be changed at any time from the WiFiManager configuration portal and will be stored in flash memory. If there are different values in config.json, they are overwritten.
char mqtt_server[16]     = "0.0.0.0";
char mqtt_port[9]        = "1883";
char mqtt_user[20]       = "";
char mqtt_pass[20]       = "";
char wifiTimeout[3]      = "5";                                                                                    //Timeout in minutes (max. 99) before WiFi configuration portal is turned off and the ESP tries to connect again to the previously configured AP (if any)
char Room[20]            = "Roomname";
char Thing[20]           = "Wohnzimmer";
char Setpoint[60]        = "Setpoint";
char statusSetpoint[60]  = "statusSetpoint";
char State[60]           = "State";
char statusState[60]     = "statusState";
char statusRoomtemp[60]  = "statusRoomtemp";
char Vanes[60]           = "Vanes";
char statusVanes[60]     = "statusVanes";
char Fanspeed[60]        = "Fanspeed";
char statusFanspeed[60]  = "statusFanspeed";
char debug[60]           = "debug";                                                                                //Send only
char service[60]         = "service";                                                                              //Receive only

//Variables below hold the current values of bit fields 4-7 and all adjustable settings to check if anything changed after receiving an update from the MHI/Arduino
//Bit field variables are initialized with 255 to force an MQTT update with the most recent MHI settings directly after booting
//The minimal set of bit fields needed to communicate power, mode, setpoint, roomtemp, vanes and fans speed is bit fields 4-7 and 10
byte current_Bitfield4   = 255;                                                                                    //Power, mode and vane swing settings
int  current_Bitfield5   = 255;                                                                                    //Vanes setting 1-4 and fan speed 1-3 (4 is in bit field 10)
byte current_Bitfield6   = 255;                                                                                    //Temperature setpoint
byte current_Bitfield7   = 255;                                                                                    //Room temperature
byte current_Mode        = 255;
byte current_Vanes       = 255;
bool current_Swing       = false;
byte current_Fanspeed    = 255;
bool current_Fanspeed4   = false;

So wie ich das verstehe, wird über State gesetzt und über statusState müsste ich es auslesen können. Es ist jedoch so wie du sagst. Wenn ich nun folgende Rule auslöse, sehe ich das zwar im MQTT Explorer, jedoch wird die angeschlossene Klima nicht gestartet.

Rule aus OH:

Code: Alles auswählen

configuration: {}
triggers: []
conditions: []
actions:
  - inputs: {}
    id: "1"
    configuration:
      itemName: Klima_Wohnzimmer_State_Send
      command: "2"
    type: core.ItemCommandAction
  - inputs: {}
    id: "2"
    configuration:
      itemName: Klima_Wohnzimmer_Fanspeed_Send
      command: "2"
    type: core.ItemCommandAction
  - inputs: {}
    id: "3"
    configuration:
      itemName: Klima_Wohnzimmer_Vanes_Send
      command: "1"
    type: core.ItemCommandAction
  - inputs: {}
    id: "4"
    configuration:
      itemName: Klima_Wohnzimmer_Setpoint_Send
      command: "24"
    type: core.ItemCommandAction

The table below shows the topics and respective value range that can be used to operate the aircon:

If all is well, a successful connection will be notified on the debug topic. Within ~10 seconds after connection, the aircon's current settings will be sent to the status topics. From now on, sending payloads to the topics (see table below under Wireless operation using MQTT) should cause the aircon to respond within max. 2 seconds. All successful commands will be acknowledged by the aircon on the respective status topic.

Das ist noch aus dem Github-Link aus meinem ersten Post.

Das ist die Befehlstabelle:

Also, der Verfasser mag verstanden haben, was er da geschrieben hat.

Ich nehme mal an, was er meint, ist, Du sendest auf Roomname/Aircon/Fanspeed den Wert 1,2,3 oder 4 woraufhin der Quirl auf die Stufe 1,2,3 oder 4 wechselt. Du sendest auf Roomname/Aircon/Vanes 1, 2, 3, 4 oder 5, was dann Pos1, 2, 3, 4 oder Swing entspricht
Du sendest auf Roomname/Aircon/Setpoint werte von 18 bis 30, woraufhin die Solltemperatur auf 18 bis 30 gesetzt wird.
Auf Roomname/Aircon/State sendest Du 0 bis 6, woraufhin das Gerät auf die 7 verschiedenen Modi wechselt.
Und dann sollte es noch weitere Topics geben, deren Name mit status anfängt und ansonsten dem jeweiligen Namen entspricht, und das wären dann die stateTopics.

Zur Konfiguration des Arduino behaupte ich mal, dort wo "Roomname" steht, sollte z.B. "Wohnzimmer" stehen. Dort wo jetzt "Wohnzimmer" steht, sollte der Name des Geräts stehen (Mein Tipp: Leerzeichen mit Unterstrich ersetzen, Sonderzeichen meiden hier vielleicht Heavy_2)
Setpoint scheint mir in Ordnung, "State" würde ich aber durch "Mode" ersetzen (dann gibt es keine Verwirrung wegen Status), Vanes werden wahrscheinlich irgendwelche Klappen sein, mit denen der Luftstrom gelenkt wird? Achte auf jeden Fall darauf, auch die Status Topics entsprechend zu benennen.
Das sähe dann entsprechend Deiner oben geposteten Datei so aus:

Code: Alles auswählen

//Access point that WiFiManager starts for configuration. Name and password should be set below before flashing. This is hardcoded and cannot be changed later.
#define configSSID  "MHI Wohnzimmer"                                                                                 //AP name (give every unit a unique name before flashing)
#define configPW    "mitsubishi"                                                                                   //Password to connect to the AP

//Variables below are initial values that can be changed at any time from the WiFiManager configuration portal and will be stored in flash memory. If there are different values in config.json, they are overwritten.
char mqtt_server[16]     = "0.0.0.0";
char mqtt_port[9]        = "1883";
char mqtt_user[20]       = "";
char mqtt_pass[20]       = "";
char wifiTimeout[3]      = "5";                                                                                    //Timeout in minutes (max. 99) before WiFi configuration portal is turned off and the ESP tries to connect again to the previously configured AP (if any)
char Room[20]            = "Wohnzimmer";
char Thing[20]           = "Heavy_2";
char Setpoint[60]        = "Setpoint";
char statusSetpoint[60]  = "statusSetpoint";
char State[60]           = "Mode";
char statusState[60]     = "statusMode";
char statusRoomtemp[60]  = "statusRoomtemp";
char Vanes[60]           = "Vanes";
char statusVanes[60]     = "statusVanes";
char Fanspeed[60]        = "Fanspeed";
char statusFanspeed[60]  = "statusFanspeed";
char debug[60]           = "debug";                                                                                //Send only
char service[60]         = "service";                                                                              //Receive only

//Variables below hold the current values of bit fields 4-7 and all adjustable settings to check if anything changed after receiving an update from the MHI/Arduino
//Bit field variables are initialized with 255 to force an MQTT update with the most recent MHI settings directly after booting
//The minimal set of bit fields needed to communicate power, mode, setpoint, roomtemp, vanes and fans speed is bit fields 4-7 and 10
byte current_Bitfield4   = 255;                                                                                    //Power, mode and vane swing settings
int  current_Bitfield5   = 255;                                                                                    //Vanes setting 1-4 and fan speed 1-3 (4 is in bit field 10)
byte current_Bitfield6   = 255;                                                                                    //Temperature setpoint
byte current_Bitfield7   = 255;                                                                                    //Room temperature
byte current_Mode        = 255;
byte current_Vanes       = 255;
bool current_Swing       = false;
byte current_Fanspeed    = 255;
bool current_Fanspeed4   = false;

Natürlich kannst Du die entsprechenden Parameter auch über die Webschnittstelle anpassen und speichern, so ist das ja auch beschrieben...

Dann brauchst Du noch die entsprechenden Channel, die ungefähr so aussehen werden:

Code: Alles auswählen

UID: mqtt:topic:2a8687c12e:klimawozi
label: Klima Wohnzimmer
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:2a8687c12e
channels:
  - id: setpoint
    channelTypeUID: mqtt:number
    label: Temperatur Soll
    description: ""
    configuration:
      stateTopic: Wohnzimmer/Heavy_2/statusSetpoint
      commandTopic: Wohnzimmer/Heavy_2/Setpoint
      unit: °C
  - id: mode
    channelTypeUID: mqtt:number
    label: Betriebsart
    description: ""
    configuration:
      stateTopic: Wohnzimmer/Heavy_2/statusMode
      commandTopic: Wohnzimmer/Heavy_2/Mode
  - id: vanes
    channelTypeUID: mqtt:number
    label: Klappen
    description: ""
    configuration:
      stateTopic: Wohnzimmer/Heavy_2/statusVanes
      commandTopic: Wohnzimmer/Heavy_2/Vanes
  - id: speed
    channelTypeUID: mqtt:number
    label: Ventilation
    description: ""
    configuration:
      stateTopic: Wohnzimmer/Heavy_2/statusFanspeed
      commandTopic: Wohnzimmer/Heavy_2/Fanspeed
  - id: temp
    channelTypeUID: mqtt:number
    label: Temperatur Ist
    description: ""
    configuration:
      stateTopic: Wohnzimmer/Heavy_2/statusRoomtemp
      unit: °C
  - id: debug
    channelTypeUID: mqtt:string
    label: Debug
    description: ""
    configuration:
      stateTopic: Wohnzimmer/Heavy_2/debug
  - id: service
    channelTypeUID: mqtt:string
    label: Service
    description: ""
    configuration:
      commandTopic: Wohnzimmer/Heavy_2/service

Den Text kannst Du (bis auf die erste Zeile mit der UID) einfach über ein bestehendes Thing drüber "schreiben" - In meinem Testsystem hat das jedenfalls sauber geklappt

also gehe ich davon aus, dass ich alles richtig gemacht habe...

Die sieben Channel verlinkst Du jeweils mit einem Item. Die beiden Temperaturen verlinkst Du jeweils mit einem Number:Temperature Item, die beiden String Channel verlinkst Du mit String Items, die übrigen Channel verlinkst Du mit Number Items.
In den Metadaten aller Items setzt Du außerdem Auto Update auf false.

Z.B. die folgenden Namen:
KlimaWohnzimmerSoll
KlimaWohnzimmerIst
KlimaWohnzimmerMode
KlimaWohnzimmerKlappen
KlimaWohnzimmerFan
KlimaWohnzimmerService
KlimaWohnzimmerDebug

Im Ergebnis solltest Du dann in der Lage sein, die jeweiligen Befehle zu steuern und umgekehrt auch eine Rückmeldung zu bekommen, wenn Du das Gerät lokal bedienst. Auch die Raumtemperatur sollte alle sechs Sekunden im passenden Topic ausgegeben werden.

Ob die openHAB-Seite korrekt funktioniert, kannst Du jederzeit mit MQTT.fx überprüfen, dort sollten die Topics sich passend verhalten. Wenn Du in MQTT.fx auf den ...status... Topics bzw. auf dem debug Topic etwas publizierst (debug = Text, die anderen nur Zahlen) müssen die entsprechenden ITems in openHAB die gesendeten Werte anzeigen. Wenn Du in openHAB die Items beeinflusst (z.B. über die Rules) dann müssen die anderen Topics (jeweils ohne status im Namen) diese Werte anzeigen.

Da im MQTT.fx allerdings keine Temperatur zu sehen ist (sollte alle 6 Sekunden reinkommen), gehe ich davon aus, dass bisher noch keine Kommunikation mit dem Klimagerät erfolgt.

Vielen dank für deine ausführliche Erklärung.

Bezugnehmen auf deinen letzten Satz:

Da im MQTT.fx allerdings keine Temperatur zu sehen ist (sollte alle 6 Sekunden reinkommen), gehe ich davon aus, dass bisher noch keine Kommunikation mit dem Klimagerät erfolgt.

Nun habe ich den Arduino Pro mini mit dem ESP-01 wie im Github-Link an die Klima. Natürlich kommen keine Daten alle 6 sec. rein. Rx / Tx habe ich bereits getauscht, auch keine Daten. Um ganz sicher zu gehen habe ich ein zweites Paar geflasht und an meiner anderen Inneneinheit versucht. Leider auch erfolglos.

Da ich beruflich mit Siemens S7 zu tun habe, kam mir bereits die Frage, wie man kontrollieren kann, ob eine Kommunikation zwischen Arduino und ESP-01 besteht?

Der ESP wird vermutlich korrekt arbeiten, bzw. die WiFi-Manager Library, da ich auf die Oberfläche komme.

Nach meine Verständnis müsste "EasyTransfer" für die Kommunikation zuständig sein. Ich wollte noch beide Codes für ESP und Arduino einfügen, aber da komme ich leider über das Zeichenlimit von 60.000 Zeichen.

Würde auch nichts helfen

ich hab zwar "auch schon mal" einen Arduino programmiert, aber das war nur eine kleine Spielstandsanzeige mit gerade mal zwei Bildschirmzeilen Code (also vielleicht so... keine Ahnung... 70 Zeilen?)
Und ich kenne auch das Gerät selbst nicht.

Typische Probleme dürftest Du als S7-Anwender besser kennen als ich, also Pegelprobleme, verdrehte Anschlüsse, falsche serielle Parameter usw.

Gibt es im Code Testpunkte, um sicherzustellen, dass die Kommunikation zwischen Arduino und ESP8266 Modul einwandfrei funktioniert?

Notfalls wende Dich doch mal an den Entwickler, der das Repository online gestellt hat, der hat mit Sicherheit Tipps, wie Du mögliche Fehler eingrenzen kannst.

openhabforum.de

Mitsubishi Heavy 2 MQTT in OH3

Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3

Re: Mitsubishi Heavy 2 MQTT in OH3