[36_Vallox.pm] Neues Modul - Vallox Belüftungsanlagen

[orli]

Hm, kannst du damit was anfangen so ohne Umbrüche?

Code Auswählen Erweitern


BufferDebug

01112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca4320111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca3310111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca3310111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca3310111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca3310111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca3310111205aaa36011120589d2701112049007b0111204a007c0111204c28a60111205300850111205400860111205baa370111205ca3310111205aaa36011120589d27


Readings sind jetzt zwar teilweise da (Lüftungsstufe fehlt z.B. immer noch), senden klappt leider auch mit 2f nicht.

Gruß
orli

[Skjall]

Hallo Tibby,

danke für dein Feedback.

Dein BufferDebug.txt sieht erstmal ganz hervorragend aus:

Code Auswählen Erweitern


01211100295c
011121290f6b


Da fragt deine Fernbedienung die Anlage nach der Lüftergeschwindigkeit und die antwortet mit Stufe 4. Das müsste eigentlich genau so in deinen Readings stehen.

Dann fielen mir aber 2 Sachen auf:

Code Auswählen Erweitern

01112135a911
01211100a3d6
011121a38157
0121110071a4
0111217100a4
6c
011120290f6a
011110290f5a
01211100a3d6
011121a38157
01211100295c
011121290f6b

1. Da sind Bytes im Datagramm, die da nicht hingehören (das 6c)... und das Mehrfach. Das sollte eigentlich kein Problem sein, da das Modul das aktuelle Datagramm bzw. in diesem fall den Fehlwert nur ignoriert.
2. Wir haben hier ein 35a9 drin. "01112135a911" ist eine valide Response der Zentrale an die FB dass die TempIncoming 23 Grad Celsius ist. Jetzt passiert bei dir folgendes. Es fehlt dann ab und zu mal ein wert: Die 21. daraus wird im bufferduchlauf das Datagramm "011135A91101". Genau jetzt schlägt Murphy zu (alles in Hex): (01 + 11 + 35 + A9 + 11) mod 100 = 01 - Ein valides Datagramm und ein vollkommenes Versagen der Prüfsumme aus Zufall. Dass dieser Fehler sich immer wiederholt ist aber schon seltsam. Und: Zumindest in dem BufferDebug ist er nicht enhalten. Im Gegenteil: die Datagramme sind richtig. Nun kann es ja sein, dass die Fehler nur dann auftraten, als du nicht mitgeschnitten hast. Aber dass immer der gleiche Teil.. und nur die 21 fehlt kann ich mir nicht vorstellen. insbesondere da der Broadcast auf die 20 läuft. Das stinkt förmlich nach nem Bug.
Ich habe gerade mal meine Logs nach "35A9" gegrept und da läuft alles:

Code Auswählen Erweitern

2017.06.16 08:52:07 4: Vallox: Incoming Status-Info (Temperature): 01112035A910 (23 deg.)
2017.06.16 08:52:11 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:17 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:22 4: Vallox: Incoming Status-Info (Temperature): 01112035A910 (23 deg.)
2017.06.16 08:52:22 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:27 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:32 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:37 4: Vallox: Incoming Status-Info (Temperature): 01112035A910 (23 deg.)
2017.06.16 08:52:37 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:42 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)
2017.06.16 08:52:47 4: Vallox: Incoming Status-Info (Temperature): 01112135A911 (23 deg.)

Für den ersten Fehler: Nimm bitte mal ein viel dünneres Kabel. Ich bin kein Elektriker, deshalb irre ich mich vllt, aber ich könnte mir vorstellen dass für so geringe Ströme 1,5 mm² zu dick sind und dadurch der Widerstand zu hoch ist. Ich habe bei mir ein Aderpaar aus einen Cat5e Kabel genommen - Länge ca. 2m . Das ist ein AWG24/1 und hat somit 0,511 mm² Durchmesser.

-
Ich habe mich beim Modul sehr auf die Prüfsumme verlassen. Da werde ich nochmal an der Validierungsfunktion schrauben müssen. Ich werde wohl auch einen Indikator für die Fehlerquote im Datenstrom einbauen müssen.

LG Jan

[Skjall]

Hallo Orli,

