Helios easycontrol und Edomi

[Marino]

Das sind die Internen der KWL, die ausgelesen werden. Manchmal zeigen 2 gleichzeitig einen total falschen Wert (0°C) z.B.. Triggert man dann den LBS sind sie wieder richtig.
Edomi schaut sich die Temperaturen dann an und wertet aus, ob der Bypass offen sein sollte oder nicht und schreibt dann E13 und E14 mit Werten innerhalb des erlabten Bereichs, damit die Klappe damit steuert.

Ich habe eben gedacht, ich stelle mal die Stufe um, denn die KWL lässt sich inzwischen seit Monaten immerhin zuverlässig steuern. Und, was passiert?

Datei: /usr/local/edomi/main/include/php/ModbusMaster.php | Fehlercode: 1 | Zeile: 150 | Maximum execution time of 35 seconds exceeded FATALERROR

Edomi-Projekt aktivieren und es ging.

Anschließend brauchte ich nur einmal die Lüftungsstufe ändern und hatte sofort falsche Werte. Die Lüftungsstufe wurde anstandslos geändert.
Die Visu zeigt die Werte von A4-A7.

Edomi_Visu.png Helios.png
Die Werte sich zwar diesmal nicht 0°, aber sie weichen doch erheblich voneinander ab und die Drehzahl des Lüfters ist auch falsch. 1618 waren es auf der Website, aber man sieht an den 10, dass damit keine 164m^3/h umgewälzt werden können (Volumenstrom der Zuluft bei Stufe 2).

Anschließend habe ich nochmal auf Lüfterstufe 3 gestellt:
Edomi_Visu_2.png

Hier gibt es sogar schon mehr zu sehen. Man sieht zum einen, dass die Temperaturen nun stimmen. Zum anderen sieht man rechts an den 20,4°C, dass bei der Falschmessung der Bypass aktiviert wurde (oberer Abzweig wird genutzt) und bei der richtigen wieder deaktiviert (unterer Abzweig wird genutzt).
Der Bypass durfte aber gar nicht schalten, da 15,5°C und 5,5°C (Außenluft) beide kleiner sind als 21,6°C (Abluft).

Im Log steht aber auch nicht "Temp. Fortluft = 5.5", sondern "Temp. Fortluft = 5.5�" (mit Fragezeichen) und zwar bei zwei Abfragen. Ggf. kommt die Logik damit auch durcheinander und hat geschaltet. Ich deaktiviere die Logik für Bypass mal, glaube aber nicht, dass es eine Änderung gibt, denn das Problem habe ich schon immer gehabt und die Logik nicht.


Viele Grüße
Nils




EDIT:
Nun ist die Bypass-Logik raus (gelöscht), damit sie nicht mit rein pfuschen kann.
Keine 10 Min. später bekomme ich für Zuluft und Abluft jeweils 0°C. Auffällig ist, meistens oder immer tritt das päärchenweise auf. Also Zuluft & Abluft oder Außenluft & Fortluft. Die Drehzahl ist in der Visu komischerweise noch richtig, aber das Log spricht eine andere Sprache. Woher die ganzen � kommen, würde ich gerne mal wissen. Ist das ganze ggf. ein Problem der Zeichencodierung und daher bekomme ich so komische Werte?
Log zeigt:

2021-08-08 10:24:53 602886 28418 debug EXE19000165 [v0.6]: Temp. Außenluft = 15.5
2021-08-08 10:24:53 852925 28418 debug EXE19000165 [v0.6]: Temp. Zuluft = 0���
2021-08-08 10:24:54 102833 28418 debug EXE19000165 [v0.6]: Temp. Fortluft = 16.7
2021-08-08 10:24:54 354552 28418 debug EXE19000165 [v0.6]: Temp. Abluft = 0���
2021-08-08 10:24:54 602433 28418 debug EXE19000165 [v0.6]: Zuluft Stufe Status = 2
2021-08-08 10:24:54 852019 28418 debug EXE19000165 [v0.6]: Abluft Stufe Status = 0
2021-08-08 10:24:55 101938 28418 debug EXE19000165 [v0.6]: Zuluft rpm Status = 1626
2021-08-08 10:24:55 351644 28418 debug EXE19000165 [v0.6]: Abluft rpm Status = ����

