Guten Tag zusammen,
Kurze bzw. etwas längliche Vorgeschichte - aber vll. interessiert es doch den / die ein oder andere(n) - sonst gerne "überlesen" und zum eigentl. Problem "springen":
Ich betreibe in den Wohn & Schlafräumen neben einer Fußbodenheizung (FBH)
jeweils zusätzlich Kühldecken (KD).
- Das Heizen bzw. Kühlen übernimmt eine Luft-Wärmepumpe (WP)
- Ob geheizt oder gekühlt werden soll, muss an der WP manuell eingestellt werden (immerhin komfortabel per Web-Fernzugriff bzw. App möglich).
- Es gibt für ALLE Heiz-/Kühlkreise EINEN gemeinsamen Vor-/Rücklauf.
-> Wenn geheizt wird, liegt überall (FBH + KD) warmes Wasser an
-> Wenn gekühlt wird, liegt überall (FBD + KD) kaltes Wasser an - Die WP meldet f@h per Binäreingang, ob aktuell geheizt-/kühlt wird.
Es ist überaus wichtig (aus physikal. Gründen, Erklärung würde hier zu weit führen), dass sofort min. 1-2 Kreise "offen" sind, sobald ich die WP auf Kühlen umstelle. Sollte also am besten autom. "passieren".
-> Sonst läuft die WP binnen ca. 20min. auf Fehler und schaltet sich komplett ab. 🙁
Im f@h habe ich, neben RTR in allen Räumen, 2 REG-Heizaktoren:
- 12-fach Aktor für alle FBH-Kreise
- 6-fach Aktor für alle KD-Kreise
Durch den gemeinsamen Vorlauf (s. o., entweder warm ODER kalt) gibt es folgendes "Dilemma":
- Konfiguration der FBH-Aktorkanäle auf Heizen, KD-Kanäle auf Kühlen, RTR SOLL auf 20 Grad
-> Fällt die IST-Temperatur unter SOLL, öffnet der RTR die FBH Kreise
-> Statt, wie der RTR annimmt, dadurch zu heizen, läuft jetzt kaltes Wasser durch die FBH
-> Unangenehm - Konfiguration der FBH-Kreise auf "Autom. Heizen/Kühlen"
-> Fällt aus o. g. Grund ebenfalls weg, da der RTR sonst bei Überschreiten SOLL kaltes Wasser durch die FBH "jagt"
Bisher hatte ich deswegen 2 "Workarounds" umgesetzt - beide nicht sonderlich komfortabel:
- Konfiguration FBH-Aktorkanäle "regulär" Heizen, RTR SOLL (in den Räumen ohne KD) so niedrig (z. B. 15 Grad), dass der RTR niemals die Kreise öffnet; KD-Kanäle alle auf "Kühlen" parametriert
-> Meine bessere Hälfte stört sich daran, dass im RTR Display eine derart niedrige Temperatur angezeigt wird: "Es ist gefühlt genauso kalt..."
-> Niemals den WAF unterschätzen 😉 - RTR SOLL wieder auf 20-21 Grad, in der f@h Konfiguration die Verknüpfung(en) zwischen RTR und Heiz- bzw. Kühl-Kreisen entfernen
-> Wenn gekühlt wird, nurmehr Verknüpfung RTR zu Kühlkreis(en) belassen
-> Wenn geheizt wird, nurmehr Verknüpfung RTR zu Heizkreis(en) belassen
-> Dieses Verknüpfen / Aufheben jedes Mal bei Umschalten Heizen/Kühlen...
-> Klar, per Backup am SysAP einspielen wäre halbwegs eine Automatisierung möglich; müsste man aber immer aktuell halten, sonst gehen alle anderen Änderungen (Aktione, Szenen etc.) die man in der Zwischenzeit vorgenommen hat "verloren"
Nun wollte ich daher eine weitere Variante ausprobieren:
- FBH-Kanäle auf Heizen programmieren
-> Trade-off: RTR SOLL-Temperatur muss niedrig genug gestellt werden (vgl. oben Variante 1.)
-> Hat ggF.jemand einen Vorschlag, wie man das "eleganter" lösen kann? - KD-Kanäle auf "Autom. Heizen/Kühlen" programmieren
-> Die Decke würde in der Konfiguration "mitheizen"
-> vll. sogar von Vorteil, da SOLL-Temperatur schneller erreicht (?)
-> Hinweis:
Dazu muss der Binäreingang für den Umschalter Heizen/Kühlen zusätzlich mit dem Kühlen-Aktorkanal verknüpft werden!
Die drei vorgenannten Konfigurationsvarianten Heizen, Kühlen oder Autom. Heizen/Kühlen sind im Technisches Handbuch für Heizungsaktoren (Kapitel 4) näher beschrieben.
Finde sehr cool, dass an diesen (vermutlich aktuell noch eher seltenen) Fall gedacht wurde und f@h das grundsätzlich unterstützt.
Die Beschreibung im Systemhandbuch und tech. Handbuch finde ich allerdings etwas knapp, insb. DASS bzw. WIE man den Binäreingang mit dem Aktorkanal verknüpfen muss habe ich mehr per Zufall herausgefunden.
Problem
Als ich gestern die zuletzt beschriebene Variante programmieren wollte (bzw. damit schon so gut wie fertig war), ist plötzlich eine Fehlermeldung in der f@h Konfigurationsoberfläche erschienen (vgl.
).
- Ich habe natürlich zuerst die erste Option "Gerät neu laden" versucht, mehrfach.
-> Ohne Erfolg - Danach "Zurücksetzen" (sollte das Gerät eig. auf Werkszustand versetzen, danach müsste alles neu programmiert werden).
-> Leider ebenfalls erfolglos - "Ignorieren" klappt - natürlich funktioniert der Aktor danach nicht mehr
-> Erscheint unter "Einstellungen" -> Ignorierte Geräte
-> die Programmierung bleibt wohl vorhanden und könnte auf einen neuen, funktionierenden 6-fach Heizaktor übertragen werden - Nach Rücksprache mit dem Elektriker habe ich per Sicherung ca. 5 min die Busspannung weggenommen
-> Aktor funktioniert danach ebenfalls nicht (hatte ich nicht anders erwartet, es muss ja ein Langzeitpuffer integriert sein, damit die Programmierung bei längerem Stromausfall nicht verloren geht; Logik ist bei f@h analog KNX in den Aktoren/Sensoren direkt hinterlegt, nicht wie bei Loxone z. B. rein im SysAP)
-> Ident-LED blinkt ca. 1x/Sekunde rot (vgl.)
-> Druck (auch längerer) auf Ident-Taste ohne Erfolg - Nach mehreren Backup-Restores (habe ich natürlich ebenfalls versucht - Erfolg: Mehrere Aktionen verloren, ca. 1h Neuprogrammierungsmarathon) ist eine andere Fehlermeldung erschienen:
-> "Es wurden Geräte aus einer anderen Installation gefunden" (der defekte Aktor)
-> "Wollen sie die 104 Geräte aus der aktuellen Installation übernehmen oder das eine aus der anderen"?
-> In Dauerschleife, ich habe natürlich jedes mal die 104 gewählt
-> Irgendwann war dann wieder der "Defektes Gerät"-Fehler gekommen und ich konnte "Ignorieren" - Ich habe das "Permalog"-File aus dem SysAP (Bereich Einstellungen -> Service) heruntergeladen
-> Darin ist erkennbar, dass der Aktor während der Programmierung plötzlich mit einer offensichtlich ungültigen Adresse ABB2FFFFFFFF (statt korrekt ABB2F52D3151) antwortet:SpoilerSysAP Permalog-
Tue Aug 27 14:14:17 2019 mrha_database | -- databaseadaptor.cpp 900 setApplianceValues ABB700CE27EB accessLevel room floor displayName 0A 01 Spielzimmer Temperatur
Tue Aug 27 14:14:17 2019 mrha_database | -- databaseadaptor.cpp 900 setApplianceValues ABB700CE27EB/ch0000 accessLevel functionId selectedIcon offsetX offsetY 23 21 0.555436001637871 0.801528096234584
Tue Aug 27 14:14:17 2019 mrha_database | -- databaseadaptor.cpp 2192 newPairing ABB700CE27EB/ch0000 ABB2F52D3151/ch0001
Tue Aug 27 14:14:18 2019 mrha_database | -- database.cpp 5321 ABB700CE27EB 0x2041 0x22c starting query setDeviceConfiguration with route 0x2e5 0x25e 0x200
Tue Aug 27 14:14:18 2019 mrha_database | -- database.cpp 5323 ABB2F52D3151 0xb003 0x1d5 starting query setDeviceConfiguration
Tue Aug 27 14:14:18 2019 mrha_database | -- database.cpp 5950 ABB700CE27EB 0x2041 0x22c query ended setDeviceConfiguration success 0
Tue Aug 27 14:14:18 2019 mrha_database | -- database.cpp 4168 ABB700CE27EB 0x2041 0x22c got new consistency tag 0x86be
Tue Aug 27 14:14:20 2019 mrha_database | -- database.cpp 5950 ABB2F52D3151 0xb003 0x1d5 query ended setDeviceConfiguration success 0
Tue Aug 27 14:14:20 2019 mrha_database | -- database.cpp 4168 ABB2F52D3151 0xb003 0x1d5 got new consistency tag 0x6000
Tue Aug 27 14:14:22 2019 mrha_database | -- project.cpp 3594 ABB700D4CD32 0x2012 setting bus available to 1 1
Tue Aug 27 14:14:42 2019 mrha_database | -- databaseadaptor.cpp 900 setApplianceValues ABB2A1293051/ch0000 accessLevel functionId selectedIcon displayName room floor offsetX offsetY 2a 5 Heizen / Kühlen 08 01 0.057768321442499 0.815956983325285
Tue Aug 27 14:14:42 2019 mrha_database | -- databaseadaptor.cpp 900 setApplianceValues ABB2A1293051/ch0000 accessLevel functionId selectedIcon displayName room floor offsetX offsetY 2a 5 Heizen / Kühlen 08 01 0.057768321442499 0.815956983325285
Tue Aug 27 14:14:42 2019 mrha_database | -- databaseadaptor.cpp 2192 newPairing ABB2A1293051/ch0000 ABB2F52D3151/ch0003
Tue Aug 27 14:14:42 2019 mrha_database | -- database.cpp 5323 ABB2F52D3151 0xb003 0x1d5 starting query setDeviceConfiguration
Tue Aug 27 14:14:44 2019 mrha_database | -- database.cpp 2886 ABB2FFFFFFFF 0xb003 0x1d5 has sent a DD3 telegram with locked property server bit set 0x620 0x6100 0x804
Tue Aug 27 14:14:44 2019 mrha_database | -- project.cpp 9010 model is not consolidated
Tue Aug 27 14:14:44 2019 mrha_database | -- project.cpp 1110 ABB2FFFFFFFF 0xb003 0x1d5 created device with consistency tag 0x6100
Tue Aug 27 14:14:44 2019 mrha_database | -- database.cpp 5323 ABB2FFFFFFFF 0xb003 0x15c starting query setIndividualAddress
Tue Aug 27 14:14:44 2019 mrha_communication | -- setindividualaddress 82 ABB2FFFFFFFF 0xb003 set individual address 0x15c 0xbae7 0
Tue Aug 27 14:14:45 2019 mrha_database | -- database.cpp 5950 ABB2FFFFFFFF 0xb003 0x15c query ended setIndividualAddress success 0
Tue Aug 27 14:14:45 2019 mrha_database | -- database.cpp 5323 ABB2FFFFFFFF 0xb003 0x15c starting query getDeviceConfigurationPhase1
Tue Aug 27 14:14:46 2019 mrha_database | -- database.cpp 5950 ABB2FFFFFFFF 0xb003 0x15c query ended getDeviceConfigurationPhase1 error 1
Tue Aug 27 14:14:47 2019 mrha_database | -- database.cpp 5323 ABB2FFFFFFFF 0xb003 0x15c starting query getDeviceConfigurationPhase1
Tue Aug 27 14:14:48 2019 mrha_database | -- database.cpp 5950 ABB2FFFFFFFF 0xb003 0x15c query ended getDeviceConfigurationPhase1 error 1
Tue Aug 27 14:14:50 2019 mrha_database | -- database.cpp 5323 ABB2FFFFFFFF 0xb003 0x15c starting query getDeviceConfigurationPhase1
Tue Aug 27 14:14:50 2019 mrha_database | -- database.cpp 5950 ABB2FFFFFFFF 0xb003 0x15c query ended getDeviceConfigurationPhase1 error 1
-> Selbiges ist auch auf Abb1 zu erkennen, der 3-stellige Code ist ebenfalls falsch
-> Vgl.- auf dem Aktor steht die korrekte Adresse
-
- Hat evtl. irgendjemand bereits ein ähnliches Problem gehabt?
- Oder kann vll. sogar mit dem Log mehr anfangen?
- Ist u. U. ein Software-seitiger Fix ggF. möglich ("Hard-Reset" des Aktor per SSH o. Ä.)?
- Oder ist der Aktor ganz einfach "hinüber" und somit ein Garantiefall?
-> Habe heute beim Elektriker einen neuen geordert, kommt aber erst frühestens nächste Woche..
Mein Rat wäre, bis auf weiteres vorsichtig zu sein bei der Programmierung von Heizungsaktoren.
Evtl. besser "langsamer" und Abwarten bis die Konfiguration sicher übernommen wurde.
Hallo JD, erstmal vielen dank für deine ausführliche Beschreibung!
Leider hatte ich dieses Problem selbst noch nicht, kann aber bestätigen dass die Heizungsaktoren speziell beim umstellen zwischen Heizen und Kühlen recht träge reagieren.
Wir nutzen unsere Fußbodenheizung (Wärmepumpe) in den heißen Sommermonaten auch zum kühlen (haben leider keine Kühldecken). Daher kenne ich das leidige Thema mit dem Wechsel zwischen Heizen und Kühlen.
Auf die Idee den Wechsel zwischen Heizen und Kühlen mittels Binäreingang ins free@home zu „melden“ bin ich noch garnicht gekommen. Bin mit allerdings auch gerade nicht sicher ob unsere Wärmepumpe dafür einen Kontakt bereitstellt (Buderus Logatherm WPL AR)
Was die Einträge im Perma-Log angeht, erkenne ich dort lediglich die drei Versuche die Konfiguration des Aktors zu lesen, welche jeweils in „error 1“ enden. Klingt für mich daher nach einem Garantiefall. Ich muss allerdings gestehen, dass ich von den Möglichkeiten die Komponenten mittels SSH zu beeinflussen wenig Ahnung habe.
Hoffe ich konnte wenigstens etwas weiterhelfen. Vllt. hat ja sonst noch jemand eine Idee.
Leider hatte ich dieses Problem selbst noch nicht...
Nunja, das "leider" würde ich streichen ? Eher zum Glück, sollte ja hoffentlich kein globales Problem sein mit dem Aktor...
Wir nutzen unsere Fußbodenheizung (Wärmepumpe) in den heißen Sommermonaten auch zum kühlen
Zu Beginn des Sommers hatte bei mir die KD schon einmal nicht funktioniert - da war es allerdings ein einfach zu lösendes "Hardware"-Problem (Installateuere hatten vergessen die Haupthähne an den Kühlkreisverteilern zu öffnen, deshalb kein Durchlauf und damit das Problem Notabschaltung WP aus meinem obigen Post.)
Hatte daher testweise ebenfalls die FBH als Kühlung laufen - und war positiv überrascht, wie gut bereits das klappt. KD ist nochmals etwas effizienter, warme Luft nach oben etc.. Und eben nachfolgendes Problem nicht gegeben.
Fliesenböden werden schon recht kalt mit 20 Grad Vorlauf. Mir hätte das weniger ausgemacht - nur die Dame(n) des Hauses gehen gerne Barfuss.. ?
Auf die Idee den Wechsel zwischen Heizen und Kühlen mittels Binäreingang ins free@home zu „melden“ bin ich noch garnicht gekommen. Bin mit allerdings auch gerade nicht sicher ob unsere Wärmepumpe dafür einen Kontakt bereitstellt (Buderus Logatherm WPL AR)
Ich hatte dazu ewig recherchiert und schlussendlich herausgefunden, bei Mitsubishi (Zubadan/Ecodan) ist es der OUT8 - Ausgang am Innengerät.
Ob es die aufwendige und gut 500€ (12V DC Netzteil, Kabel extra für den Zweck, Installationsstunden) teure Zusatzinstallation wert war, naja.
Bisher sicher nicht - da ich die autom. Umschaltung in f@h gar nicht genutzt habe; wäre das Ziel der Programmieraktion von Di. gewesen. ? Bis "Murphy's Law" einmal mehr "zugeschlagen" hat
Wahrscheinlich hätte es ein einfacher Schalter am Binäreingang genauso gut getan (wäre meine Alternative gewesen, und könnte ich Dir als einfache & günstige Lösung empfehlen, da unabhängig von WP).
Den kurz betätigen ist immer noch viel weniger Aufwand als f@h jedes Mal umprogrammieren.
Was die Einträge im Perma-Log angeht, erkenne ich dort lediglich die drei Versuche die Konfiguration des Aktors zu lesen, welche jeweils in „error 1“ enden.
Würde ich genauso interpretieren - wie man es ggF. beheben könnte wissen wohl nur die Entwickler bei B-J / ABB. ?
- Ist u. U. ein Software-seitiger Fix ggF. möglich ("Hard-Reset" des Aktor per SSH o. Ä.)?
Meines Wissens kommt man doch als Otto-Normal-User gar nicht per SSH auf den SysAP drauf?
Oder ist der Aktor ganz einfach "hinüber" und somit ein Garantiefall?
Das wäre zumindest meine Vermutung - bei Speicherbausteine wie zB Flash oder EEPROM sind im gelöschten Zustand alle Bits auf dem Wert 1, bei 32 Bit in Hexdarstellung macht das FFFFFFFF. Daher sieht das für mich als Aussenstehener so aus, als ob das Ding einen Teil seiner Werksprogrammierung (mindestens die Seriennummer) verloren hätte, entweder durch einen Defekt oder durch einen Fehler in der Firmware.
- Ist u. U. ein Software-seitiger Fix ggF. möglich ("Hard-Reset" des Aktor per SSH o. Ä.)?
Meines Wissens kommt man doch als Otto-Normal-User gar nicht per SSH auf den SysAP drauf?
Oder ist der Aktor ganz einfach "hinüber" und somit ein Garantiefall?
Das wäre zumindest meine Vermutung - bei Speicherbausteine wie zB Flash oder EEPROM sind im gelöschten Zustand alle Bits auf dem Wert 1, bei 32 Bit in Hexdarstellung macht das FFFFFFFF. Daher sieht das für mich als Aussenstehener so aus, als ob das Ding einen Teil seiner Werksprogrammierung (mindestens die Seriennummer) verloren hätte, entweder durch einen Defekt oder durch einen Fehler in der Firmware.
@arne: Danke für Deine Einschätzung 🙂
Als "Otto-Normal-User" nicht - aber ggF. sind ja "Power-User" unterwegs.. 😉
Mit Hardware bzw. Speicherbausteinen kenne ich mich nicht so gut aus - aber interessant, dass das dort ebenfalls ähnlich ist.
Ich kenne das mit der "höchsten" Adresse (sprich FFFF.. bzw. 255.255.255) eher aus der Netzwerk-Welt, dort bedeutet es idR. "Broadcast". Könnte eine alternative Erklärung sein.
Aktor wurde heute ausgetauscht - funktioniert alles wieder so wie es soll.
Bzw. - ich lasse es jetzt im Testbetrieb so laufen, dass die Kühldecken zum Heizen mit verwendet werden.