Komm, gib es zu.. du bist der Umwelttechniker auf der Neumayer-Antarktisstation.
-
Was verwendest du denn für ein Kabel zum Anschluss?

LG Jan

[orli]

 

Ja genau, du hast mich ertappt!

Ich hab aktuell 2x0,6mm Draht ungeschirmt dran.


https://shop.loxone.com/dede/rangierdraht.html


Gehe eigentlich davon aus, dass das ausreicht für so geringe Ströme. Könnte es auch durch Cat7 ersetzen sollte das was bringen.


EDIT: Senden von Kommandos geht nun auch. Allerdings bekommt meine Fernbedienung das nicht mit und bleibt beim alten Setting stehen (mit dem anderen Plugin ändert sich der Zustand), ich hab mich eben nur gewundert warum die Lüftung so laut ist, als ich am Ausströmer vorbei lief. Da hab ichs nochmal per Gehör getestet. Senden klappt nun doch bei mir.

[Skjall]

Das klingt eigentlich ganz gut.
Was mich jetzt verwirrt ist wie bei Tibby, dass dein Log nicht zum BufferDebug passt. Das Debug sieht super aus und dein Log total durcheinander. Vllt. wäre ein geschirmtes kabel besser.
BTW: Ich habe mich vorhin übrigens vertan. Mein Kabel hat (zumindest laut Wikipedia) einen Querschnitt von 0,205 mm². Das andere war der Durchschnitt in mm. Aber wie gesagt. Nicht mein Beruf.

Ich habe mal den Validierungsfilter erweitert. Wenn jetzt ein scheinbar gutes Datagramm die falschen Adressen enthält kommt auf Verbose 4 eine Fehlermeldung und das Datagramm wird ignoriert. So werden die Readings zumindest nicht kontaminiert.
Ebenso habe ich die Internals "MessageCount" und "ErrorCount" gesetzt. So erhält man mal einen Überblick über unsinnige Daten.

Eine Bitte an alle Nutzer: Wenn man die Anlage startet erscheinen auf Fernbedienungen mit Display Zahlen. Die stehen im Zusammenhang mit den nur dann ausgelesenen "Initial"-Readings (1-5). Es wäre echt nett wenn ihr, während das Modul läuft, mal den Stecker der Anlage zieht bzw. die Klappe auf macht und sie damit neu hochfahren lasst. Wenn Ihr dann bitte ein Foto der Fernbedinung mit den Zahlen und die Initial Readings postet. Wenn ihr kein Display habt, sind die Readings auch hilfreich. So kann ich ggf. auf eine Bus- oder Anlagen-Version filtern.

LG Jan

[Skjall]

EDIT: Senden von Kommandos geht nun auch. Allerdings bekommt meine Fernbedienung das nicht mit und bleibt beim alten Setting stehen (mit dem anderen Plugin ändert sich der Zustand), ich hab mich eben nur gewundert warum die Lüftung so laut ist, als ich am Ausströmer vorbei lief. Da hab ichs nochmal per Gehör getestet. Senden klappt nun doch bei mir.

Normalerweise schicke ich einen Befehl an die Anlage ("11") und die Anlage antwortet an alle FB ("20") dass das die neue Einstellung ist. Schau mal bitte in die Logs, was von der Anlage kommt, wenn du am FHEM die Geschwindigkeit änderst. Das reicht eigentlich aus, denn ich will ja alle anderen Devices nur updaten, wenn die Anlage den Befehl gefressen hat. Das andere Modul macht das anders: Es schickt es an die Anlage, an die "10" und an die "20". Also alle möglichen. Dadurch updatet sie alles verfügbare. Finde ich nicht elegant, aber es scheint so, als wenn der Autor sein Modul für eine alte Anlage geschrieben hat. Ich werde mal bei der nächsten Version ein Attribut einbauen, damit man das forcieren kann.

LG  Jan

[orli]

Hab die Version jetzt mal eingespielt und lasse sie bis morgen früh laufen. Morgen tausche ich das Kabel mal gegen CAT, das wirds aber nicht sein, denn das Bufferlog passt ja. Kann ich da Attribut "an 10 und 20" senden irgendwie definieren?

Meld mich mit neuen Logauszügen morgen früh!

[Skjall]

