« Heizung, Lüftung, Klima  |

DIY Alternative zu Nibe Modbus Modul

Teilen: facebook    whatsapp    email
#nibepi
 
 1  2 ... 3 ... 12  13  14  15 ... 16 ... 49  50  51 
  •  chrismo
  •   Gold-Award
29.1.2019 - 25.4.2024
1.009 Antworten | 62 Autoren 1009
127
1136
Weil es hier immer wieder zu Diskussionen zum Thema Modbus-Anbindung der Nibe kommt, wollte ich hier mal kurz meine Erfahrungen mit dem Nachbau einer DiY Lösung, auf Basis von im Netz vorhandener Infos, teilen. Für mich war es eine Spielerei und Zeitvertreib der letzten Tage. Der Post dient vor allem als Speicherort für meine gesammelten Infos und evt. dem Austausch von Leuten, die das so oder so ähnlich bei sich installiert haben. Ich kann und will hier keine Empfehlung abgeben, sowas selbst zu machen!

Die Lösung basiert im Wesentlichen auf den Nibe Bindings von openHAB (https://www.openhab.org/addons/bindings/nibeheatpump/), das eine Umsetzung Modbus auf UDP macht. Infos zur Funktionsweise findet man auf der openHAB Seite bzw. dem entsprechenden github Repo.

Die grobe Vorgangsweise war folgend:
1) Auf einen Arduino mit Ethernet Shield und RS485 Adapter die NibeGW Software (Teil des Bindings) installieren. Der Ardunio Code muss dabei an die eigenen Netzwerkeinstellungen angepasst werden. 

2) Den Arduino an die Wärmepumpe und ans LAN anschließen.

3) Die Nibe Modbus Manager Software auf einem Rechner installieren und bis zu 20 Register auswählen, die periodisch von der Wärmepumpe exportiert werden sollen. Diese Konfig muss gespeichert und per USB-Stick auf die WPWP [Wärmepumpe] übertragen werden.

4) Das Modbus Modul in der WPWP [Wärmepumpe] aktivieren. Wenn alles geklappt hat, bleibt die Wärmepumpe im Normalbetrieb. Falls irgendwas bei der Kommunikation mit dem Arduino schief geht, wird eine Fehlermeldung am Display ausgegeben und die WPWP [Wärmepumpe] geht in einen Alarmmodus.

5) Das nibeopenhab Binding in openHAB installieren und konfigurieren.

zu 1) Man könnte dazu auch einen Raspberry Pi mit RS485 Adapter verwenden, auf dem dann auch openHAB selbst läuft. Das finde ich aber nicht optimal. Ein Pi wäre mir da nicht robust genug. Selbst ein einfacher Neustart des Pis würde zu einem Fehler der WPWP [Wärmepumpe] führen und ein SD-Kartenfehler wäre sowieso ungemütlich.

zu 5) Da ich derzeit noch nicht weiß ob es openHAB oder was anderes wird - über Erfahrungen bzw. Empfehlungen würde ich mich freuen(!) - habe ich das Binding so adaptiert, das es ohne openHAB läuft. Derzeit verwende ich die Log-Dateien dieses "Stand-Alone Bindings" zur Speicherung der Werte. Eine Erweiterung für "richtige" Ausgabeformate bzw. Kanäle (Umsetzung auf KNX wurde hier mal in einem anderen Thread diskutiert) wäre aber von hier weg leicht machbar.

von energiesparhaus

  •  nibepi
