[OAM-Aircondition] - Toshiba, dich kühlen soll

[u20p17]

thewhobox: kannst du mir vll deine config von der platformio.ini schicken? vll find ich damit mein problem

[thewhobox]

u20p17 das ist die platformio.custom.ini die ich verwende.

[custom]
build_flags =
  ${KNX_IP.build_flags}
  -D KNX_ACTIVITYCALLBACK
  -D USE_KNX_DMA_UART=0 ; or 1 // uart0 oder uart1
  -D USE_KNX_DMA_IRQ=1 ; or 1 // abhängig von bereits verwendeten irqs

[custom_develop]
extends = custom
build_flags =
  ${custom.build_flags}
  -D OPENKNX_HEARTBEAT
  -D OPENKNX_DEBUG
  -D OPENKNX_LOOPTIME_WARNING=100
  
; ESP32

[env:develop_omote_rev5]
extends = ESP32_develop, ESP32_custom_develop, custom_develop, ESP32_UPLOAD_USB
build_flags =
  ${KNX_IP.build_flags}
  ${ESP32_develop.build_flags}
  ${custom_develop.build_flags}
  -D OPENKNX_LOOPTIME_WARNING=100
  -D OPENKNX_USB_EXCHANGE_IGNORE
  -D KNX_IP_WIFI
  -D SERIAL_DEBUG=Serial
  -D DEVICE_OMOTE_REV5
upload_speed = 300000
extra_scripts =
  ${env.extra_scripts}
  lib/OFM-Network/scripts/pio/minimize.py
board = esp32-s3-devkitc-1
; credits to https://github.com/handledexception/platform-espressif32/blob/esp32-s3-devkitc-1-n16r8v/boards/esp32-s3-devkitc-1-n16r8v.json
board_build.arduino.memory_type = qio_opi
board_build.prsam_type = opi
board_build.extra_flags = -DBOARD_HAS_PSRAM
board_upload.flash_size = 16MB
board_upload.maximum_size = 16777216​

[mgeramb]

Wäre für jeden Hinweis dankbar, wieso der ESP32-S3 nicht funktioniert

S3 geht, habe ich bei einem anderen Projekt schon erfolgreich getestet. Vielleicht liegt es am Device Treiber? Sonst eventuell noch die 115200 baud für den Monitor explizit festlegen, oder du könntest mal probieren, alle Module im main auszukommentieren um mögliche andere Fehler auszuschließen.

[u20p17]

habe heute einige stunden den fehler mim esp32-s3 gedebuggt und schlussendlich das Problem gefunden... es ist (leider) sehr trivial gewesen... :P
ich hatte den PROG_LED_PIN=21 als OUTPUT konfiguriert und dieser trieb den Pin wegen PROG_LED_PIN_ACTIVE_ON=1 auf HIGH, um die LED einzuschalten. Der Recovery/Boot-Code versuchte anschließend, PROG_BUTTON_PIN=21 als INPUT_PULLUP einzulesen und interpretiert gedrückt = LOW (Taster nach GND). Aber der Pin wird bereits aktiv vom LED-Treiber auf HIGH gehalten →die Firmware bleibt im Recovery-Pfad hängen.

Nachdem ich den Pin geändert hatte konnte ich auch mim ESP32-s3 OpenKNX flashen und mit dem Wifi verbinden - weitere Tests sind noch ausständig...

[u20p17]

Hallo,
kurzes Statusupdate zur Daikin Implementierung: Habe den ersten Prototypen mit der Faikin Hardware (ESP32-s3) am laufen und kann mittlerweile die Klimaanlage steuern ( EIn/Aus, Temp. ändern, FanSpeed ändern und Sensordaten auslesen) 🎉theoretisch sollten auch diesselben Klimalanlagen funktionieren, die auch mit der Faikin Firmware funktionieren, da die Protokollversion gleich ausgelesen wird und dementsprechend die Kommunikation angepasst wird... (Y)

Werde die nächsten Tage weiter daran arbeiten, aber sollte jetzt nicht mehr so viel Aufwand sein eine Beta auszurollen, die dann an verschiedenen Daikin Geräten getestet werden kann...

LG
Franz

[u20p17]

Hallo,
habe nun einen Anfängerfehler wenn ich die .knxprod erzeugen will... habe in der AirCondition-Dev.xml die ApplicationNumber von "0x35" auf "0x36" und die ApplicationVersion von "0.5" auf "0.6" erhöht. danach gespeichert und dann STRG+Shift+T gedrückt und OpenKNXProducer (DEV) aufgerufen. Dann erhalte ich folgenden Fehler:

--> You need to >>> INCREASE YOUR <<< ETS ApplicationVersion and manually synchronize op:verify of the FCB Module to ModuleVersion 0.5, see https://github.com/OpenKNX/OpenKNX/w...n-Modulen-(OFM)