Nein, das glaube ich auch nicht. zumindest nicht das Problem mit den fehlenden 21ern. Ich werde da mal am Sonntag oder Samstag Abend schauen, ob ich was finde.
Die chaotisch-defekten Datagramme könnte es jedoch schon verbessern.
-
noch nicht aber jetzt:
Neues Attribut: ValloxForceBroadcast auf 1

[orli]

Klappt, Status wird in Echtzeit geändert. Scheint für ältere Anlagen notwendig zu sein.

Jetzt müssen wir noch die Sache mit den invaliden Dategrammen und Readings hin kriegen.

[Tibby]

Hallo zusammen,

erst einmal vielen Dank an euch für die Unterstützung. Meine Neuinstallation (Raspi 3komplett neu mit Raspbian Jessie aufgesetzt) ist abgeschlossen und jetzt aktualisieren sich die Readings regelmäßig.

Bevor ich ein Update direkt in FHEM gemacht habe, sind wieder die folgenden Daten im Log erschienen:

Code Auswählen Erweitern


2017.06.17 11:41:28.247 4: Vallox: Incoming Status-Info (FanSpeed): 011135A91101 (Level )
2017.06.17 11:42:09.542 4: Vallox: Incoming Status-Info (Select): 011121A38157 (Bits 10000001)
2017.06.17 11:42:45.642 4: Vallox: Incoming Status-Info (FanSpeed): 011135A91101 (Level )
2017.06.17 11:43:16.598 4: Vallox: Incoming Status-Info (FanSpeed): 011135A91101 (Level )
2017.06.17 11:43:52.684 4: Vallox: Incoming Status-Info (Select): 011121A38157 (Bits 10000001)
2017.06.17 11:44:08.195 4: Vallox: Incoming Status-Info (FanSpeed): 011135A91101 (Level )
2017.06.17 11:44:44.313 4: Vallox: Incoming Status-Info (FanSpeed): 011135A91101 (Level )
2017.06.17 11:44:44.347 4: Vallox: Incoming Status-Info (Flags6): 0111217100A4 (Bits 00000000)
2017.06.17 11:44:59.793 4: Vallox: Incoming Status-Info (FanSpeed): 011135A91101 (Level )
2017.06.17 11:45:40.206 4: Vallox: Incoming Status-Info (Temperature): 01112035A910 (23 deg.)


Nach dem FHEM-Update tauchen diese nun nicht mehr auf. Ich bin daher etwas ratlos Es scheint aber nichts mit der Hardware (RS-485-Adapter oder Kabel) zu tun zu haben.

Meine Vermutung ist, dass es irgendwas mit der Perl-Installation zu tun hatte. Ich hatte vor einiger Zeit mal ein komplettes Update aller Module über CPAN angestossen, da ich Probleme mit dem Pushbullet-Modul in FHEM hatte.
Kann es sein, dass die Daten vom Adapter in deinem Modul falsch verarbeitet werden?

Im Anhang findet ihr auch ein Foto der Steuerung direkt nach dem Einschalten.

Ich werde die Situation weiter beobachten und melde mich dann nochmal.

Euch ein schönes Wochenende!

Viele Grüße,
Martin

[Tibby]

Hallo zusammen,

also das ist wirklich seltsam. Nach der kompletten Neuinstallation und dem Aktualisieren von FHEM hat alles funktioniert. Dann habe ich gemerkt, dass ich noch kein "apt-get update" auf dem System gemacht habe.
Nach dem Update (Heute um ca. 16:59, Geänderte Pakete habe ich aus dem Apt-Log angehängt) funktionierte es wieder nicht...

Also stehe ich jetzt wieder vor dem gleichen Problem wie gestern, dass sich die Readings nicht aktualisieren. Die Fehlermeldungen bzgl. der "Unhandled datagrams" sind bis jetzt nicht wieder im FHEM-Log aufgetaucht.

Es gibt aber jetzt die folgenden Meldungen:

Code Auswählen Erweitern


2017.06.17 18:23:03.595 4: Vallox: Invalid Status-Request: 010000000001
2017.06.17 18:24:10.593 4: Vallox: Invalid Status-Request: 01d629000000
2017.06.17 18:32:36.239 4: Vallox: Invalid Status-Request: 01d629000000
2017.06.17 18:33:02.041 4: Vallox: Invalid Status-Request: 01d629000000
2017.06.17 18:35:26.511 4: Vallox: Invalid Status-Request: 01d629000000