Die Website zeigt richtige Werte. Nun kommt noch das ABER, denn die Werte sind ja richtig, wenn ich nochmal triggere. Wenn ich also nichts mache, nach 15 Minuten. Wenn ich auf der Website schaue, dann ändert sich die Lüfterdrehzahl alle 3-4s. Nicht gravierend, lediglich um 1-2 RPM. Wenn die Temperaturen auch alle paar Sekunden aktualisiert wird, kann ich so nicht mit Gewissheit sagen, ob die Werte dort auch richtig sind, denn ggf. ist es nur der eine Wert und bis ich drauf schaue, ist er wieder richtig, da ein paar Sekunden vergangen sind. Edomi behält den Wert ja für 15 Min., bis getriggert wird.

[gbglace]

Ja die Frage ist welche Sensoren generieren denn die Temperaturen. Sind das deine Temperaturen aus dem KNX die Du an die KWL übergibst und dann dort falsch ankommen und zu der verrückten Steuerung führen oder sind es die KWL internen Sensoren wovon ggf einer einfach defekt ist und daher die KWL verrückt steuert. Und selbst bei der ersten Variante wäre es möglich das auch der KNX Sensor defekt ist.

[SebastianBaeumler]

Hallo Nils...

Was Degen den die Werte auf der Webseite.
Wenn die auch komisch sind, würde ich einen Fehler in der KWL nicht aus schließen.

Ob du die Werte via modbus, Webseite oder knx Modul aus liest, werden die Werte mit ziemlicher Sicherheit den gleichen Ursprung haben. Und folglich bei allen Möglichkeiten im falsch sein.

Gruß Sebastian

[Marino]

Seid ihr wirklich alle wunschlos glücklich und alles funktioniert, wie es soll?
Meine Bypass-Klappe spielt gerade verrückt, da die Temperaturen andauernd falsch sind und die Logik dann steuert.
Ich frage mich wirklich, ob das originale Busmodul auch diese Fehler hat oder ob die damit weg wären. Denn 4 Sensoren + Anbindung an KNX ist zwar günstiger, aber die Mehrkosten für das Modul würden sich erst recht nicht lohnen, wenn ich dann die gleiche Problematik habe, wie jetzt.

Viele Grüße
Nils

[Marino]

Nachdem ich nun länger mal getestet habe, muss ich nochmal nachfragen. Ich triggere alle 15 min.und nachdem ich die SD-Karte getauscht habe, funktioniert die Netzwerkverrbindung nun. Nun spiele ich gerade mit dem Bypass im Sommer rum, denn die KWL schafft es bei Automatik dass sich die Temperaturen so langsam angleichen, dass bei 34°C Aussentemperatur immer noch der Bypass offen ist.

Was mir also allgemein aufgefallen ist:
1. Für die Temperaturwerte kommen ab und an falsche Werte. Also nicht nur ein wenig falsch. Statt 34°C Außenluft sind es auf einmal 5,1°C und der Bypass wird geöffnet, um die "kalte" Luft reinzulassen. Oder die Zuluft zeigt 1068°C und dagegen sind auch die 34°C kalt und die Anlage macht den Bypass auf. Diese Fehlmessungen kommen häufiger vor. In den letzten 2 Tagen mehr als 10 mal definitiv. Mal so grob aufs Diagramm geschaut.
2. Manchmal ist eine ganze Seite merkwürdig. Also Außenluft zeigt 0°C, Fortluft 0°C und Zuluft-Lüfter hat ca. 30RPM. Die andren Werte sind normal. Ein anderes Mal ist die Zuluft 0°C, die Abluft 0°C und der Abluftlüter hat um die 30RPM.
3. Wenn ich die KWL stromlos mache, bekomme ich eine Fehlermeldung im Fehler-Log:

2021-06-18 16:45:01 460984 ? 26932 Datei: /usr/local/edomi/main/include/php/ModbusMaster.php | Fehlercode: 2 | Zeile: 100 | socket_connect(): unable to connect [113]: No route to host ERROR