26.2.2020  (#261)

zitat..
ChrisTartu schrieb: There are a number of registers being posted to MQTT in intervals (once per minute?)
is this list of registers defined?

This is from the functions in Nibepi, updating graphs and functions, updates occur every minutes and 3 minutes. Different registers, in the latest release it will not update whats not neccesary, depends on what functions you have activated.
 

zitat..
ChrisTartu schrieb: For each register the main value is posted to MQTT, but also a "/raw". What is the purpose of that? Seems redundant to me. The two outputs for the node are great though.

If I remember correctly, the regular output is formatted (In swedish) So if register 45001 (Alarm register) says 183 that means "Avfrostning" (Defrosting) so it will output that, the /raw always outputs a number. So you can map it in your program later to whatever you want to call it.
 

zitat..
ChrisTartu schrieb: I am tracking energy consumption (independently of Nibe/Pi), but would like to know how much is used for water and how much for heating.

You can get that info, but only for the compressor. Register 43144 outputs the total KWH for the compressor, and 43305 is the total hotwater production for the compressor. So 43144-43305 is the heat.


1
  •  ChrisTartu
27.2.2020  (#262)
Hm, my last post didnt make it to the board. Anyway.

Thanks for the answers to my question Jan and Fredrik.

/reg/raw vs /reg:
So far all my value and raw values were exactly the same, even for "text" registers
Here is an example, that does not seem to use translation/formatting.
nibe/modbus/41929 NORMAL
nibe/modbus/41929/raw NORMAL
Anyway, knowing this, I will switch to using /raw for my following logic-nodes and db entries
 
--------------------------------------------------

Great pointers to the energy registers. That allows for very detailed power usage information.
Unfortuntately, I get read timeouts for those registers. Maybe not supported for F1155?

The amp registers are always at 0 on my system, but I thought those are used to measure the main house connection power usage to automated safety power usage reduction?!

--------------------------------------------------
BTW: There is no problem running NibePI 1.1beta with an external MQTT server. I am using Mosquitto on a different server. No issues at all.
--------------------------------------------------

Fredrik, it is a bit unclear, how you define "activated functions". At what point do they become activated? 
- if there is a config some? 
- if certain nodes are present in a flow?
- if these nodes are used by sending msgs to them?

--------------------------------------------------

I have just now added and configured a "NibePi Weather" node.
What is the input used for?
On the outputs (connected both to debug) I get those kind of messages:

topic: "Utomhustemperatur"
payload: -0.4 (that is the same is measured by the Nibe sensor,right?)

topic: "Kurvjustering"
payload: 0 (curve adjust is configured to 0)

topic: "Vindgraf"
-no payload-

--------------------------------------------------

How is the Pricelevel node supposed to work?
Do you have any written documentation for the nodes? (language does not matter)

--------------------------------------------------

Jan, ich werde mir die Modbus Doku von Nibe mal genauer ansehen. Danke!


1
  •  nibepi
27.2.2020  (#263)

zitat..
ChrisTartu schrieb: /reg/raw vs /reg:
So far all my value and raw values were exactly the same, even for "text" registers
Here is an example, that does not seem to use translation/formatting.
nibe/modbus/41929 NORMAL
nibe/modbus/41929/raw NORMAL
Anyway, knowing this, I will switch to using /raw for my following logic-nodes and db entries

Thank you, you find a bug, that will be resolved in an update.

zitat..
ChrisTartu schrieb: Great pointers to the energy registers. That allows for very detailed power usage information.
Unfortuntately, I get read timeouts for those registers. Maybe not supported for F1155?

I see now that they are not supported, cant find anything else.

zitat..
ChrisTartu schrieb: The amp registers are always at 0 on my system, but I thought those are used to measure the main house connection power usage to automated safety power usage reduction?!

They are used for that purpose, so they are not connected in your case.
 

zitat..
ChrisTartu schrieb: Fredrik, it is a bit unclear, how you define "activated functions". At what point do they become activated? 
- if there is a config some? 
- if certain nodes are present in a flow?
- if these nodes are used by sending msgs to them?

Sorry, I thought that you ran the full NibePi solution which comes with an complicated flows.json file.
The nodes are very bad documented unfortunally. Here is the example flows.json file
https://github.com/anerdins/nibepi-flow/blob/master/flows.json
They can be considered activated when they are put on to the flow. I have not updated the options in the node yet to allow configuration of everything that NibePi dashboard does.
The input of the nodes is for manual update, most of them update every 5 minute and outputs data, a lot of things happend under the hood too, it changes the curveadjustment. If you send any payload on the topic "update" it will make an update.
I need to take some time to document the nodes, right now my focus is on the whole NibePi project which has an own Node-RED dashboard. You should try the flow I posted above and take a look.


1
  •  JanRi
  •   Gold-Award
27.2.2020  (#264)

zitat..
nibepi schrieb: I see now that they are not supported, cant find anything else.

 Here we go for 1x55:

Simply search for "Heat Meter" in F1155.json and you will find them all emoji

Compressor only: 44308, but there are several others for hot water, add heat and so on.

There are also registers for current compressor power and inverter power but so far I did not understand them. I can read them but so far I have not figured out how to interpret them.

Overall, F115.json is really interesting emoji


1
  •  ChrisTartu
28.2.2020  (#265)
Jan,

the heat meters are no option yet, because the system does not contain the EMK3x0 sensor to measure the water flow. It is configured to be present and therefore the minimum flow of 5l/min is used for the heat calculations.
Imagine my shock when I first calculated the COPs being around 1.3-1.5, but with actual flow speeds of >20l/min the numbers look much better emoji
Will have a look at the json anyway. Thx.


1
  •  ChrisTartu
28.2.2020  (#266)
Having said that, I can still use the values to calculate the relative power usage: heating vs hot water.

1
  •  ChrisTartu
1.3.2020  (#267)
I just ran into a wierd bug.

Using the output node I tried to set the curve parallel adjustment (40872) register.
The write request failed and the plugin did some kind of internal shutdown repeatingly printing the following messages to the log (not debug tab).

Heatpump Series: fSeries
Shutting down the core.
Heatpump Series: fSeries
Shutting down the core.

I restarted nodered and all communication failed and the heat pump went into Alarm mode.

Turns out that something during the internal shutdown caused a (partial) reset of the config node. The name was still showing /dev/ttyUSB0 which is the correct usb device for my RS485 USB stick, but the settings internally got reset to the initial /dev/ttyAMAO and also the modbus server settings were reset.

Obviously using those wrong connection details the communication could not work. After fixing them the system is back to normal.

The problem is repeatable.

Fredrik, how should we report those kind of bugs?



1
  •  nibepi
2.3.2020  (#268)

zitat..
ChrisTartu schrieb: I just ran into a wierd bug.

Using the output node I tried to set the curve parallel adjustment (40872) register.
The write request failed and the plugin did some kind of internal shutdown repeatingly printing the following messages to the log (not debug tab).

Heatpump Series: fSeries
Shutting down the core.
Heatpump Series: fSeries
Shutting down the core.

I restarted nodered and all communication failed and the heat pump went into Alarm mode.

Turns out that something during the internal shutdown caused a (partial) reset of the config node. The name was still showing /dev/ttyUSB0 which is the correct usb device for my RS485 USB stick, but the settings internally got reset to the initial /dev/ttyAMAO and also the modbus server settings were reset.

Obviously using those wrong connection details the communication could not work. After fixing them the system is back to normal.

The problem is repeatable.

Fredrik, how should we report those kind of bugs?

 I can reproduce the error too, thank you for finding that bug.
You can start issues under my github. I have two different gits, one for the core (nibepi), one for node-red nodes.
This problem is related to the core, but you cannot know that so you can post too either one.
https://github.com/anerdins/nibepi
https://github.com/anerdins/node-red-contrib-nibepi
I will look into this right away.
And it terminated because that's not a writeable register.


1
  •  chrismo
  •   Gold-Award
9.3.2020  (#269)
Ich hatte heuer zwei Modbus-Alarme. Nach Ab-/Anstecken bzw. Herumdrücken auf meinem DIY Modbus Modul ging es wieder. Wahrscheinlich eine kalte Lötstelle o.ä. bei einem Pin. Da ich keine Lust hatte, da jetzt nochmal die Löststellen zu kontrollieren, habe ich mir ein Prodino-Modul gekauft, das schon die Ethernet- bzw. Modbus-Schnittstelle integriert hat: https://kmpelectronics.eu/products/prodino-mkr-zero-ethernet-v1/

Das Board macht einen sehr guten Eindruck und ist qualitativ sicher mit dem offiziellen Nibe Modbus 40 Modul gleichwertig. Preis ca. 70 Eur inkl. Versand.

Eine ältere Version vom Prodino wird bereits von NibeGW unterstützt. Es waren aber ein paar kleine Anpassungen am Arduino Code nötig, da die neue Version nicht mehr auf einem Arduino Leonardo, sondern auf einem Arduino MKR basiert. Falls wer Interesse hat, kann ich gerne den Code schicken bzw. werde ich die Anpassungen an den NibeGW Maintainer weiterleiten, damit sie evt. ins openHAB Repository aufgenommen werden.


2020/20200309394217.jpg

1 

2
  • ▾ Anzeige
    Energiesparhaus.at ist Teilnehmer des Amazon-Partnerprogramms, das zur Bereitstellung eines Mediums für Webseiten konzipiert wurde, mittels dessen durch die Platzierung von Partner-Links zu Amazon.de Entgelte verdient werden können.
Hallo chrismo,
hier gibt es dazu Erfahrungen und Preise: DIY Alternative zu Nibe Modbus Modul

  •  moef
  •   Gold-Award
10.3.2020  (#270)
@­chrismo
toll
bin in der materie nicht so tief drinnen, aber ich kriege so basteleien immer früher oder später auf die reihe.
Interesse ist groß.
Kannst du so nett sein und kurz zusammen fassen, was man benötigt? Hardware, Software, Anpassungen, etc.

1
  •  uzi10
  •   Gold-Award
10.3.2020  (#271)
Ja bitte um Zusendung.. ich sammel mal alles

1
  •  chrismo
  •   Gold-Award
11.3.2020  (#272)
@moef
@uzi10

Ich habe Dateien hier hochgeladen: https://bitbucket.org/crnv/nibegw-prodinomkr/src/master/

1
  •  OpiVanKnobi
22.3.2020  (#273)
Danke @chrismo! Ich hatte mir, inspiriert vom NibeGW, bereits vor über einem Jahr einen ProDino MKR Zero Ethernet bestellt, das "Hello World" installiert, und seit dem liegt er hier auf dem Schreibtisch. :/

Mein Ziel ist es, direkt auf dem Arduino RS485→MQTT zu machen, also den Umweg über UDP einzusparen. Meine Stromzähler werden schon per RS485/Modbus ausgelesen und publishen auf MQTT, das alles landet in OpenHAB, welches alle 15s in InfluxDB schreibt und dann entweder Werte im Dashboard anzeigt, oder per Grafana einbindet.

Also das übliche Setup :). Auf NodeRed und einen weitere RPi will ich dann verzichten. Der Arduino sollte auch mit dem 12V der WPWP [Wärmepumpe] klarkommen, also kein weiteres Netzteil nötig. (Ich befürchte das Ethernet braucht zuviel Strom, mit Wifi wäre es sparsamer ...)

Mit den zusätzlichen Relais am ProDino dachte ich dann die SG ready Eingänge der WPWP [Wärmepumpe] anzusteuern, aber nach dem Lesen des Handbuch ist die Beeinflussung ja eher mau, und für eine modulierende WPWP [Wärmepumpe] nicht so dolle.

Ist jetzt offtopic, aber gibt es einen guten Thread, welcher Möglichkeiten für PV-Überschuss aufzeigt? Ich wollte mit einfachen Regeln starten:
- wenn PV-Überschuss von ca. 400W → Heizkurve +1 verschieben
- wenn PV <400W (also nachts) UND für den nächsten Tag wird Sonnenschein prognostiziert: HK -1
- sonst: HK-Verschiebung auf 0 belassen (unser Haus ist sehr träge)

Jetzt hatte @JanRi aber ja den berechtigten Einwand, dass die Schreibzyklen sicherlich limitiert sind. Also sollte man sowas wohl lieber mittels BT50-Input verbiegen?

Noch haben wir keine PV -- sollte im April installiert werden, aber dank Covid19 gibt es natürlich kein Material :/. Irgendwann in der nächsten Heizperiode habe ich dann sicherlich den Arduino am Laufen und kann hoffentlich damit spielen (und habe keine Löcher mehr in der Aufzeichnung, weil mal wieder nibeuplink.com spinnt).

@­chrismo, meinst du der Arduino hat genug Rechenpower um direkt in MQTT zu schreiben?

An alle: welche Spielereien könnte man sonst noch mittels diverser Relais machen?

1
  •  chrismo
  •   Gold-Award
22.3.2020  (#274)

zitat..
OpiVanKnobi schrieb: @chrismo, meinst du der Arduino hat genug Rechenpower um direkt in MQTT zu schreiben?

IO also auch Netzwerk dauert ja Monate in µC-Zeit gesehen, das ist sicher kein Problem. Es gibt auch MQTT Libs für Arduino. ABER: wahrscheinlich ist der SRAM das Limit. Du müsstest die ganzen Register im Speicher ablegen, damit du die notwendigen IDs bzw. auch Wertebereiche der Register hast (siehe Inhalt in [1]). Ich glaube das geht sich nicht aus. Außer du schränkst hier schon auf die wichtigsten Register ein. Wäre dann halt sehr unflexiblel, wenn man den Arduino neu programmieren muss, um ein neues Register einzulesen.

zitat..
OpiVanKnobi schrieb: das alles landet in OpenHAB, welches alle 15s in InfluxDB schreibt und dann entweder Werte im Dashboard anzeigt, oder per Grafana einbindet.


Wenn openHAB eh schon läuft, wieso dann nicht dort das NibeBinding/Node-RED installieren? Braucht ja dann keinen extra RasPi.

Noch was anderes: Ich war mit dem Entwickler des Prodino in Kontakt, da ich Ethernet2 statt Ethernet verwenden musste. Mit Ethernet kam bei mir nur "Müll" an. Auch die mitgelieferten UDP Bsp. gingen bei mir nicht. Der Entwickler konnte das Problem nicht reproduzieren. Hast du UDP Kommunikation mit dem PRodino MKR mal getestet, z.B. UDPRelay? Ich habe Bsp. Code [2] der alle Sekunden die Bytefolge "5c 00 20" sendet. Bei mir kommen da aber zufällige Bytes an. Falls du mal Zeit hast, wäre es super, wenn du den Bsp Code mal auf den Prodino laden und schauen könntest (mit Wireshark, o.ä.), was gesendet wird.

[1] https://github.com/openhab/openhab-addons/blob/2.5.x/bundles/org.openhab.binding.nibeheatpump/src/main/java/org/openhab/binding/nibeheatpump/internal/models/F1X55.java)

[2] https://bitbucket.org/crnv/nibegw-prodinomkr/src/master/udptest.ino


1
  •  OpiVanKnobi
28.3.2020  (#275)
Ja, also die mitgelieferten UDPRelay und UDPInput funzen einwandfrei, aber dein Code wirft in der Tat nur Müll raus:


4,0}vO$a@RM *َm'')RL$\P^[*vq?z<ucRҡ+xnH!^M?y;dF+3p~c%!4q?%]#Mb<p



17:31:25.695230 IP 192.168.0.198.1111 > 192.168.0.151.12345: UDP, length 3
0x0000: 4500 001f 0036 4000 8011 77ea c0a8 00c6 E....6@...w.....
0x0010: c0a8 0097 0457 3039 000b d877 2b22 4500 .....W09...w+"E.
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
17:31:26.695451 IP 192.168.0.198.1111 > 192.168.0.151.12345: UDP, length 3
0x0000: 4500 001f 0037 4000 8011 77e9 c0a8 00c6 E....7@...w.....
0x0010: c0a8 0097 0457 3039 000b 374a c94f 4800 .....W09..7J.OH.
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
17:31:27.695943 IP 192.168.0.198.1111 > 192.168.0.151.12345: UDP, length 3
0x0000: 4500 001f 0038 4000 8011 77e8 c0a8 00c6 E....8@...w.....
0x0010: c0a8 0097 0457 3039 000b 72f7 23a2 b200 .....W09..r.#...
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............


Der Fix is ganz einfach: _udp anstelle von udp zu verwenden. Ich verstehe nicht ganz, warum du 2 Instanzen von EthernetUDP haben willst. Ist ja kein TCP-Socket. Aber ich habe genau 0 Erfahrung mit Arduinos.

Mit diesem Loop hier läufts:

void loop()
{
long now = millis();
if (now - lastUpdate > 1000) {
lastUpdate = now;
byte testdata[] = {0x5c,0x00,0x20};
//unsigned char testdata[] = "ack";
//sendUdpPacket(testdata,3);
_udp.beginPacket(targetIp, TARGET_PORT);
_udp.write(testdata, 3);
_udp.endPacket();
#ifdef DEBUG
Serial.println(">> Sent data.");
#endif
}
}




% nc -lu 12345
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ ^C


1
  •  chrismo
  •   Gold-Award
28.3.2020  (#276)

zitat..
OpiVanKnobi schrieb: Ich verstehe nicht ganz, warum du 2 Instanzen von EthernetUDP haben willst. Ist ja kein TCP-Socket.

Das war so von NibeGW übernommen. Eine Instanz für Versenden von Paketen (udp=Client) und einmal für das Empfangen (_udp=Server).

In NibeGW wird dann _nur_ der Server mit der Methode _udp.begin(PORT) initialisiert. Der Client wird zuerst nicht initialisiert. Vor Versand eines Pakets wird udp.beginPacket(TARGET_IP, TARGET_PORT) gemacht.

Nach deinem Hinweis, habe ich mal versucht auch den Client mit udp.begin(TARGET_PORT) zu initialisieren und danach ging es! Sowohl mein Bsp. Code als vor allem auch NibeGW.

Interessanterweise, braucht man beim Arduino Uno bzw. dem W5100 das begin() bei einem Client nicht aufzurufen. Ist im Original NibeGW Code [1] nirgends gemacht. Bin auch kein Arduino Experte, daher keine Ahnung was da jetzt beim MKR bzw. W5500 Ethernet Chip anders ist. Aber das Problem ist ja jetzt gelöst. Danke für den Test und deinen Hinweis!

[1] https://github.com/openhab/openhab-addons/blob/2.5.x/bundles/org.openhab.binding.nibeheatpump/contrib/NibeGW/Arduino/NibeGW/NibeGW.ino




1
  •  jaydee73
15.4.2020  (#277)
@nibepi : Can you give us a quick update about the current state of your 1.1 development? I've seen several different repositories in your Github-Account, one of them indicates that there also will be a complete plugin/flow for a node-red installation. Is this correct? So no need to have a dedicated pi for your plugin?

1
  •  klayman
16.4.2020  (#278)
Hallo,

kurze Frage an die OpenHab Nutzer: Wie sieht denn Eure nibe.items Datei aus, i.e. wie habt Ihr ein Item konfiguriert? Die Binding Doku hat hierzu kein Beispiel und mit OH2 kamen ja die Channels dazu... Meine nibe.things sieht so aus:

nibeheatpump:f1x55-udp:myNibe [hostName="192.168.178.150", port=9999]

Ein Beispielitem (welches aber nicht funktioniert)  so:

Number OutdoorTemp "Outdoor temperature [%.1f °C]" {channel="nibeheatpump:f1x55-udp:myNibe:40004"}


Danke,
Klayman

1
  •  chrismo
  •   Gold-Award
16.4.2020  (#279)
meine nibe.things:

nibeheatpump:f1x55-udp:nibe1155 [
hostName="10.0.0.122",
port=9999,
readCommandsPort=10000,
writeCommandsPort=10001,
refreshInterval=30,
enableReadCommands=true,
enableWriteCommands=false,
enableWriteCommandsToRegisters="48132"
]

Ich glaube das meiste ist optional, deine Thing-Definition müsste auch funktionieren.

Ein Eintrag aus der nibe.items:

Number:Temperature nibe_sensor_BT1OutdoorTemp "BT1 Außentemperatur [%.1f °C]" <temperature> (gNibeTemp) { channel="nibeheatpump:f1x55-udp:nibe1155:sensor#40004"}

zitat..
klayman schrieb: Ein Beispielitem (welches aber nicht funktioniert) so


Auf ersten Blick würde ich meinen, dass beim Channel ein "sensor#40004" statt "40004" hin gehört.

Bei Registern, die man auch schreiben kann, anstelle von "sensor" dann "setting" verwenden (auch wenn man dieses nicht schreibt), z.B.:

Number:Dimensionless nibe_setting_DegreeMinutes "Gradminuten [%.1f]" (gNibePump) { channel="nibeheatpump:f1x55-udp:nibe1155:setting#43005"}

1
  •  klayman
16.4.2020  (#280)
Ah ja, danke. Das sensor und setting hatte gefehlt. Danke!!

1
  •  klayman
17.4.2020  (#281)
Noch ne Frage: Bekommt Ihr Werte für Brine Pump Speed (47418) und Supply Pump Speed (47437) bei der F1255-6? Und welche Register fragt Ihr für den Wärmemengenzähler ab? Für Warmwasser Comp.+Add. nehme ich Register 44298, was mit ca. 3.500 kWh auch plausibel aussieht. Aber für die Gesamtheizleistung inkl. WW bei Register 44300 bekomme ich nur ca. 420 kWh - das passt nicht zusammen. Die WPWP [Wärmepumpe] ist jetzt gut 2.5 Jahre in Betrieb, das waren sicher mehr als 420 kWh Heizenergie emoji

1


Beitrag schreiben oder Werbung ausblenden?
Einloggen
 Kostenlos registrieren [Mehr Infos]


next