Hinweis: Ich habe für diese Tests die Datei aus Jans Post von gestern Abend verwendet.

Sowohl mit Minicom als auch mit aktiviertem ValloxBufferDebug sehe ich gültige Daten (siehe kurze Aufzeichnung, für ca 10-15s, im Anhang).

Beispiel:

Code Auswählen Erweitern


01211100a3d6
011121a38157 => 01 11 21: Lüftung meldet an Fernbedienung, A3: SELECT 81: Wert?
01211100295c
011121290f6b => 01 11 21: Lüftung -> FB, 29: FanSpeed 0F: 4, 6B: Checksum
...

dann plötzlich:

Code Auswählen Erweitern

011121a38157
011120ac8048
44805cd2
01112035a910
01112034b218
0121110071a4

Anschließend geht es wieder normal weiter.


Kann es sein, dass solch ein fehlerhafter Datensatz irgendwie den Puffer durcheinander bringt? Und irgendwie scheint es einen Zusammenhang mit einem anderen Paket auf dem System zu geben. Sonst hätte das Systemupdate keine Auswirkung auf das Verhalten haben dürfen.

Um die weitere Analyse zu vereinfachen, werde ich meine Konfiguration jetzt mal so lassen und nicht weiter dran rumfriemeln 

Hier noch kurz der letzte Status des Geräts in FHEM:

Code Auswählen Erweitern


Internals:
   CFGFN      /opt/fhem/cfg/10_vallox.cfg
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0@9600
   ErrorCount 14
   FD         14
   NAME       Vallox90SE
   NR         159
   PARTIAL
   STATE      opened
   TYPE       Vallox
   Readings:
     2017-06-17 17:03:10   CO2AdjustState  0
     2017-06-17 16:32:51   CO2High         0
     2017-06-17 17:02:28   CO2Low          0
     2017-06-17 17:03:05   EfficiencyAverage -100
     2017-06-17 17:03:04   EfficiencyIn    -200
     2017-06-17 17:03:04   EfficiencyOut   0
     2017-06-17 17:03:10   FanSpeed        4
     2017-06-17 17:03:10   FaultIndicator  0
     2017-06-17 17:03:10   FilterGuardIndicator 0
     2017-06-17 17:02:23   FireplaceBoosterStatus 0
     2017-06-17 17:02:23   FireplaceSwitchActivation 0
     2017-06-17 17:03:10   HeatingIndicator 0
     2017-06-17 17:03:10   HeatingState    0
     2017-06-17 17:03:10   PowerState      1
     2017-06-17 17:03:10   RHAdjustState   0
     2017-06-17 17:02:23   RemoteMonitoringControl 0
     2017-06-17 17:03:10   ServiceReminderIndicator 1
     2017-06-17 16:55:42   TempExhaust     24
     2017-06-17 17:03:04   TempIncoming    24
     2017-06-17 17:00:28   TempInside      27
     2017-06-17 16:58:27   TempOutside     26
     2017-06-17 18:17:59   state           opened
Attributes:
   ValloxBufferDebug 0
   alias      Vallox 90 SE
   icon       vent_ventilation
   room       Lüftungsanlage
   verbose    5


Seit ca. 17:00 heute Nachmittag kein Updates bei den Readings mehr zu sehen. System wurde mehrfach neu gebootet und FHEM mehrfach neu gestartet. Alles ohne Erfolg.

Viele Grüße,
Martin

[Skjall]

Hmm, das ist interessant. Vorweg: Ich habe einen NUC und keinen Pi. Insofern kann ich das nicht testen, da ich Intel-Pakete bekomme.

Das Script ist eigentlich ziemlich blöd:

Es hängt rechts ankommende Bytes an den Buffer an. Wenn der Buffer 7 Hex Werte, also 14 Zeichen lang ist, schneidet er die letzten 12 Zeichen ab, befüllt damit die Variable und duchläuft den Validierungsprozess. Da bedeutet auch dass der Buffer bei der Fehlstelle so aussieht:

Code Auswählen Erweitern