Eigentlich klar, aber es ist anschließend erst wieder möglich die KWL mit dem LBS zu verbinden, wenn ich das Projekt neu aktiviere. Ggf. geht auch ein Neustart (Edomi), aber das habe ich nicht getestet. Wenn ich nicht neu aktiviere, ist keine Verbindung möglich.
4. Selten (heute Nacht z.B.) bekomme ich einen Fehler im Fehler-Log, der dazu führt, dass eine Steuerung der KWL auch nicht möglich ist. Die Temperaturwerte für Abluft und Zuluft waren über 6,5h leicht fallend und wurden ausgelesen. Fortluft und Außenluft hingegen waren bei 0°C. Lüfterstufe konnte ich nicht ändern, erst nach Projektaktivierung war alles gut. Der Fehler kam heute das zweite Mal vor. Jedenfalls habe ich ihn das zweite Mal gemerkt.

2021-06-20 00:30:41 402529 ? 12987 Datei: /usr/local/edomi/main/include/php/ModbusMaster.php | Fehlercode: 1 | Zeile: 150 | Maximum execution time of 35 seconds exceeded FATALERROR

5. Manchmal glaube ich, die Temperatursensoren haben eine sehr hohe Toleranz oder zeigen falsche Werte. Ich kann z.B. bei 22°C angesaugter Außenluft nicht glauben, dass bei aktiviertem Bypass und somit umgangenen Wärmetauscher die Zuluft 24,2°C betragen soll. Wodurch sollte die gleich 2,2°C angewärmt werden? Das ganze auch über längeren Zeitraum. So warm kann die KWL ansich nicht sein und der Raum, in der die KWL verbaut ist, hat auch ca. 21°C gehabt.

Wie sieht das bei euch aus? Habt ihr auch immer wieder falsche Werte mit dem LBS und traut ihr den Temperaturwerten?

Ich überlege, was man tun kann, damit alles richtig funktioniert. Also immer über Steuerbar, Temperaturwerte plausibel und damit die Berechnungsgrundlage für Bypass oder Bypass manuell steuern?

