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 great, thank you! So the base image either does the modbus communication ("serial"), or the udp based communication with nibegw and then forwards everything to the configured broker...? Some questions (just to get it right.. ;) - is there still an embedded broker started if no external is provided? - advantage of nibeGW: if the base image application is not running, the handshakes towards the nibe are correctly handled (no errors..)..? - advantage of the base imae app: no further rpi/arduino needed (but of course the modbus adapter), but the app has to be running all the time (or how does the nibe react if there if no one responds)? - any dependencies to nodered in the base image? - docker compose only needed for the things mentioned (host network, volumes, serial device,...), or is there another reason for its requirement? Regards |
||
|
||
|
That is correct. No, there is not, you need to run a external broker aside. Or in the same docker-compose... Yes, the nibegw will still ACK all the messages and keep the heatpump happy with no red lights. When the base image wakes up again it will just catch up the communication again. If you go with the serial method (or nibegw running on the same hardware) you only need one set of hardware. This is basically what the NibePi image does, without the docker. If the app shuts off (and is running serial) the heatpump will go into red alarm and probably shut off the heat and hotwater if you have that configured for "red light incidents". No, NodeRED is not inside the base image. It's just a Node image running a script (NibePi core). And that script forwards everything to MQTT. Actually docker-compose is not needed. But my example is written in docker-compose. You can run the docker image with a regular "docker run" command, with volumes, serial, network=host, etc configured in that "one line command" My next step in the docker universe will be to build the whole NibePi experience into a docker image. Containing both the frontend and the backed. Running on a NodeRED docker base image. The biggest advantage now is that many people are running Arduinos with NibeGW or other devices running NibeGW, now a simple docker image can catch that UDP traffic and forward that to MQTT. Not only Openhab that NibeGW is built for. |
||
|
||
|
Great, thanks for all the effort and the detailed explainations! |
||
|
||
|
Versteh ich nicht, in meiner Anleitung sind es nur wenige Schritte bis zu einer funktionierenden Fernsteuerung. Die Kosten belaufen sich auf ~50€ (RaspPi, RS485, Netzteil). Wenn man schon mal einen Raspberry benutzt hat sind es wenige Minuten bis es läuft, wenn man 0 Plan von Linux hat muss man sich paar Minuten einlesen. Den ganzen Docker Kram verstehe ich auch nicht, was soll das bringen ? Läuft doch perfekt. Genauso Androino und NibeGW - was soll man damit ? Wo ist der Nutzen ? NodeRED bietet alles was man braucht. Verwirrte Grüße P.S. hier mal alle meine Dashboards in einem Bild:  Verlauf fehlt, den reiche ich nach. (VLT,RLT,Hz,AT,GM,KT,therm.Leistung).
|
||
|
||
|
Wurde hier eh schon diskutiert. Erstens gibt es NibeGW deutlich länger, war also früher einzige Option und wer openHAB hat, für den ist es sowieso die "natürliche" Variante. Und der Arduino setzt die Wahrscheinlichkeit, dass die WPWP [Wärmepumpe] in den Alarmmodus geht auf praktisch 0, weil Bestätigung quasi in Hardware und nicht Software gelöst ist. |
||
|
||
ahso d.h. wenn der neu gestartet wird gibt es keinen Alarm ?    |
||
|
||
|
Der Arduino startet in <1s und somit innerhalb des Timeouts für die Bestätigung eines Pakets der WPWP [Wärmepumpe]. Außerdem läuft auf dem Arduino nur NibeGW und sonst gar nichts. Einzige Fehlerquelle ist ein Hardware-Defekt. Dagegen hängt beim Pi viel von Software ab (OS, Docker, JavaScript Runtime,...), was grundsätzlich mehr Fehlerquellen bedeutet. Außerdem braucht ein Neustart länger als das Timeout der WPWP [Wärmepumpe], die dann in den Alarmmodus geht. Als Gegenmaßnahme wird bei NibePi der Alarm zurückgesetzt. Außerdem wird der Schreibzugriff auf die SD Karte deaktiviert, was deren Lebensdauer massiv erhöht. Die Langzeiterfahrung wird zeigen, wie oft was beim Pi passiert, der Arduino ist mMn aber so stabil wie das originale Modbus40 Modul. |
||
|
||
|
Danke, dachte dass wäre das gleiche in wie ein RPi 😇 |
||
|
||
|
Some german and english translations has been added by Mr Seppel. NibePi is now approximally 80% translated to english and german. For those who are running NibePi 1.1 beta, and updated from 1.0.6 imagefile can update to the latest snapshot including the translation with command. So to get the german version of NibePi, the way now is to download the 1.0.6 image, update to 1.1 beta from the interface, then run the above command in SSH terminal. |
||
|
||
|
Hallo, Sie haben Recht. Meine Frage : was ist der Nutzen (RaspPi, RS485, usw.) für eine KWL KWL [Kontrollierte Wohnraumlüftung] ... zum Beispiel ? Zumal die KWL KWL [Kontrollierte Wohnraumlüftung]-Sensoren (Temperatur- und andere Sensoren) oft falsch sind ! Im Jahr 2020, was mehr mit RaspPi, RS485 im Vergleich zu der Smartphone-API des Herstellers? Grüße, Pierre |
||
|
||
|
Es geht hier um eine WPWP [Wärmepumpe]-Heizung und nicht um eine KWL KWL [Kontrollierte Wohnraumlüftung] 👀 Meine KWL KWL [Kontrollierte Wohnraumlüftung] hängt an einer Funksteckdose, die mache ich ein oder aus. |
||
|
||
|
Im Prinzip gilt das gleiche auch für eine KWL KWL [Kontrollierte Wohnraumlüftung], aber bleiben wir bei der WPWP [Wärmepumpe]. Die hier beschriebenen Lösungen sind eine Alternative zun Nibe Uplink, dessen Vorteile hier beschrieben werden: https://www.knv.at/nibe-uplink/ Also Überwachung und Steuerung der Wärmepumpe, erstellen von Visualisierungen, speichern historischer Informationen. |
||
|
||
|
vor allem das Smartphone API kostet viel Geld und funktioniert oft nicht und langsam bzw verzögert... direkter Zugriff ist besser |
||
|
||
|
Es kommt natürlich immer auf die Anforderungen darauf an Für mich ist z.B. Smarthome Integration ein Thema Für die KWL KWL [Kontrollierte Wohnraumlüftung] habe ich z. B. einen EWT bei dem ich die Regeleinheit selber gebaut habe, hier sind die Daten aus der KWL KWL [Kontrollierte Wohnraumlüftung] ganz nützlich Auserdem lasse ich das Ding z.B. nur auf Stufe 1 laufem wenn keiner zuhause ist (und noch ein paar andere Logiken) Auserdem finde ich Statistiken zum optimieren und zur Fehlersuche super Auch habe ich Wolken nicht besonders gern, finde die Daten der Haustechnik sollten im Haus bleiben |
||
|
||
|
Ich habe zur Nibe zur Wärmepumpe noch ein KWL KWL [Kontrollierte Wohnraumlüftung]. Dort gibt es eine Umluftklappe die bei bestimmten Temperatureinstellungen 40902 den Wärmetauscher überbrückt. Ich kann es hören wenn die Klappe in die andere Stellung gefahren wird. Mit welchem Wert bekomme ich die Klappenstellung zurückgemeldet? 48970 i(Outdoor Air Mixing) st immer 1 und 43096 (Mixing Valve State) ist immer 0 Hartmut |
||
|
||
|
Neben allem, was schon gesagt wurde: Diese Lösung ist vor allem auch dann interessant, wenn man schon irgendeine Art von Server zu laufen hat, z.B. einen PC, eine VM, einen eingebetteten Server oder was auch immer. Damit kann man dann die WPWP [Wärmepumpe]-Seite von der Serverseite komplett entkoppeln. Das Setting NibeGW auf Arduino schickt per UDP an RPi, der dann nur NibePi macht, ist natürlich ziemlich sinnfrei. Dann kann der RPi das auch alleine. Das Setting Arduino (oder ein ganz kleiner oder alter RPi) senden per NibeGW und UDP an einen Server ganz woanders hingegen ist sehr wohl sinnvoll (wenn der Server eh schon da ist für andere Zwecke). Letzteres läuft bei mir (mit selbst gebauter Serverseite, also nicht NibePi, sondern einem eigenen UDP-"Empfänger") seit Dezember im problemlosen Dauereinsatz. |
||
|
||
|
Moin, ich habe mir NibePi auf einem Pi Zero installiert und das läuft anscheinend soweit auch, zumindest sieht es in dem Webinterface ganz gut aus 😬 Danke schon mal dafür @nibepi 👍  Nun wollte ich das ganze in Openhab per mqtt einbinden und da habe ich so meine Probleme 😌 Das Mqtt Binding ist installiert und auch die IP vom NibePi ist im MQTT Broker Nibe eingetragen.  Dann habe ich ein Generic MQTT Thing angelegt und dort einen Channel erstellt   Aber in Openhab kommt nichts an  Was habe ich falsch gemacht ? Muss ich noch etwas bei diesem NodeRed machen ? LG Jörg |
||
|
||
|
Have you read Beckers guide? http://hausbau-becker.blogspot.com/2020/06/it-fachartikel-fernsteuerung-nibe.html You also need to activate the MQTT broker in the node configuration. And you should not specify a command topic on a regular sensor (40004), and if you specify a command topic it should look like nibe/modbus/47265/set
|
||
|
||
Yes, I have read Beckers Guide and the NibePi is running, which you can see here  In the picture in the coment it says the brooker runs under localhost:1883 So do I have to activate it ? |
||
|
||
|
https://imgbb.com/5sxxf4n Basically you can doubleclick a NibePi node, new window appears, click the pen next to "Server" this will open up the basic NibePi configuration, make sure the Use Mosquitto broker is checked. |
||
|
||
MQTT was already running and on my openhab server I can see that it connects .....  But I can´t get any data... |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]