011120ac8048         # Validiertes Datagramm
1120ac804844
20ac80484480
ac804844805c
804844805cd2
4844805cd201
44805cd20111
805cd2011120
5cd201112035
d201112035a9
01112035a910         # Validiertes Datagramm

Und ohne Fehlstelle so aussähe:

Code Auswählen Erweitern

011120ac8048         # Validiertes Datagramm
1120ac804801
20ac80480111
ac8048011120
804801112035
4801112035a9
01112035a910         # Validiertes Datagramm

Sprich: Ein perfekt laufender Bus sollte eine Erkennungsrate von einem Datagramm auf 6 Bufferdurchläufe haben.
Je höher der Wert, desto schlechter der Bus. Betrachtet man nur die Fehlstelle wären es 1:10. Aber: Die Erkennung der unbeschädigten Datagramme ist nie beeinflusst. Am Ende finde ich beide unbeschädigten Datagramme.

Den Stick selber lese ich nicht aus. Dafür nutze ich das DevIO-Modul von Rudi.

Jetzt gibt es folgende Möglichkeiten:
1. Der Buffer füllt sich nicht richtig mit dem realen Datenstrom
2. Die Daten werden zugeliefert aber aus irgend einem Grund nicht richtig verarbeitet.

Jetzt könnte es natürlich sein, dass ich einen Denkfehler begangen habe.
Ich spiele mal was durch: Ich gehe von der Prämisse aus, dass DevIO mir immer nur ein Byte liefert. Mit meinem i5 NUC mit 16 GB RAM mag das auch so sein.
Ein RPi ist ja deutlich langsamer und SWAPed viel mehr. Dann kommen zB mal 3 Bytes auf einmal:

Da ich stumpf die den Buffer nehme und die 3-14. Stelle weiterverarbeite sähe das dann so aus:

Code Auswählen Erweitern

1.1: a40111217100 <-- a40111       # Read in den Buffer
1.2: a40111217100a40111            # Neuer Buffer (Hier erwarte ich eigentlich nur 14 Zeichen)
1.3: 0111217100a4                  # Neuer Buffer nach dem Schneiden (substr($buffer,2,12)) (Valides Datagramm)
2.1: 0111217100a4 <-- 21a3         # Read in den Buffer (dieses mal 2 Bytes und erst nach der bereits gelesenen 11)
2.2: 0111217100a421a3              # Neuer Buffer (Das nun kommende Datagramm ist schon jetzt unsinn)
2.3: 11217100a421                  # Neuer Buffer nach dem Schneiden (Nun ist es vollkommen durcheinander.)


Das würde auch erklären, warum ich kein Muster in den Daten erkenne. Insofern brauche ich aus dem DevIO einen zusätzlichen DevIOBuffer der mir die Daten kontinuierlich, Byte für Byte zuliefert.

---
Zeitsprung: Ich habe das gerade reinprogrammiert und was soll ich sagen: Ich hatte ja keine Ahnung! Ich hatte ein dicken Schnitzer im Design, weil ich die Funktionsweise des FHEM Aufrufs falsch verstanden hatte. Das es überhaupt etwas ausgelesen hat grenzt schon an ein Wunder.

LG Jan

[Tibby]

Hallo Jan,

das war ein Volltreffer! Ich habe das aktualisierte Modul aus deinem Post eben eingespielt und jetzt kommen die Readings zuverlässig im Sekundentakt.

So schaut's aktuell aus:

Code Auswählen Erweitern


Internals:
   CFGFN      /opt/fhem/cfg/10_vallox.cfg
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0@9600
   FD         14
   MR_Flags6  00000000
   MR_Select  10000001
   NAME       Vallox90SE
   NR         159
   PARTIAL
   STATE      opened
   TYPE       Vallox
   Readings:
     2017-06-18 00:37:02   CO2AdjustState  0
     2017-06-18 00:36:49   CO2High         0
     2017-06-18 00:36:49   CO2Low          0
     2017-06-18 00:37:02   EfficiencyAverage -91.6666666666667
     2017-06-18 00:37:02   EfficiencyIn    -150
     2017-06-18 00:37:02   EfficiencyOut   -33.3333333333333
     2017-06-18 00:37:02   FanSpeed        4
     2017-06-18 00:37:02   FaultIndicator  0
     2017-06-18 00:37:02   FilterGuardIndicator 0
     2017-06-18 00:37:02   FireplaceBoosterStatus 0
     2017-06-18 00:37:02   FireplaceSwitchActivation 0
     2017-06-18 00:37:02   HeatingIndicator 0
     2017-06-18 00:37:02   HeatingState    0
     2017-06-18 00:37:02   PowerState      1
     2017-06-18 00:37:02   RHAdjustState   0
     2017-06-18 00:37:02   RemoteMonitoringControl 0
     2017-06-18 00:37:02   ServiceReminderIndicator 1
     2017-06-18 00:36:50   TempExhaust     21
     2017-06-18 00:37:02   TempIncoming    22
     2017-06-18 00:36:50   TempInside      27
     2017-06-18 00:36:50   TempOutside     25
     2017-06-18 00:27:43   state           opened
