Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
|
|
||
|
Sounds good! Thanks for the great work. Do you plan to publish a version which can be installed onto an already existing pi environment? I have a running installation of a Rpi3 with the latest Raspbian Buster OS as a pi-hole dns-service. I would like to "add" your nibepi to this, so a complete image would kill my pi-hole environment. |
||
|
||
|
@nibepi : Thank you for the information. With your hits I think I got the software part running. I just have to set up the hardware now and test the system. |
||
|
||
|
Hello, I have a NIBE VVM500 with Fighter F2120 air heat pump. Will NibePi also work with this setup? I didn't find the F2120 mentioned any (it is also not mentioned in the nibegw topic). Thanks for help. |
||
|
||
|
VVM500 with the F2120 is supported with 870 registers at your disposal :) |
||
|
||
|
I also got the hardware (RPi 3B+ with USB-RS485 converter) connected. In the NibePi UI I already receive some values. So this part looks good. As I am new to MQTT I am still struggling with that. My setup will be: NIBE F1155 <Modbus> NipePi <-MQTT-> loxberry(running on separate RPi) <-http or UDP-> Loxone Smart Home So far I could not manage to establish data transfer with MQTT. I have the possibilities to have the broker running directly on NipePi or external on the loxberry (Mosquito broker). My questions are: - Is it better to use the internal or an external broker? - MQTT subscriptions are like "nibe/modbus/40004" right? - Which usernames/credentials are required - Are there any settings in the router (port forward etc.) required for MQTT? - What would be a simple way to monitor MQTT data traffic? - Is it ok to have the RMU (room terminal) connected in parallel to the NibePi? |
||
|
||
|
I would go with the internal broker, I imagine it's more stable that way. You're right with the subscriptions, that can be set up in the nibepi interface under settings. For the internal broker there is no username or password and it uses the standard 1883 port. If you are just using it in a normal home network no port forwarding should be necessary, if you want to access nibepi from outside your home i recommend an external broker with auth. You can use a program called MQTT Explorer to monitor the traffic, under nibepis interface you can se graphs and values also. RMU40 is no problem to run parallell with NibePi, actually NibePi can simulate an own RMU to get additional functions over mqtt, such as forcing hotwater or fan speed for a certain time. NibePi decrypts your RMU values and sends it out on MQTT. Outdoor, indoor, hotwater temps for an example. I'm sorry for the almost non-existing translation of NibePi and the lack of basic information about how it works, I havent gotten to that part yet.
|
||
|
||
|
Thank you again I for your comprehensive answer. I will try your suggestions. I am sure I will get it running. RMU 40 is connected and the values (e.g. room temperature) is shown in the graph. I will use the simulated RMU 40 for forcing hot water. I hope that will work. At least according to the Nibe installation guide two RMUs shall be fine. Dont worry about any missing translations. We are very thankful here to have you in our community. You put really a lot of afford in this project. At it it something really simple and useful. And some basic RPi coding and MQTT basics can be done/learned by every user by himself (this is especially true for me, as I still have to learn a lot ). Thank you for any kind of support for this project! |
||
|
||
|
It will work with two or even more virtual RMU, Nibe is only concerned about the electrical consumption of RMUs so a virtual one is no problem. Yes I plan to release one, the flows can just be imported to a nodered instance. But a tutorial needs to be made for that to simplify it.
|
||
|
||
|
Hi! I connected the nibepi the first time to my Nibe F1255-6. Installed 1.0.6 and then updated to 1.1 I run it on a Raspberry-Pi 3 with an USB-Converter. When I activate the Modbus module in the Nibe-configuration-menu, i get an alarm that there's a communication problem to Modbus. Does anyone have this problem too? Could it be a problem that my cable from the usb-converter to my Heatpump is about 5 meters? |
||
|
||
|
Have you change the interface to "/dev/ttyUSB0" (or 1 if you have another serial USB converter)? That SHOULD work. For testing, I would try it with a shorter cable. For me, everything runs perfect (with NibeGW, not NibePi, but this should not matter) with appr. 2 meter of cable (left over KNX cable). |
||
|
||
|
Thanks for your answer. Tried it with a shorter cable, and it works now... Next I'll buy a RPi-zero, so that i can power it from the heatpump and integrate it. br |
||
|
||
|
Did you try to reset the alarm? Sometimes the start-up reset dosent work. And the cable needs to be a twisted cable. |
||
|
||
|
thanks, but the problem was the cable. with another cable it works... |
||
|
||
|
I have my RPi connected to the heatpump via a ~8 meter cable (2 wires of a CAT 5 cable, twisted, shield still on) and it works stable. But as I stated up this stetting the first time, I also got an modbus error. After a restart, the error never came back and I did not see any problem since a few days. |
||
|
||
|
Hi guys! I have been following this project for quite a while and finally got around to install the NibePi1.1beta release yesterday. I have a Nibe F1155-12-EXP (not sure what the EXP means - maybe eastern european market - I live in Tartu/Estonia) connected to an RPI4 (4GB) using an "old" RS485 adapter I still had my "toys" box. The NodeRed installation runs in a docker container for which I have used this project (https://github.com/gcgarner/IOTstack) to setup the initial Docker Compose file. After a short hickup (maybe I had mixed up A/B lines , it works rock solid so far. My main goal is to understand the heat pump better, but also to improve its functionality. A) smart energy only uses the hourly electricity price but does not seem to know about the network price which also changes over time (night time/weekends). Since this is a large percentage (almost 50%) of the total price I would like to push better price information (also includes ALL taxes) to the NIBE. B) We have floor heating in our house and I would like to use the weather forecast to activate higher temperatures (6h-12h?) before the colder outside temperatures actually hit. C) maybe more... I have noticed a few things: There are a number of registers being posted to MQTT in intervals (once per minute?) is this list of registers defined? I can force reading a register using the nibe-request node. The response is also updated to MQTT for this register. 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. Which register is best used to determine if the heat pump is in "hot water" or heating mode? 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. Anyway, I have several decades of software development experience, so if I can help, let me know. My native language is german, but I am writing this in English so that everyone (espcially Fredrik) can follow. Meine Muttersprache ist übrigens Deutsch |
||
|
||
|
Wäre mir lieber wenn das alle hier sprechen |
||
|
||
|
Der Autor von NibePi kann aber kein deutsch... von daher ist Englisch eigentlich netter. Er schrieb aber mal, dass er Google Translate verwendet. Ich antworte mal zur Abwechslung in deutsch zu c): Die Liste der vordefinierten Register kann man mit dem Modbus-Setup-Utility definieren. Das findet man mit ein bisschen suchen bei Nibe im Netz (NIBE ModbusManager). Wenn man das startet, kann man diese Register definieren. Dabei entsteht eine Datei namens LOG.SET. Die kommt auf einen USB-Stick und den steckt man rein. Fertig, der Stick kann dann wieder raus. Ganz genau ist die Vorgehensweise im Manual für das Modbus 40 Modul beschrieben - kann man bei Nibe runterladen. Diese Register werden alle 2 Sekunden automatisch von der WPWP [Wärmepumpe] gesendet! Alle anderen muss man abfragen und bekommt es dann innerhalb von zwei Sekunden. Bei mir stehen darum da die wichtigsten Register drin. Diese Nachricht kann 20 16-Bit-Register enthalten, mehr lässt das Tool auch nicht zu. Wenn man 32-Bit-Register drin hat, dann verliert man entsprechend Register (also man hat nur noch 19 Register, wenn ein 32er dabei ist usw.). Alles, was so ankommt (angefordert wie auch aus LOG.SET) sendet NibePi dann auf MQTT. An der Relais-Stellung (Register 43514). 2 ist Standby, 7 ist heizen und 15 ist Warmwasser. Ganz genau ist es so: 1 Solepumpe 2 Heizungspumpe 4 Kompressor 8 WW WW [Warmwasser]-Umschaltventil. Nun aufaddieren und fertig. Bei WW WW [Warmwasser] sind alle 4 aktiv, beim Heizen nur die ersten drei. Ist also schlicht binär codiert. Mache ich auch. Mein Energieauslesescript postet einfach die Werte ebenfalls per MQTT auf entsprechende Themen. Der Logger abonniert dann die WPWP [Wärmepumpe]-Kanäle und die vom Energieauslesescript und packt beides zusammen ins Log. Das klappt mit meiner Lösung NibeGW->UDP2MQTT ganz prima und sollte es direkt mit NibePi (meins ist vom MQTT-Interface her kompatibel sein) auch gehen. Ansonsten: VORSICHT! Es ist immer noch unklar, wie oft man auf Register schreiben kann, ehe man den Flash oder ein EEPROM tötet (siehe entsprechender Thread).
|
||
|
||
|
Bin schon gespannt ob die nibepi 1.1 dann fehlerfrei und auch mit externen broker läuft... Das mit den Flash hat noch keiner rausgefunden? Auch die Schweden nicht? |
||
|
||
|
Warum sollte sie das nicht tun? Die Fehler haben wir ja weiter vorne im Thread alle ausgemerzt. Ich nutze zwar NibeGW zum Abfragen der Daten, aber mein Decoder basiert ausschliesslich auf dem, was hier im Thread gepostet wurde. Läuft seit Anfang Dezember im Dauerbetrieb ohne jedes Problem. Externer Broker ist letztlich nur eine Zeile Konfiguration. Bei mir ist aktuell alles extern... der Pi ballert die Daten per UDP raus, ein Programm auf dem Server fängt sie auf und veröffentlicht sie per MQTT (Broker läuft auf dem Server). Der Logger (auch auf dem Server) abonniert sie dann und alles ist fein. Ich glaube, die ignorieren das. Die Idee von NibePi, zu Beeinflussungszwecken ein RMU zu simulieren, das dann passend manipulierte Innentemperaturwerte sendet, umgeht das Problem aber, denn das schreibt ja nicht auf den Flash, sondern ist für die Nibe dann nur ein anderer Sensor. Wenn ich mehr Zeit habe, will ich sowas auch mal versuchen. Ich würde dann per Modbus den BT50 auslesen, manipulieren und das dann als RMU-Innentemperatur zurücksenden und da dann den Inneneinfluss dranhängen. Damit sollte man ohne Flash-Schreibvorgänge die VL VL [Vorlauf]-Soll-Temperatur beeinflussen können. |
||
|
||
|
Hi there and thank you for the coffee, Have you tried the built in "prognosreglering" / "Forecast automation" (TRANSLATION to english have started but I need to finish the real 1.1 version first. The forecast module only relies on SMHI (Swedish weather service) but there might be forecasts availible for your region anyhow. I'm using 6 hours on my floor heating. I would say 43086. Yes we (I) are ignoring it for now, there is a lot of time to deal with that issue. I think we are on the same path to find a workaround solution, manipulate the BT50 sensor in my virtual RMU40. If you activate the virtual RMU S1 you can post temperatures to "nibe/modbus/10060/set and it will update the 40033 with that value and use it in the heatpump, but only if the real hardwired sensor is disconnected. Another solution would be to talk to nibe just to make a new modbus register which can affect the curveadjust without saving it to the flash/eeprom. There are a lot of Nibe accesories and I guess there's a lot of nice possibilities if we can decode how they work, for example simulate a climatesystem 2 with own hardware such as sensors, electric valves. |
||
|
||
|
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. 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. 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. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]