|
|
||
ja, da hast du recht. Die nutzen auch nur das Nibegw von Openhab... Für die Nicht-Bastler ist das Projekt perfekt und scheint sehr ausgereift zu sein. Wer es günstiger mag, muss basteln und Arduino nutzen |
||
|
||
Nein falsch sie nutzen eben kein NibeGW. Die komplette Kommunikation über RS 485 im Modbus Protokoll in Richtung der Wärmepumpe und umgekehrt erfolgt direkt in der Node.js Anwendung. (im Repository die heatpump.js) Gerade was die Kommunikation schreibend in Richtung der Wärmepumpe angeht, ist die Node.js Anwendung deutlich umfangreicher und sauberer implementiert. |
||
|
||
Mich würde der Stromverbrauch der gesamten Konstruktion mal interessieren, ob es sich lohnt, trotzdem den Arduino einzusetzen. |
habe gerade nochmal reingeschaut. Jo, die gehen direkt auf den seriellen Port. Es gibt halt noch das zweite Repo, wo er noch mqtt per nibegw genutzt hatte. ||
|
||
Ich frage das mal nach. Aber ich würde fast sagen dass es mir egal wäre. (wobei ein PI Zero nicht die Welt verbraucht) Am Arduino fehlt mir die MQTT Funktionalität und da ist mir lieber, wenn ich diese kleine Install and Forget Box direkt an der Wärmepumpe habe, welche mir die Daten sauber per MQTT ins Netzwerk serviert. Update: Der PI Zero braucht nicht mehr als 1W. Ich warte noch auf gemessene Angaben, aber viel mehr wird es nicht werden. |
||
|
||
dann sollte doch klar sein, was unter dem Weihnachtsbaum liegt |
||
|
||
Definitiv ja. So wird es ein leichtes auch andere Sachen wie den Luxus Modus für Warmwasser direkt vom KNX Schalter aus zu starten ohne über Nibe Uplink gehen zu müssen. (das hat sich bei mir heute mal wieder verabschiedet) |
||
|
||
Danke denis das du die vielen Informationen für uns einholst Ich hab es auch nur zufällig über Github gefunden da ich den arduino Code gesucht habe, den habe ich wohl umsonst gekauft Für mich wäre es super da ich eh nodered für andere smarthome Schnittstellen laufen habe dann brauche ich nicht noch openhab extra, auserdem scheint auch aktiv weiterentwickelt zu werden Werde aber noch auf die v1.1 warten auch die WPWP [Wärmepumpe] es schon vertragen könnte weißt du ob nur der pi zero unterstützt wird (ich hätte noch einen alten B+ der hätte enthernet)? |
||
|
||
Hallo chrismo, hier gibt es dazu Erfahrungen und Preise: DIY Alternative zu Nibe Modbus Modul |
||
|
||
Ja uplink macht mich auch scho wahnsinnig... Mqtt is wohl das Beste Protokoll für das.. |
||
|
||
Danke für die tollen infos. Die Lösung klingt vielversprechend. Ich denke das wird kein Problem sein. Eventuell musst dir ein paar Konfigurationen (pi als read-only betreiben; andere Einstellungen bei den network-interfaces;..) selber einrichten, aber das findet man bestimmt alles online. Was mich interessiert: läuft der mqtt-broker am pi (wenn ja: welcher?) oder muss der einfach nur im netzwerk hängen? Edit: sieht für mich aus, als ob im script ein mqtt client verwendet wird, der dann auf einen lokalen broker verweist (sollte also nix dagegen sprechen, diesen wo anders zu hosten). Der broker selbst kommt glaube ich vom nodered (da dürfte standardmäßig einer mitgestartet werden).. |
||
|
||
Bin mir auch gerade nicht sicher welcher lokale verwendet wird. Ich habe nochmal nachgefragt. Wo ich aber sicher bin ist dass man auch einen externen Broker verwenden kann. Die Node.js Anwendung sucht hier erst nach Settings für einen externen Broker, wenn in der Config dafür nichts gefunden wird, dann wird der interne verwendet. Aber im Endeffekt ist es egal wo der Broker im Netzwerk sitzt. Update: Es gibt zwar ein "startExternalMQTT", wird aber soweit ich es sehen kann nicht wirklich verwendet. Aktuell geht die Anwendung hard coded auf den lokalen Broker. (siehe https://github.com/bebben88/NibePi/blob/master/nibepi/heatpump_1.0.6.js#L768) Update 2: Hier die Antwort vom Macher. "the image file holds a own mosquitto broker. The heatpump.js communicates with the nodered Interface with mqtt. Its also possible to use an external broker. But the internal is mandatory for heatpump.js to work at all. But all this will be changed in 1.1. There will be possible to use internal or external broker in 1.1 but all the scripts will be a part of the node red node." Es wird also mit der nächsten Version dann deutlich modularer und dann auch offiziel möglich den eigenen externen Broker zu verwenden. (was Sinn macht, wenn man eh schon irgendwo einen Mosquito o.ä. laufen hat) |
||
|
||
Hi, das klingt wirklich sehr gut! Vor allem scheint das Schreiben ja tatsächlich zu funktionieren, wenn sie darüber schon wetterabhängige Beeinflussungen bauen. Den Stromverbrauch sehe ich nicht als ganz egal an. Beliebig viel kann man aus dem entsprechenden Anschluss der Nibe vermutlich nicht ziehen. Das Modbus 40 zieht bis 80mA, das wären also knapp 1W bei 12V. Sehr viel mehr würde ich da also nicht ziehen wollen... vielleicht das Doppelte, aber nicht wesentlich mehr. Ein Pi 2 oder Pi 1 könnte also schon knapp werden (oder eben extern speisen). Haben die Schweden da irgendwelche Infos, wieviel mA die Nibe an diesen Pins liefern kann? Aus den Diskussionen um den NibeGW wissen wir ja, dass die Bestätigungen Richtung Nibe sehr zeitkritisch sind. Von daher sollte auf dem Pi am besten nicht viel mehr als das laufen, was zwingend nötig ist. Von daher ist das anscheinend getestete Image der Schweden vermutlich eine gute Idee. Mist ist, dass der Pi Zero nur WLAN kann. USB LAN wäre eine Möglichkeit, zieht aber vermutlich auch ein bisschen was. Bei 100 MBit/s, was sicher ausreicht, könnte es aber gut sein, dass da ein weiteres Watt ausreicht - müsste man testen. Ich werde das mal weiter anschauen... auch wenn ich dieses ganze Javascript-Zeugs nicht mag und lieber was noch simpleres habe (z.B. kleines C-Programm + Shellskripte), hat diese Lösung verdient, dass man sich damit befasst. Billiger als das Modbus 40 ist sie allemal... Viele Grüße, Jan |
||
|
||
Nochmal von mir... Ob das wohl auch an einem USB-Port eines "normalen" Pi mit einem USB-RS485 geht? Dann hätte man Ethernet und alles wäre fein Nur der Stromverbrauch ist dann natürlich größer. Die Dinger gibt es bei Reichelt extrem günstig: https://www.reichelt.de/raspberry-pi-usb-rs485-schnittstelle-ch340c-rpi-usb-rs485-p242783.html So ein Teil dient bei mir seit 11 Monaten problemlos dem minütlichen Auslesen meiner Stromzähler vor der Wärmepumpe mittels eine PI. Natürlich könnte man da noch einen zweiten RS485-Stick dranstecken, aber ich fürchte, dass das für das Timing auf der Nibeseite zu knapp wird, weil der Pi schon einiges zu tun hat (u.a. die ganze Lichtsteuerung). Aber man könnte ja noch einen nehmen... Hast du den Entwickler per Facebook kontaktiert oder gibt es da noch einen anderen Weg (Gitseite klingt eher nach FB). Ich boykottiere FB nämlich wegen diverser Gründe... Viele Grüße, Jan |
||
|
||
Respekt für Euer Engangement, Wissen und Können. Ich schaue da nur zu. Obwohl ich in dem Bereich auch gerne dazu lerne. Wenn es halbwegs ausgereift ist, könnte man es auch nibe anbieten. Übernahme eines Startups... |
||
|
||
Sagen wir mal so extern Speisen ist ja immer möglich, vielleicht auch gewünscht. Zum Thema Ethernet. Im schlimmsten Fall nimmt man eben einen Ethernet HAT für den Zero und schon ist WLAN kein Problem mehr. |
||
|
||
This text below is translated from english with google. Original in the bottom...
Es ist schön zu sehen, dass Sie alle Parameter des Skripts analysieren.
Fühlen Sie sich frei, etwas zu fragen. Ich bin der Entwickler von NibePi und es wurde entwickelt, um intelligente Automatisierungen von Anfang an bereitzustellen und für jeden Benutzer einfach zu sein.
Das Skript (heatpump.js) wurde um einige Hundert Teststunden optimiert. Und das Timing spielt keine Rolle, selbst wenn Sie intensive Anwendungen ausführen. Zumindest ist dies bei der kommenden Version 1.1 der Fall, die vollständig integrierte NodeRED-Knoten zum Abrufen, Anfordern und Senden von Daten bietet.
Ich habe zuvor NibeGW und die OpenHAB-Bindung verwendet und bin mir der Fehler voll bewusst, und NibePi verbessert sich in jedem Punkt.
Sie müssen das Rad nicht noch einmal erfinden. Sagen Sie mir einfach, was Sie herausholen möchten, und ich bin sicher, dass wir es gemeinsam beheben können, um NibePi für alle Benutzer zu verbessern.
English version: It's nice to see that you´are analyzing all the parameters of the script. Feel free to ask anything. I am the developer of NibePi and it is created to provide smart automations out of the box and to be simple for every user. The script (heatpump.js) is optimized by several of hundreds of testing hours. And the timing is not an issue even if you run intense applications. At least that is the case of the 1.1 version coming which will offer fully integrated NodeRED nodes for getting, requesting and sending data. I have used NibeGW before and the OpenHAB binding and I am fully aware of the flaws of it and NibePi improves on every point. You do not have to invent the wheel again, just tell me what you want to get out of it and I am sure we can fix it togehter, making NibePi better for all users. 2 |
||
|
||
@Jan 120mA sind bei 12V auf den Pins der Nibe von Nibe vorgesehen. |
||
|
||
Hi, and welcome in this forum! It is great that you are writing here. I was just a few days from buying the Modbus 40 but this is much greater and offers much more options. Great I have some questions... This means you do not see a problem to execute it on a Pi that is otherwise rather busy with other stuff that is compute-intensive from time to time? In my KNX application (Weinzierl BAOS 838 using RS232 on the PI side) I experienced timing problems on a heavy loaded Pi 3 - that is why I asked. At the end, this Pi already has RS232 for KNX, RS485 for reading smart meters and now I consider NibePI... or a second small Pi just for interfacing the heat pump because this has to be as stable as possible. Have you tested NibePi with other RS485 devices besides the one you link on the GIT site? Especially, I'm interested in USB adapters such as this one: https://www.reichelt.de/raspberry-pi-usb-rs485-schnittstelle-ch340c-rpi-usb-rs485-p242783.html For "usual" RS485 (reading smart meters) this works very well and stable, but USB adds another layer of complexity. With respect to feeding it from heat pump: Do you have any information regarding the possible power delivery on 12V? Normally, this is for feeding the Modbus 40 which requires up to 80 mA at 12V - appr. 1W. For a Pi Zero this is fine but all the other Pi, especially with LAN, require significanty more than 1 W. Greetings and many thanks, Jan |
||
|
||
I will answer for the new version 1.1. NibePi runs a "backend.js" in a own application which is optimzied and only do what is necessary for communication with the heatpump. The backend receives data and queues it and sends it to the heatpump when it's ready to receive. All the calculations, decoding, mqtt, node-red is handled in another .js script. Making the backend run in it's own dedicaded event loop as a own application. Maybe your KNX application is not optimized the same way. A user in NibePi forum is using the NibePi image file with a raspberry pi 3 and a USB-RS485 stick. It works. I cant say if the timing is perfect but im sure there are no problems with that setup. You can connect atleast to accesories to a Nibe heatpump. Modbus40 and a RMU40 at the same time. They draw 120mA of current togheter, making it 1,44W. So that should be our minimum. |
||
|
||
Hi, It is not Although it is multi-threaded C++, it is not optimized in any way... That sounds great. Can you point me to the appropriate posting/thread in this forum (I can use google translate on that)? I have a leftover Pi2 and a spare RS485 USB... so I can give it a try. Are you aware of any requirements regarding the RS485 interface or can we use just anything that is "Rs485"? The stick I have is rather cheap and lacks the GND connection - it has only the differential A and B lines. Obviously, I can just connect GND to Pi GND but normally RS485 should not require this (it works without on the smart meters but here on the Nibe side it is not standard modbus). Was there any "bad" experience with interfacing the heat pump that way? Greetings, Jan |
||
|
||
Hi nibepi, nice project! I guess it might be a nice alternative for the not so tech-savvy users to the existing solutions such as NibeGW. I have a question that is somehow related to Jan's question about the timing of acknowledgements. What would happen if there is a power outage and the RPi and the Nibe heat pump need to restart? Does the RPi reboot before the Nibe is restarted and hence can acknowledge packets before the Nibe would go into alarm mode? This may sound like an unlikely situation but actually it happened two or three times to me since I use NibeGW. Luckily, this is not an issue there since the Arduino is ready within a second or so. And actually this becomes a real issue if the RPi would be powered by the Nibe, as discussed in this thread. Because if the RPi starts up too slowly, then every restart of the Nibe (and hence restart of the Pi) would result into alarm mode. |
||
|
||
It's on facebook as a closed group. If you have facebook just search for NibePi. I have heard that burning an image to a SD card and putting it in a Rpi2/3 will work, but you need to modify the heatpump.js (/home/pi/.nibepi/heatpump.js) to work with the ttyUSB0 (Or whatever) instead of the standard port ttyAMA0. SSH credentials are pi / nibe. It should work without the GND since rs485 wont demand that. The user said it just worked after he changed the port. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]