Mögliche Lösungen:
- Der LBS zeigt richtige Werte, da hier irgend etwas falsch läuft und der Fehler gefunden ist
- Temperatursensoren an meine Heizung anbinden (ca. 170€). Dann kann Edomi den Bypass berechnen und liegt nicht falsch, da die Werte der KWL nicht stimmten.
- Bypass manuell öffnen (Helios KWL-EM Erweiterungsmodul (ca. 230€). Wenn der LBS mal nicht funktioniert, könnte Edomi oder wer auch immer, immer steuern. Macht nur in Verbindung mit Temperatursensoren Sinn, denn wenn der LBS gerade mal nicht kann, hätte ich auch keine oder falsche Werte für die Berechnung ohne extra Sensoren.
- KNX-Modul (360-390€ ca.). Hilft das? Ich meine wenn Modbusfehler bei Edomi vorkommen, beeinflussen die dann auch das oder ist das mit dem kein Problem. Wenn ich es nicht überlesen habe, kann ich damit aber auch die Bypasstemperaturen nicht ändern, wo ich dann zur Steuerung wieder das Erweiterungsmodul benötigen würde.


So kann es jedenfalls nicht weiter gehen. Ich weiß nur nicht, was am sinnvolsten ist. Aber eine Bypassklappe, die durch falsche Temperaturen auch falsch gesteuert wird und warme Luft rein lässt, ist doof. Sie nicht steuern können (passiert deutlich seltener) nervt ein wenig, da meine Frau alleine nichts machen kann. Selten aber doofer Fehler.

Was meint ihr dazu? Wie ist das bei Euch? Und was würdet ihr machen/probieren. Oder kann eine Änderung im LBS an irgendeiner Stelle Besserung bringen?


Ich freue mich auf Eure Antworten.

Viele Grüße
Nils

EDIT: Ich habe noch ein paar Bilder angehängt. In der Visu ist rechts oben der Wert, wenn Bypass aktiv, rechts unten, wenn deaktiv.
1: Rechte Seite Werte falsch, alle bei 0 oder 0000
1.jpg 4.png

2: Linke Seite Werte falsch
2.jpg

3: Bypass offen und trotzdem 2,1°C Erwärmung. KWL ist im Keller bei ca. 21°C (zu dem Zeitpunkt).
3.jpg

5: Sprünge im Datenarchiv, wo immer andere Sensoren 0°C haben
5.png

6: Zuluft hat über 1500°C
6.png

7: Modbus Fehler heute Nacht (oben bbeschrieben in #4)
7.2.png

[saegefisch]

neuer Thread zum Thema "/usr/local/edomi/www/shared/php/base.php | Fehlercode: 8 | Zeile: 20 | sql_connect(): send of 5 bytes failed with errno=32 Broken pipe ERROR"
--> siehe hier

Hier geht es bei Bedarf mit dem Ursprungsthema "Helios easycontrol" weiter...

[vento66]

Vielleicht mal einen neuen Thread aufmachen...
Dann würd ich mal schauen, wer welche LBS am laufen hat, vielleicht gibt es da ja eine Schnittmenge.

[baumhaus123]

Ich habe zwar keine Helios, aber seit einiger Zeit ebenfalls Deiner erste Meldung:

2021-02-03 17:46:10 550434 ? 15047 Datei: /usr/local/edomi/www/shared/php/base.php | Fehlercode: 8 | Zeile: 20 | sql_connect(): send of 5 bytes failed with errno=32 Broken pipe ERROR

Auch zu wechselnden Zeiten (also nicht die üblichen Hochlast-Zeiten um Mitternacht oder volle Stunden), manchmal gehäufter, manchmal eine ganze Weile gar nicht mehr.

Ob das seit dem Upgrade 2.01 -> 2.02 passiert oder länger, kann ich leider nicht mehr sagen. Die Foren-Suche liefert so wenige Treffer, dass es wohl nur bei wenigen Systemen auftritt... Vielleicht verdient es aber ein eigenen Thread und hat wohl möglich nichts mit dem Thema dieses Threards zu tun.

Jetzt hat's mich auch erwischt. In unregelmäßigen Abständen bekomme ich ein paar Mal täglich exakt diese Meldung im Fehlerlog. Ich habe auch keine Helios. Ich bin vor ein paar Wochen auf CentOS 7 migriert. Diese Meldungen hatte ich mit CentOS 6 noch nicht - mit 7 aber auch nicht sofort. Ich kann keinerlei Systematik erkennen und bin für jegliche Hinweise dankbar.

[gspsteve]

Jetzt ist es auch bei mir wieder soweit, durch Filterwechsel die Helios KWL geöffnet und seitdem ist sie wieder Netzwerktechnisch nicht erreichbar. Auch durch mehrmaliges ein / aus schalten nicht. Das ist schon nervig...

[saegefisch]

Ich habe zwar keine Helios, aber seit einiger Zeit ebenfalls Deiner erste Meldung:

2021-02-03 17:46:10    550434    ?    15047    Datei: /usr/local/edomi/www/shared/php/base.php | Fehlercode: 8 | Zeile: 20 | sql_connect(): send of 5 bytes failed with errno=32 Broken pipe    ERROR

Auch zu wechselnden Zeiten (also nicht die üblichen Hochlast-Zeiten um Mitternacht oder volle Stunden), manchmal gehäufter, manchmal eine ganze Weile gar nicht mehr.

Ob das seit dem Upgrade 2.01 -> 2.02 passiert oder länger, kann ich leider nicht mehr sagen. Die Foren-Suche liefert so wenige Treffer, dass es wohl nur bei wenigen Systemen auftritt... Vielleicht verdient es aber ein eigenen Thread und hat wohl möglich nichts mit dem Thema dieses Threards zu tun.

[Marino]

Da müsste ich mir dann wohl mal einen Mirror-Port einrichten und einen Rechner mit Wireshark dran hängen.

[SebastianBaeumler]

Hallo Nils,

das PS: war nur allgemein als Info dad es auch mit DHCP geht.

Für die Analyse warum der Socket connect schief geht, wäre die Aufzeichnung hilfreich.

[Marino]

Ich rufe alle 15 Minuten ab. Das sollte eigentlich nicht zu viel sein.

Nicht, dass wir und falsch verstehen, ich habe in dem Netzwerk den DHCP-Server deaktiviert und die KWL weiterhin statisch, wie zuvor.

[SebastianBaeumler]

Hallo Nils,

wie oft rufst du den die Daten der Helios ab?

Ich weiß aus meiner Erfahrung, das der Helios Baustein zusammen mit der ModbusMaster.php für jeden Parameter die Verbindung Auf und wieder Ab baut.

Vielleicht kommt das System hier durcheinander.
Wenn du mich mal direkt anschreibst, kann ich dir meinen Umbau der Bausteine auf einen Single Connect für Tests zur Verfügung stellen.
Vielleicht verbessert sich das Verhalten dann.

Auch ist immer eine Netzwerkaufzeichnung z.B. mit Wireshark hilfreich, das man sieht was da stört.

Gruß,
Sebastian

PS: bei mir läuft die Helios KWL EC 370 seit Jahren auf DHCP ohne Probleme. Lediglich zum Filterwechsel wird sie ausgeschaltet.
Helios.png

[Marino]

Ich wollte mich mal wieder zu Wort melden.

Also, ich habe eine neue SD-Karte bekommen. Mit dieser ist, wenn ich direkt dran gehe, also ohne Router, die Anlage immer erreichbar gewesen, was mit der vorherigen Karte nicht so war. Nun habe ich sie also wieder am Router angeschlossen. Wie bereits gesagt, eigenes Netzsegment, keine weiteren Geräte. Also nur der Router selber und die KWL. Nachdem ich alles Mögliche probiert habe und sie immer wieder nicht erreichbar war, gab es nur noch eine Einstellung: DHCP. Nun, ich habe DHCP deaktiviert, da die IP eh statisch vergeben ist und seitdem läuft sich seit ein paar Tagen durch. Ich werde weiter beobachten, aber zuvor lief sie nicht einmal auch nur 24h durch und nun über 4 Tage, also bin ich zuversichtlich. Wie auch immer DHCP gestört haben kann bei statischer Adressierung.


Ein kleines ABER gibt, es leider trotzdem.

Ich nutze CentOS 7 und habe daher, wie von SebastianBaeumler in Post #134 beschrieben die ModbusMaster.php entsprechend geändert.

Nun bekomme ich täglich zu unterschiedlichen Zeiten morgens (die letzten Tage war es ein 4h Fenster) die folgenden beiden Meldungen. Bei der ersten weiß ich nicht, ob sie wirklich hiermit zusammen hängt.

2021-02-03 06:10:06 404522 ? 815 Datei: /usr/local/edomi/www/shared/php/base.php | Fehlercode: 8 | Zeile: 20 | sql_connect(): send of 5 bytes failed with errno=32 Broken pipe ERROR

2021-02-02 14:15:04 370699 ? 20930 Datei: /usr/local/edomi/main/include/php/ModbusMaster.php | Fehlercode: 2 | Zeile: 100 | socket_connect(): unable to connect [113]: No route to host ERROR

Wenn ich diese Meldung(en) erhalte, kann ich den LBS nicht mehr triggern, also die KWL nicht steuern und auslesen. Projekt aktivieren hilft leider nicht, erst nach Edomi-Neustart geht es wieder.

Hat jemand eine Ahnung, woran das liegen kann? Denn erreichbar ist die KWL definitiv und lässt sich im Webinterface steuern.


Viele Grüße
Nils


PS (EDIT): Laut Helios Support sagt übrigens der Fehler "Datenaustausch:8: Fehler beim Upload einer Datei" erst einmal gar nichts aus und sie ärgern sich eher damit rum, dass der viel zu früh gezeigt wird und die Kunden zusätzlich verwirrt.

Und für die, die es interessiert mit der SD-Karte:
Die Karte ist eine 8GB Sandisk MicroSD. Wurde schnell fertig gemacht und verschickt und war dann knapp 3-4 Tage später hier. Anbei eine Anleitung zum Wechseln und die Bitte, die alte Karte wieder zurück zu schicken.