was mache ich da falsch?

LG

[Ing-Dom]

habe in der AirCondition-Dev.xml die ApplicationNumber von "0x35" auf "0x36"

warum?!

--> You need to >>> INCREASE YOUR <<< ETS ApplicationVersion and manually synchronize op:verify of the FCB Module to ModuleVersion 0.5

das bedeutet dass die Modulversion von FCB, die in der xml definiert ist nicht mit der version übereinstimmt die ausgecheckt ist.

[u20p17]

mit den .xml files bin ich noch auf Kriegsfuß :P wann sollte man die ApplicationNumber erhöhen?

Problem mit der Modulversion von FCB hab ich gefixt - danke (Y)

[mumpf]

wann sollte man die ApplicationNumber erhöhen?

Bei der selben Applikation? Nie! Damit erzeugst Du eine neue Applkation, also so was wie Fahrstuhlsteuerung statt AirCondition. Das willst Du nicht für eine kleine ETS-Änderung.
ApplicationVersion solltest Du bei jeder ETS-Relevanten Änderung erhöhen.
Modulversionen dann erst, wenn es ans Release geht, wobei potentiell auch freigeben für andere Entwickler eine neue Modulversion erfordern könnte. Mit der Modulversion Deines Moduls sagst Du anderen: Hey, ich hab hier was geändert, dass ETS relevante Auswirkungen hat. Das verkraftet die ETS nicht, ohne eine neue ApplicationVersion zu bekommen. Also mach das gefälligst in Deinem OAM.
Und genau das sagt die Meldung mit >>> increase <<<.

Gruß, Waldemar

[Ing-Dom]

u20p17
hast du denn überhaupt an der xml was geändert oder wolltest du nur passend zur fw deine knxprod erzeugen?

[u20p17]

mumpf: Danke fürs erneute erklären

Ing-Dom : Ja musste das Daikin-Dropdown 'freischalten'

Habe es nun geschafft, dass alle Funktionen die meine Daikin Klima kann von OpenKNX zu steuern/lesen. Hier eine Liste mit funktionierenden Features:
image.png

Nächster Schritt wäre jetzt nen Pull-Request zu machen und dann bräuchten wir mehr Tester

Hier noch der Auszug aus der Doku zur Zusammenfassung der Implementation

Daikin (S21) – Einstellungen, Funktionen & Hinweise

Folgende Einstellungen und Funktionen stehen für Daikin Klimageräte (S21-Schnittstelle am Innengerät) zur Verfügung.

Hinweis: Das S21-Protokoll ist nicht vollständig dokumentiert und einige Funktionen sind je nach Gerätemodell / Protokoll-Version optional. Die Implementierung nutzt nur dokumentierte bzw. verifizierte Teile (Stand: Faikin Wiki Protokoll v0–v3.40). Nicht unterstützte oder unsichere Bereiche wurden bewusst weggelassen.

Telemetrie & Überwachung

• Robuste Kommunikation: Retry-Mechanismen und Timeout-Behandlung
• Innengerät-Temperatur (RH)
• Außentemperatur (Ra)
• Feuchtigkeit (Re)
• Gesamtverbrauch (FM)
• Kompressorfrequenz (Rd)
• Fan Speed (RL / RK): Drehzahl / Tap (wenn verfügbar)
• Echter Zielwert (RX): Interner Regler-Zielwert (inkl. Powerful/Intelligent Eye Einflüsse)
• Unit/System State (RzB2 / RzC3): Bitfelder für Aktiv / Defrost / Powerful etc.

Grundfunktionen

• Ein/Aus: Steuerung über D1 (Power-Bit)
• Betriebsmodi: Automatik, Kühlen, Heizen, Trocknen, Lüfter (gemäß F1-Rückmeldung)
• Solltemperatur: 18,0–30,0 °C in 0,5 °C-Schritten
• Lüftergeschwindigkeit: Automatik + 5 Stufen (Low → High). Quiet/Night intern als eigener Modus; Rückmeldung über RG korrekt, F1 zeigt Quiet wie Auto (Protokoll-Einschränkung).
• Swing: Vertikal / Horizontal / Beides über D5, sofern vom Gerät gemeldet (F2-Featurebits). Keine absolute Lamellenpositions-Steuerung.

Erweiterte / optionale Funktionen
Die Verfügbarkeit wird zur Laufzeit über F2 / FK / (bei v3+) FU00 erkannt. Nicht jedes Gerät unterstützt alle Funktionen.