Attributes:
   ValloxBufferDebug 0
   alias      Vallox 90 SE
   icon       vent_ventilation
   room       Lüftungsanlage
   verbose    0


Vielen, vielen Dank für die schnelle Unterstützung!

Mit besten Grüßen,
Martin

[Skjall]

Das freut mich. Dass deine Effizienz nicht stimmt liegt vermutlich daran, dass du den Wert für die DamperMotorPosition nicht hast. Die Effizienz ist kein Reading aus dem Bus sondern errechnet das Modul. Wärmetauschereffizienz ohne aktiven Wärmetauscher zu berechnen geht nicht
Ist das Reading mittlerweile da? Bzw: kannst du es selbst per get anfordern?

Ich werde im Release noch filtern, ob ein Reading vorhanden ist bevor ich die Berechnung durchführe.

LG Jan

[Tibby]

Das freut mich. Dass deine Effizienz nicht stimmt liegt vermutlich daran, dass du den Wert für die DamperMotorPosition nicht hast. Die Effizienz ist kein Reading aus dem Bus sondern errechnet das Modul. Wärmetauschereffizienz ohne aktiven Wärmetauscher zu berechnen geht nicht
Ist das Reading mittlerweile da? Bzw: kannst du es selbst per get anfordern?

Ich werde im Release noch filtern, ob ein Reading vorhanden ist bevor ich die Berechnung durchführe.

LG Jan

Hallo Jan,

ja - das mit der Effizienz war mir auch schon aufgefallen. Hatte mir dann den Quellcode angeschaut und dann vermutet, dass es beabsichtigt war.
Im Sommerbetrieb versucht die Anlage meines Wissens die einströmende, wärmere Außenluft mit der auströmenden, kälteren Innenluft ein wenig zu kühlen. Daher war meine Interpretation, dass negative Werte hier diesen Kühlungseffekt repräsentieren.

Code Auswählen Erweitern


$EfficiencyIn = ($TempIncoming-$TempOutside)/($TempInside-$TempOutside)*100;
$EfficiencyOut = ($TempExhaust-$TempIncoming)/($TempOutside-$TempIncoming)*100;


Aus dem Log:
2017.06.18 00:28:37.249 5: Vallox: Efficiency Inside: (22-22)/(27-24)*100 = -66.6666666666667
2017.06.18 00:28:37.254 5: Vallox: Efficiency Outside: (21-22)/(24-22)*100 = -50

Das mit dem Reading "DamperMotorPosition" habe ich mir auch angeschaut. Ich verstehe das so, dass in meinem Fall eine Berechnung stattfindet, da der Wert für dieses Reading eben bei mir aktuell <> 1 ist. Für den Fall das DamperMotorPosition==1 ist, wird keine Berechnung ausgeführt, sondern 0 ausgegeben:

Code Auswählen Erweitern


# If HRC is in Bypass - Efficiency is 0
if (ReadingsVal($name,"DamperMotorPosition",0) == 1) {
readingsSingleUpdate($hash,"EfficiencyIn", 0, 1);
readingsSingleUpdate($hash,"EfficiencyOut", 0, 1);
readingsSingleUpdate($hash,"EfficiencyAverage", 0, 1);
Log3 ($name, 5, "Vallox: Efficiency Override: HRC Bypass");

} else {...}


Das sieht für mich so OK aus...

Bei einem "get Vallox90SE reading DamperMotorPosition;" erscheint nur ein leeres Popup.

LG,
Martin