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
|
|
||
|
Hallo, ich freue mich zu sehen, dass dieses Projekt so weit fortgeschritten ist. Vielleicht kann mir jemand die drei Fragen kurz und knapp beantworten? Vielen Dank! 1) Ist NibePi einfach ein fertiges Raspberry Image, welches "NibeGW" vorkonfiguiert enthält? (ich las früher immer etwas von "NibeGW") 2) Ich las etwas davon, dass NibePI die Daten über MQTT aussendet, diese kann ich ja mit meinem Smarthome verarbeiten (z.B. HomeAssistant oder OpenHub). Kann ich denn auch Einstellungen meiner VVM500/F2120-12 ändern (insbesondere die Lüftungseinstellungen also 50%, 100% etc.) - das würde ich hin und gerne vom Smartphone tun (ohne die Premium Mitgliedschaft..) 3) Ich glaube früher war immer von einem Arduino die Rede, jetzt wird der Raspberry Zero verwenden? Hat das einen Grund (Ethernet / WLan Anschluss...?) |
||
|
||
|
1) ja, GW kenne ich nicht 2) das muss man konfigurieren, ich mache alles über Node-Red, siehe mein Bild:  Lüftungseinstellungen kann man auch implementieren, da ich diese nicht besitze, habe ich es nicht eingebaut. Von unterwegs verstelle ich es genau so wie im Lan, nur per VPN. 3) ich verwende einen Raspberry Pi 3B mit Lan Anschluss, siehe mein Blog: http://hausbau-becker.blogspot.com/2020/06/it-fachartikel-fernsteuerung-nibe.html |
||
|
||
|
ad 1) nein, NibePi ist eine komplett neue Implementierung und hat kein NibeGW dabei. NibeGW ist ein Teil von openHAB bzw. genauer gesagt des Nibe Bindings für openHAB. ad 3) NibeGW gibt es für Arduino und Raspberry Pi, NibePi nur für RPi. Vorteil Arduino: als Mikrokontroller stabiler als ein RPi, WPWP [Wärmepumpe] wird nie in den Alarmmodus gehen. Nachteil: zusätzlich wird immer ein RPi benötigt Einfacher und schneller dürfte es mit NibePi gehen, weil da alles in einem fertigen Image kommt. Robuster ist NibeGW auf einem Arduino. |
||
|
||
|
NibePi använder sina egna moduler för att kommunicera med värmepumpen. NodeJS, NibeGW använder C-kod eller arduino-kod. Men NibePi stöder kommunikation med en NibeGW-modul. Men jag skulle fortfarande rekommendera den verkliga NibePi-installationen med version 1.1 https://github.com/anerdins/nibepi/blob/master/README.en.md NibePi commuicates with MQTT, as supported by most smarthome system. I think NibeGW/openhab lacks on that point. You can read and write a lot of settings, so there should be no problem adjusting that. NibeGW and openhab has used arduino and rpi. But with NibePi I want a more powerful hardware capable of doing more things than just send UDP (arduino). Recently I have been starting my own SMS service, my snapshot version of 1.1.2 implements sending SMS from a MQTT topic. ( MQTT -> NibePi core -> NibePi dev cloud -> SMS gateway -> Phone). This should also work in the rest of europe (not just sweden) because my service provider has free SMS all over europe. EDIT: All comments translated to swedish, sorry... |
||
|
||
|
Actually, openHAB also supports MQTT, as well as NodeRED. E.g. I use NodeRED flows to calculate the current heating/cooling power or sample/preprocess some register values before storing them in a database. So NibeGw with the openHAB Nibe binding are quite similar to NibePi in terms of functionality. However, as far as I read here, NibePi is easier to configure and thus the better alternative, if openHAB is not used already. |
||
|
||
|
Hi all I am following this topic with some questions. I have a F1145-12 and want to get some stats & tweaks from my heatingpump. What do you suggest, a RaspberryPI with NibePI or going more for the Prodino MKR ? How is the Prodino MKR powered ? Via POE? Thanks for the info. I was first checking to do everything via Nibe Uplink, but via this MODbus principle it will be better imho. |
||
|
||
|
Since I am using openHAB for other smart home functions anyway, the NibeGW solution fits my setup perfectly. I use a Prodino MKR directly powered by the heatpumps 12V supply that is intended for the official Modbus40 module. If you start from scratch, NibePi on a Raspberry Pi Zero may be the easier solution to start with. Downside is a slighty reduced robustness. |
||
|
||
|
But what I read is that the Prodino MKR is more robust (non modbus alarms). Are the connections for the Prodino MKR the same as for the raspberry pi zero (W) ? I would integrate the Prodino MKR inside the Nibe heatpump & place a RPI with NibePi for the dashboarding in my office. So I have the dashboarding available for selecting hot water etc.. |
||
|
||
|
In terms of hardware yes, software no. NibePi handles ACKs in JS on a Raspberry that runs dozens of processes and may fail for different reasons. The MKR has exactly one purpose and runs nothing else. AFAIK this is currently not possible but will be added to NibePi in an upcoming release. |
||
|
||
|
Little status update: I have now integrated NibeGW with MQTT support directly in the Prodino MKR software. It is more of a proof of concept but so far things went very smoothly. As of now only the registers received via the periodic telegrams are decoded and posted to their respective MQTT topics including the raw data as received without decoding based on the register type. Explicit Read/Write operations outside the predefined list of registers but triggered via MQTT topics are to be implemented. While doing so, my outside temperature dropped to 9.2 degrees which is encoded as 0x5C = 92. 0x5C is the telegram start marker and is therefore encoded as two 0x5C 0x5C. I thought this was handled by NibeGW already but it's not and those messages are forwarded as is via UDP. As this brings the size of a register encoding from 2+2 to 2+3 bytes all following registers are decoded with 1-off data if this special case is not handled. It doesnt affect the basic Nibe <>Prodino communication in any way though (which is rock solid and thus no alarms whatsoever), but any downstream software working with the UDP data needs to handle it separately. |
||
|
||
|
Actually 1.1 has beed released (and translated in most part to german and english) https://github.com/anerdins/nibepi/blob/master/README.en.md  So you can use a prodino with NibePi running on a own separate Raspberry Pi, still no guide though how to install it on a already running system. This docker-image supports running on a docker. https://hub.docker.com/r/anerdins/nibepi-base Fully functional MQTT support
|
||
|
||
|
You can modify the prodino code and look in the data buffer for double 0x5C. [0x5C,0x5C]. Which means it's not an start it's a value. handle that before it sends it away. I loop through the buffer and look for double and remove it and recalculate the checksum. Example code below from NibePi. |
||
|
||
|
The checksum calculation and verification is done by NibeGW before the data array including multiple 0x5Cs is handed over to the callback function, so the multiple 0x5Cs are to be included in the checksum? Here is an example telegram: 5C00206851C9AF00006EAFBCFF449C5C5C00489C80014E9C80014D9CED018BA8031E85A87D0080A8900139A803001BB9010021B801001FB81E001EB85A00D3A1640056BF6400C8A300003AB96400FFFF0000FFFF000032 Register: 40004 = 9C44 with value 5C5C00 = 9.2 degrees decoded Anyway, I just wanted to point out that the receiving end of the UDP data stream needs to handle this (at least with the NibeGW version that I started my project with). NibePi offers the following architectures: Nibe <> Arduino with NibeGW <> UDP <> NibePi <> MQTT Nibe <> NibePi <> MQTT Correct? I am looking to condense that a bit into: Nibe <> Arduino with NibeGW+MQTT support <> MQTT Actually the UDP support is still present, so it could be used in parallel: Nibe <> Arduino with NibeGW+MQTT support <> MQTT Nibe <> Arduino with NibeGW+MQTT support <> UDP <> NibePi (<> MQTT) I am going to adjust my MQTT support to be compatible with your approach. Please understand that I am not trying to compete with your project. I love what you are doing, I have just lost faith in the long term stability of Pi + NodeJS architectures. They are nice and very flexible to run comfort functions and I have 3 running in my house but IMO not realiable enough to keep critical infrastructures alive. That is why I am striving for the Arduino<>MQTT architecture. |
||
|
||
|
The idea of NibeGW is to forward packets to the UDP receiver. The packets are NOT altered in any way. NibeGW just ack's the packets in order to avoid alarms and sends valid one on UDP. Everything else should be done at the other side. Therefore, de-escaping (dropping double 0x5c) is not part of NibeGW Yes. The checksum applies to the packet as it is transmitted, so including escaped characters. I'm not sure if it is a good idea to do MQTT at Arduino because this way, you have to deal with much more possible problems than with just UDP. What happens if MQTT broker is not reachable? etc. UDP is "fire and forget" - very simple and low overhead. It does not matter if there is no receiver. Additionally, if we support writing to Nibe, the gateway has to do much more. It has to be aware of registers, data types, ranges, etc. in order to avoid illegal actions. Keep in mind that Nibe (at least partially) relies on such checks. Without these checks, you can set parameters to values not possible by user interface. E.g., I use my UDP-MQTT-gateway in order to set maximum automatic pump speed to values <50 (not possible with UI). If we implement such checks on Arduino, we will run into memory limitations. 1000+ registers with data types, ranges, etc. need severel KB of memory... However, a stable (!) arduino-based MQTT source would be nice - maybe on one of the bigger Arduinos. |
||
|
||
|
Well, I am using the Prodino MKR Zero Ethernet and there is not really an issue with memory. Sketch uses 48084 bytes (18%) of program storage space. Maximum is 262144 bytes. Global variables use 9584 bytes of dynamic memory. This contains NibeGW + MQTT support + 1000 register definitions (not yet including range limits). Range limits/validity constraints only need to be added for writable registers. |
||
|
||
|
Hey guys, first of all a great project!! I started with my first PI Zero and the NibePI 1.1 image and it worked fine. I already played around a little bit and added Sensors for my FLM module -> Works fine. Now I'm trying to rais the security a little bit ... enabling AUTH for NodeRed admin dashboard ist working. I'm stuck is the MQTT authentication. I enabled authentication in mosquitto -> fine ... my local MQTT Browser can connect after entering these credentials but nibepi does not send any data ... I have configured these credentials in "NibePi" and "/dev/ttyAMA0" and in the Example tab, MQTT are getting "connected" again ... but no values are transfered and "node-red-log" only shows "MQTT Broker is disconnected." and "Could not connect to MQTT broker". I can see that node-red itself is connected: 1600014984: Sending CONNACK to 127.0.0.1 (0, 5) 1600014987: Received PINGREQ from nibepi 1600014987: Sending PINGRESP to nibepi 1600014989: Sending CONNACK to 127.0.0.1 (0, 5) Any ideas? Even adding these credentials to /etc/nibepi/config.json doesn't solve the issue. Disabling auhtentication in MQTT resolves the issue immideately. Thanks a lot, KoMa |
||
|
||
|
I have got some other reports that auth in MQTT client isnt working, I will take a look at it as soon as I can. So the problem is probably not in your setup. That is correct. I have no problem with that. Having everything in one hardware dedicated to communicate with the heatpump is a great idea, and if the prodino is a more powerful arduino I think you can achieve that. But I actually believe that the aproach with read-only SD card on a raspberry pi zero is a stable solution. I have also experienced all the issues with raspberry pies and corrupt memory cards, but time will tell if my aproach is a good stable way. |
||
|
||
|
Is there any documentation about these limits? And do you know wheter the official Modbus40 module adheres to them? That sounds cool! IMHO the best compromise between robustness and usability. |
||
|
||
|
Thanks a lot! If you want me to test/try something please tell me. may I ask what the config.json is needed for and shouldn't this file be updated from the admin dashboard? also Ido not use log.set because I want to query only specific registers every x minutes. Is there a way to configure how long the system should wait before querying again? And am I right that all Register are queried that are configured in config.json or used in a dashboard? Im sorry I do not use Facebook it may be already discussed. Thanks a lot, KoMa |
||
|
||
|
It's me again ... I managed it to bring up MQTT with authentication ... But I think there is room for improvement ... Steps: 1. Configure Mosquitto to use Auth: mount -o remount,rw / mosquitto_passwd -c /etc/mosquitto/users.conf nibepi mosquitto_passwd /etc/mosquitto/users.conf user1 mosquitto_passwd /etc/mosquitto/users.conf user2 Enable Authentication: vi /etc/mosquitto/mosquitto.conf allow_anonymous false password_file /etc/mosquitto/users.conf systemctl restart mosquitto.service 2. Enable MQTT auth in nibepi/nodered: -In NodeRed edit mqtt-broker (NibePi) and as well as nibe-config (/dev/ttyAMA0) and add credentials. -Also edit /etc/nibepi/config.json and add credentials. reboot ... Now MQTT works only with authentication. It is still interesting for me I can define which registers are published to MQTT. The ones defined in /etc/nibepi/config.json? And also the relationship between nodered and the config.json is ... it seems changes in nodered are not saved to this config file. Next step to make it a little bit more secure will be TLS/SSL for MQTT |
||
|
||
|
Next update ... I enabled TLS ... bad situation is that we have mosquitto 1.4.1 installed and there is no mosquitto 1.5 for this debian release. V1.5 brings per listener settings and this will allow unauthenticated traffic on localhost and only authenticated on the network. Now my setup looks like this: Port 1883 (MQTT in plain text) listens only on localhost Port 8883 (MQTT with SSL) listens on all interfaces Advantage of this setup: Less performance on localhost because of the unecrypted traffic. My mosquitto.conf: # Place your local configuration in /etc/mosquitto/conf.d/ # # A full description of the configuration file is at # /usr/share/doc/mosquitto/examples/mosquitto.conf.example pid_file /var/run/mosquitto.pid include_dir /etc/mosquitto/conf.d # Disable Persistence -> RO file system # persistence false #persistence_location /var/lib/mosquitto/ # Disable Logging for performance and RO file system # If enabled. log to RAMDISK # #log_dest file /tmp/mosquitto.log #log_timestamp true #log_type debug # Define Listeners and per Listener settings # Needs MOSQUITTO V1.5!!! # #per_listener_settings true # Listener 1883 # -only on localhost # -unencrypted # -no authentication (will come with v1.5) # listener 1883 localhost #allow_anonymous true # Listener 8883 # -on all NICs # -Encrypted # -authentication # listener 8883 allow_anonymous false password_file /etc/mosquitto/users.conf certfile /etc/nginx/ssl/SSL-CERT.cer cafile /etc/nginx/ssl/CA-CERT.cer keyfile /etc/nginx/ssl/SSL-KEY.key (If you now ask regarding nginx-path: I'll later setup a nginx proxy to make node-red accesible vie port 443 only and do a redirect from port 80 (http) to 443 (https) and I want to share certificates. This for now works fine ... disadvantage: Some tools (like MQTT 2.1.4 for iobroker) do not support self signed certificates. To make this work, edit /opt/iobroker/node_modules/iobroker.mqtt/lib/client.js and add "rejectUnauthorized: false" (without "" and remeber to add a commy at the end of line 134). I already opened a feature request. KoMa |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]