• Powerful (F6 / D6): Wenn F6 unterstützt (ab vielen v2/v3-Geräten). Frühe Geräte evtl. nur Status über F3-Bitmuster.
• Econo (F7 / D7): Energiesparmodus (Bit im zweiten Byte von F7).
• Quiet (D4 proprietär in dieser Implementierung / Status in F6 Quiet-Bit). Fan Quiet wird durch RG korrekt gelesen; F1 meldet ihn als Auto (Protokoll-Eigenheit).
• Streamer: Wenn in FU00 Byte 5 vorhanden und F6 Streamer-Bit reagiert.
• LED: Steuerung (abhängig von LED-Bit in F6 Byte 3, invertierte Logik). Fehlt bei älteren Modellen.
• Kein externer Temperatursensor via S21: F6 Sensor-Bit wählt keine externe Raumtemperaturquelle; es werden keine externen Temperaturdaten übergeben.
• Demand / Leistungsvorgabe (F7): Auswertung des Rohwertes (1-stellige Lastkennzahl), Umsetzung derzeit heuristisch in Prozent (experimentell).

Hinweis: Eine eventuelle zukünftige Erweiterung würde deutlich gekennzeichnet und setzt belastbare Protokollnachweise voraus.

Protokollversionen
Dynamische Erkennung v0 / v2 / v3.x (F8 + FY00 Probe). Antwort „v2“ über F8 bei v3 ist Daikin-Rückwärtskompatibilität.

Automatische Funktionen

• Protokoll-Detection: F8 → ggf. FY00 für v3+; Feature-Bits über F2/FK/F6/FU00
• Polaritätshandling: Automatische Polarity-Versuche (Inversion RX/TX-Kombinationen)
• Fallback F6→F3: Falls F6 (Special Modes) nicht reagiert, werden ggf. F3-Bits genutzt (eingeschränkt)
• Retry / Timeout: ACK- und Grace-Window Handling (angepasst an beobachtete Zeiten)

Der Vorgabewert wird auf den nächstliegenden fest definierten Wert gerundet.

Getestete Geräte

• Daikin Stylish FTXA25AW

Rückmeldungen aus Tests willkommen – unbekannte Feature-Kombinationen werden protokolliert und können zukünftige Erweiterungen steuern.

Faikin-Bezug
Konzepte (Timing, Query-Reihenfolge, Interpretation von F*/R*/Rz*-Kommandos) orientieren sich an den im Faikin-Projekt dokumentierten Erkenntnissen. Nicht jede dort aufgeführte experimentelle Funktion ist hier aktiv umgesetzt.

[willisurf]

Habe es nun geschafft, dass alle Funktionen die meine Daikin Klima kann von OpenKNX zu steuern/lesen

Herzlichen Glückwunsch, das ist der Gedanke von Open Source und OpenKNX

Kann leider beim Testen nicht helfen, habe Toshiba (und die läuft schon mit OpenKNX)
Aber ich denke da werden sich einige Interessenten finden.

[u20p17]

Danke willisurf

Habe nun nen PullRequest erstellt: https://github.com/OpenKNX/OAM-Aircondition/pull/6 Wartet jetzt auf nen merge von mgeramb (Y)

[mgeramb]

Ich habe ein

Habe nun nen PullRequest erstellt: https://github.com/OpenKNX/OAM-Aircondition/pull/6 Wartet jetzt auf nen merge von mgeramb (Y)

Sieht schon richtig gut aus. Ich habe ein paar erste Anmerkungen hinterlassen. Aber ich denke wir brauchen da eine detaillierte Abstimmung, wie das am Ende aussehen soll. Bei ein paar Dingen bin ich mir selber nicht sicher. Die Szenen werden wohl Typspezifisch werden müssen, weil die Settings je nach Hersteller oder sogar Modell unterschiedlich sein werden.

[u20p17]

Hallo!
Habe kurz deine Kommentare überflogen und stimm dir da zu...

Bezüglich Szenen:
1.) Schalten/Betriebsmodus/Lüfter/Lamellenbewegung/Gerätemodus/Luftreinigung sind ident zwischen Daikin/Toshiba.
2.) Solltemperatur würde ich bei Daikin auf 0.5deg genau einstellbar machen (Kann Toshiba nur auf ein Grad genau? Ansonsten können wir es vll generell auf 0.5deg umbauen?)
3.) Vertikale Lamellenstellung/Leistungsbegrenzung würde ich bei Daikin ausblenden, da nicht unterstützt...
4.) Den KO für die Luftfeuchtigkeit würde ich bei Toshiba ausblenden

Bezüglich den erweiterten Funktionen: Soll ich diese auch abstract machen, dann müssten wir auch beim ToshibaDriver diese implementieren ?

Bezüglich Luftfeuchtigkeitsmode: Denke, dass wir - wie du geschrieben hast - noch eine Funktion einführen sollten, die sagt, wie viele Stufe es gibt und dann kann man diese auf Prozentwerte mappen (z.B. 0=Off, 25=Low, 50=Standard, 75=High, 100=Continuous).

LG
Franz