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
|
|
||
|
Danke JanRi, habe heute beobachtet als Länge 87 war und Byte 53 54 waren 5c5c kodiert. Programmiere heute eine Funktion die Byte auswertet und entfernt |
||
|
||
|
Hallo, nachdem ich hier schon lange interessiert mitgelesen habe wollte ich jetzt meine Nibe F1245 über nigebw an openHAB anbinden. Ich verwende einen RPi und habe dort die aktuellste Version von nibegw drauf. Ich verwende einen RS485 USB-Adapter. Allerdings komme ich nicht weiter - Kabel, RPi, USB-Adapter etc. habe ich schon ausgetauscht. Nach der ersten Meldung im Log geht die WPWP [Wärmepumpe] immer in einen Alarm (251). Die WPWP [Wärmepumpe] hat die Firmware 9240R2. Mir gehen jetzt nach einigen Tagen die Ideen aus. Die interessanten Werte habe ich über LOG.SET übertragen. Was kann ich noch versuchen? NibeGW version: 1.22 Verbose level: 3 Test mode: FALSE Serial port: /dev/ttyUSB0 Flow control: HW remote UDP address: 192.168.178.48:9999 server UDP address for read cmds: 10000 server UDP address for write cmds: 10001 RS-485 address to listen: 0x20 Send all messages by UDP: FALSE Send acknowledge: TRUE Send acknowledge to all addresses: FALSE Open serial port: /dev/ttyUSB0 Initialize UDP server Initialize UDP server 2020.5.15 15:26:59:672898: 5C 00 20 6B 00 4B (calc/recv checksum 4B/4B = OK) Valid message received, len=6 Write token received Nothing to send...Send ACK (0x06) Write data to serial port Data: 06 |
||
|
||
|
Vielleicht ein Rechteproblem? Ich würde mal ein "chmod 666 /dev/ttyUSB0" probieren, oder NibeGW mal als root starten. |
||
|
||
|
Ich hatte ein ähnliches Problem, habe das aber quasi als "Hack" erledigt. Ich vermute, dass nibegw den Port nicht sauber initialisiert. Wenn das mit den geänderten Rechten nicht geht (siehe chrismos Post), dann schau dir mal mit setserial den seriellen Port an und prüfe, ob er richtig eingestellt wird (die Parameter stehen in den Quellen von nibegw). Setserial: https://linux.die.net/man/8/setserial Bei mir lief es, nachdem ich die Parameter auf eine zugegebenermaßen sehr "hacky" Weise erzwungen habe, weil es schnell gehen musste. Setserial ist aber der saubere Weg. Könnte man dann auch so machen, dass man sie im Script per setserial setzt und danach dann nibegw startet. |
||
|
||
|
Danke für die Tips - setserial werde ich prüfen. chmod 666 /dev/ttyUSB0 hat leider nichts verändert. |
||
|
||
|
So, nachdem ich wieder zurück zum alten USB-Adapter bin (bei dem anderen gab es immer einen IOCTL Fehler bei setserial) bekomme ich jetzt einige Werte von der WPWP [Wärmepumpe] mit 6 Zeichen - bei diesen ist die Prüfsumme ok und es wird eine ACK gesendet. Danach kommt aber ein längerer Wert der immer auf einen Prüfsummenfehler und eine anschließende NACK läuft. Also gibt es wieder einen Alarm . Hat jemand eine Idee wieso hier die Prüfsumme falsch sein könnte? 2020.5.16 16:58:39:428848: 5C 00 20 69 00 49 (calc/recv checksum 49/49 = OK) Valid message received, len=6 Read token received Nothing to send...Send ACK (0x06) Write data to serial port Data: 06 Send UDP data to 192.168.178.48:9999 Data: 5C0020690049 2020.5.16 16:58:39:434596: 5C 00 20 69 00 49 (calc/recv checksum 49/49 = OK) Valid message received, len=6 Read token received Nothing to send...Send ACK (0x06) Write data to serial port Data: 06 Send UDP data to 192.168.178.48:9999 Data: 5C0020690049 2020.5.16 16:58:39:448728: 5C 00 20 6D 0F 01 24 18 46 31 32 34 35 2D 38 20 45 20 44 45 6A (calc/recv checksum 6A/6A = OK) Valid message received, len=21 Nothing to send...Send ACK (0x06) Write data to serial port Data: 06 Send UDP data to 192.168.178.48:9999 Data: 5C00206D0F01241846313234352D3820452044456A 2020.5.16 16:58:39:502281: 5C 00 20 68 50 44 9C 53 01 4F 9C 0F 01 50 9C DA 00 56 9C 27 01 52 9C 4B 01 01 51 9C 24 E1 6E FE FD AF DF BF B2 EB FD EB FF FF 6B AA FD CF 73 FF D5 4C DB FD 75 54 75 C7 EF 7B EF BF E7 75 EE 5E 07 FD FF 22 64 FF 5C 00 20 68 50 44 9C 53 01 4F 9C 0F 01 50 9C DA (calc/recv checksum 03/DA = ERROR) Send NAK (0x15) |
||
|
||
|
From what I can see you are communicating with the heatpump and I have to ask a basic question, after you started nibeGw and get the above messages, have you reset the alarm manually on the heatpump menu? Because, NibeGW dosent do that for you, neither will openhab I believe. |
||
|
||
|
Yes, I have reset all the alarms manually - but then after some seconds a new alarm will show up. At the moment I'm not sure if the parameters for the serial communications are set correctly. I expect to receive messages every 2 seconds - correct? But sometime I have to wait 10 or 20 seconds for the next message and then I get the above shown checksum error. |
||
|
||
|
Schau mal in die Quellen von nibegw.c und überprüfe dann bei laufendem Programm mit setserial, ob die Parameter wirklich so gesetzt wurden. Dann die Verkabelung prüfen: Wie lang sind die beiden Datenleitungen, ist GND verbunden? Was für Kabel hast du benutzt? Bei mir läuft es mit etwa 1,5m KNX-Leitung (diese grüne Busleitung) seit Dezember ohne jeden Fehler. Initialisierungsprobleme hatte ich aber auch. Nibegw alleine wollte nicht sauber funktionieren. Da es schnell gehen musste, habe ich einen "Hack" improvisiert: Ich habe nibepi in der damaligen Version (die noch den Fehler mit den Escapes hatte) genommen und so modifiziert, dass das Programm sich sofort nach der Initialisierung beendet. Danach startet dann nibegw und alles funktioniert prima. Richtige Lösung wäre setserial, aber so geht es auch Wenn du das testen willst, ohne groß zu basteln: Blätter etliche Seiten zurück und nimm eine der frühen Versionen von Nibepi (oder eine der späteren, es geht letztlich nur um die Initialisierung). Die startest du per Hand, wartest kurz und brichst mit Strg-C ab. Danach dann einfach nibegw starten. Wenn es dann geht, dann ist die Initialisierung dein Problem. Das macht nibepi anscheinend besser als nibegw. Um es richtig zu lösen, müsste man sich die Zeit nehmen, die Initialisierung beider Programme Schritt für Schritt zu vergleichen und dann zu korrigieren. Oder eben setserial. Dass es an der Initialisierung liegt, war bei mir damals übrigens 100% klar. Ich habe ja einige Zeit lang mit nibepi und nibegw parallel rumprobiert und dabei öfter zwischen beiden gewechselt. Nibegw hat dabei IMMER funktioniert. Es versagte erst nach einem Neustart. Damit war klar, dass der einzige Unterschied darin lag, dass Nibepi vorher NICHT gelaufen ist. Also muss es an der Initialisierung liegen. Beweis: Nibepi starten, beenden, nibegw ging. Das führte dann zu dem Hack. |
||
|
||
|
setserial funktioniert leider nicht - bekomme immer 'Cannot get serial info: Inappropriate ioctl for device' Wenn ich mir mit stty die Parameter ansehe, entsprechen sie den aus nibegw.c erwarteten Daten. Auch wenn ich sie anders setze sind sie nach dem Start von nibegw wieder in dem erwarteten Zustand. pi@raspberrypi3:~ $ stty -F /dev/ttyUSB0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc Als Kabel verwende ich zwei Adern eines Netzwerkkabels (ca. 1,5m) - geschirmt ist es allerdings nicht. Ich habe es aber auch schon mit nur 30 cm versucht. Trotzdem werde ich mich jetzt mal an nibepi versuchen und schauen ob sich dadurch noch etwas an den Parametern verändert. |
||
|
||
|
Die Versuche meinen Raspberry zur Kommunikation mit der WPWP [Wärmepumpe] zu bewegen habe ich aufgegeben. Letztlich hatte ich schon NibePi intralliert - jedoch ließ sich das erforderliche Modul serialport nicht installieren. Dutzende Versuche und stundenlange Suchen haben zu keinem Erfolg geführt. Aus diesem Grund habe ich mir jetzt ein Prodino MKR bestellt. Die Software habe ich schon vorbereitet - hier vielen Dank an @chrismo für die Erstellung des angepassten Codes. Sobald der Prodino eingetroffen ist werde ich berichten. |
||
|
||
|
It was a driver issue? Did you download the NibePi image file and burned it? Or how did you do? NibePi runs on a read-only file system so in order to install drivers it needs to be opened up with command "sudo mount -o remount,rw /" then closed again with "sudo mount -o remount,ro /" |
||
|
||
|
Wie schaut es mit dem Projekt aus ? Die letzte Version ist 1.0.6. Ich blick da nicht ganz durch. Vorinstalliert ist Node Red und eine Wetter Vorhersage. Das lese ich hier was von Adriano, Openhub, Edomi, Fehlercodes und von JanRi irgendwelche Hacks/instabiler Code Den Pi ZeroW + RS485 HAT + 12V Konverter + SD Karte mit 1.0.6 in meine F1255 integrieren würde ich mir zutrauen - nur wie es dann weiter geht k.A. Hier fehlt eine Noob Anleitung, so wie ich sie auf meinem Hausbaublock schon geschrieben habe (für andere Projekte). Mein Ziel wäre es sowas wie das Uplink in Edomi o.ä. nachzubauen, nur mit Servicemenü Zugriff und allen Werten in Echtzeit. |
||
|
||
|
Um das mal zusammenzufassen: Es gibt mehrere Möglichkeiten, an die Daten dranzukommen. In jedem Fall braucht man einen RS485-Adapter. Möglichkeit 1: NibePi. Hier hast du einen RPi mit RS485-Modul, der an der Nibe hängt. NibePi (es gibt neuere Testversion als 1.0.6, 1.0.6 enthält noch diverse Fehler, die hier im Thread besprochen sind) enthält ziemlich viele Features. Für den Zweck, selbst etwas zu bauen, reicht eine stark reduzierte Fassung. Dazu hatte NibePi (der User, nicht das Programm) hier auch einige Hinweise gegeben. Letztlich kann man damit sämtliche gewünschten Werte in ein MQTT-System einspeisen und auch via MQTT Abfragen formulieren. Wenn dein Eigenbau MQTT spricht, wäre das eine gute Möglichkeit. Der Weg ist also: WPWP [Wärmepumpe] <-> RPi <-MQTT-> irgendein Programm Möglichkeit 2: OpenHAB oder ähnliches. Hier ist die Idee, dass eine UDP-Schnittstelle den Zugriff in beide Richtungen realisiert. Diese wiederum kann auf zweierlei Weise bereitgestellt werden: 2A: RPi mit nibegw. Der RPi hat wieder ein RS485-Modul und sendet alles, was er bekommt, per UDP raus. Zusätzlich hat er einen UDP-Server, über den man Anfragen starten kann (Antworten kommen dann als UDP-Paket). 2B: Arduino mit nibegw, RS485 und Ethernet. Macht genau das gleiche wie der RPi, nur vermutlich stabiler. Der Weg ist also: WPWP [Wärmepumpe] <-> RPi oder Arduino mit nibegw <-UDP-> OpenHAB oder so. Möglichkeit 3: Man nehme den "Nibe-UDP"-Adapter von Möglichkeit 2, wobei es letztlich egal ist, ob es 2A oder 2B ist. Dann schreibt man selbst einen kleinen UDP-Server+Client, der die Gegenstelle darstellt und die Daten dann weitergibt oder selbst verarbeitet. Den Weg bin ich gegangen (2A, also RPi), wobei mein UDP-Adapter letztlich die MQTT-Schnittstelle von NibePi nachbaut. Alles weitere dann über UDP. Der Weg ist dann: WPWP [Wärmepumpe] <-> RPi oder Arduino mit nibegw <-UDP-> UDP-MQTT-Adapterprogramm <-MQTT-> irgendein Programm Der wesentliche Unterschied zwischen 1 und 3 ist, dass man bei 1 deutlich mehr auf dem RPi macht. Bei 3 macht der RPi/Arduino nur die Umsetzung auf UDP und alles andere passiert woanders (bzw. kann woanders passieren). MQTT ist genial, darum würde ich diesen Weg empfehlen. Damit ginge dann sowohl 1 als auch 3, wobei du von NibePi nur einen Bruchteil brauchst, nämlich den Teil, der die MQTT-Kommunikation realisiert. NodeRed, Wettervorhersage usw... brauchst du dann alles nicht. Wie genau man das mit der Beta-Version erreichen kann (also das reine MQTT-Gateway), müsstest du NibePi fragen. Das dürfte mit den NibePi-Images fast out-of-the-box gehen. Für Variante 3 könntest du meinen Adapter als Startpunkt verwenden. Das sind letztlich nur 344 Zeilen Javascript + eine JSON-Datei mit den Registerbeschreibungen. Stabil ist es, sogar extrem stabil. Es läuft jetzt seit einem halben Jahr im Dauerbetrieb ohne ein einziges Problem. Ich logge dauerhaft darüber und es ist auch mein Uplinkersatz. Ich kann damit wesentlich mehr machen als mit Uplink-Premium, weil man alles schreiben kann, was grundsätzlich schreibbar ist. Ich brauche aber keine fancy GUI. Von daher setze ich z.B. die Kühlgrenze so auf 18C (das würde exakt genauso auch bei NibePi funktionieren, weil die Schnittstelle identisch ist, nur der Weg zur Nibe eben ein anderer): mosquitto_pub -h localhost -t "nibe/modbus/47374/set" -m "18" Das ist in keiner Weise massenkompatibel, oder? Man kann aber natürlich an das MQTT eine GUI dranbauen, wenn man das braucht. Da es quasi auf meine Bedürfnisse zugeschnitten ist, sehe ich wenig Sinn drin, das in der Form zu veröffentlichen. Zudem müsste man schauen, ob es auch mit Fällen zurechtkommt, die ich bislang noch nicht hatte. Von daher nutze ich es produktiv, aber das könnte ebenso auch jemand anders tun, der sich da reinarbeiten will. Ich habe halt nur keine Zeit, da eine allgemeinverständliche Anleitung zu bauen.
|
||
|
||
|
Danke Jan. Scheinbar braucht es MQTT, ich frage mich wie und wo man MQTT am besten einrichtet. Auf dem Raspberry der an der WPWP [Wärmepumpe] hängt oder auf einem anderen Raspberry ? Der RPi der in der WPWP [Wärmepumpe] verbaut wird, soll ja ein "Read only" System sein - hier kann man ja nicht mal ein Update durchführen - das irritiert mich ein wenig. D.h. der kann dann auch nicht der MQTT Server sein und Edomi wohl auch nicht "beherbergen". Ich habe einen RPi 3B im Sicherungskasten der im Moment folgendes macht: -VPN (Wireguard) -Pihole -SMA Dienst "Smart Appliance Enabler" -neu spotane Abfrage des SMA EM (siehe mein Blog) D.h. an die WPWP [Wärmepumpe] muss sowieso ein Weiterer. Ist nur die Frage ob ich den alten 3B in die WPWP [Wärmepumpe] integrieren sollte und dafür einen neuen 4er in den Sicherungskasten setze, oder den 3B so lasse und einen ZeroW für die WPWP [Wärmepumpe] nehme. Ein FB Freund hat schon angefangen mit Edomi:  So in der Art stelle ich mir das auch vor. Kann man hier auch Schalter nachbilden z.B. für Luxus WW WW [Warmwasser] einmalig und WT-Pumpe % ? Wie fragst du denn live Werte ab ? Auch so: mosquitto_pub -h localhost -t "nibe/modbus/47374/*** |
||
|
||
|
Bei NibePi ist alles auf einem Pi. Der MQTT-Server kann problemlos mit readonly Dateisystem laufen. Wenn du mit NibePi arbeiten willst, dann würde ich das betreffende Image nehmen, auf die neueste Version bringen und das auf einen Pi packen. Da läuft dann auch Mosquitto (der MQTT-Broker). Von deinem anderen Pi aus abonnierst du einfach die betreffenden Themen. Nein... das fordert nur an. mosquitto_sub -h localhost -t 'nibe/dbus/43024' ...abonniert den Kanal 43024 (Status Kuehlung). Wann immer da was publiziert wird, bekommt man das. Das ist aber nur mein Weg für alles übrige. Mein Livebild AT: 15.0 IT: 22.5 AT_24h: 19.7 VL: 19.7 RL RL [Rücklauf]: 21.1 exVL: 19.4 VLsoll: 20.0 PCsoll: 20.5 Kond.VL: 19.5 Heissgas: 28.5 Sauggas: 21.8 SoleEin: 12.2 SoleAus: 14.5 BWoben: 44.2 BWunten: 32.4 WQ: 1 % WT: 40 % WT: 12.2 l/min Kompr.: 0.0 Hz Ziel: 0.0 Hz Inverter: 21.1 C Relais: 6 Starts: 243 0.0 GM Spreizung: -1.4 P_th: -1192 W P_ko: 0.0 W P_pu: 48.8 P_el 48.8 AZ: -24.428 EZ Kompressor: 3338.9 KWh EZ Pumpen: 511.9 KWh BW Kompressor: 0.000 KWh BW Pumpen: 0.000 KWh Modus Kuehlung WMZ Heizung: 19095.8 KWh WMZ BW: 1476.1 KWh WMZ Kuehl: 0.0 KWh Betriebsstunden: 8343 Betriebsstunden BW: 369 Alarmz.: 0 Alarm: 0 Letzter Al.: 0 Alarmtimer: 0 Nachrichten: 22333 ist ein node.js Programm, das selbst MQTT spricht. Es funktioniert letztlich so: Es hat die 20 Werte aus der LOG.SET abonniert. Die schickt die WPWP [Wärmepumpe] ja alle 2 Sekunden. Nibegw liest das und schickt es per UDP an meinen UDP-Adapter. Der dekodiert und kippt es in das MQTT. Jeder, der das abonniert hat, bekommt es. Ich bekomme also alle 2 Sekunden alle Werte aus der LOG.SET. Selbiges würde auch mit mosquitto_sub klappen - da erscheint dann alle 2 Sekunden ein neuer Wert. In Javascript auf node.js ist es aber geradezu trivial, mit MQTT zu arbeiten. Damit bekommt mein Logger diese 20 Werte. Zusätzlich logge (und anzeige) ich weitere 15 Werte. Das mache ich so, dass mein Logger entsprechende Nachrichten publiziert (analog zu dem Kommando oben). Damit die Last nicht zu hoch wird, frage ich die ca. 15 Werte im Abstand von 20 Sekunden ab, also jeden Wert etwa alle 5 Minuten. Das triggert dann bei UDP-MQTT-Adapter die Abfrage des betreffenden Wertes. Der wird dann bei der WPWP [Wärmepumpe] nachgefragt und wird dann wiederum per MQTT publiziert, wo ich es dann per Abo wieder bekomme. Mit Nibepi würde das ganz genauso gehen. Nibepi publiziert die Werte aus LOG.SET alle zwei Sekunden und alle anderen, nachdem du eine Anfrage publiziert hast. Mit Edomi kenne ich mich in keiner Weise aus. Du musst da quasi eine Datenquelle einbauen, die die entsprechenden Topics abonniert. Zusätzlich würde ich mit einem kleinen Programm (das kann ein Shellskript sein, das periodisch mosquitto_pub aufruft) Anfragen nach allem übrigen publizieren, so dass die Antworten dann auch reinlaufen. Als erstes würde ich es aber mit mosquitto_pub/sub austesten. Dann sieht man, wie genial und einfach MQTT im Grunde ist. WT-Pumpe setzen: mosquitto_pub -h localhost -t "nibe/modbus/47414/set" -m "49" ...setzt auf 49%. Logischerweose kannst du auch den Wert 49 mit einem Programm deiner Wahl unter der Topic "nibe/modbus/47414/set" publizieren. Du kannst ALLES machen, wofür es schreibbare Register gibt. Das geht um mehrere 1000% über das hinaus, was Uplink Premium kann. Aber! Die Anzahl der Schreibzyklen ist begrenzt... siehe betreffender Thread. Wenn ich mal WW WW [Warmwasser] außer der Reihe will (nachts ist bei mir Spar mit niedriger Anschalt und normaler Ausschaltschwelle), dann tut es das folgende Skript: echo "Schreibe 42..." mosquitto_pub -h localhost -t "nibe/modbus/47045/set" -m "42" echo "Warte 10 Sekunden..." sleep 10 echo "Setze zurueck..." echo "Schreibe 22..." mosquitto_pub -h localhost -t "nibe/modbus/47045/set" -m "22.0" Das setzt die Anschaltschwelle von "spar" auf 42 und 10 Sekunden später wieder auf 22 zurück. Damit läuft dann WW WW [Warmwasser]. Pi Zero: Da stört mich das WLAN. Ethernet ist da nicht so leicht. Bei mir hängt ein alter RPi2 an der WPWP [Wärmepumpe]. Darauf läuft das alte NibePi-Image mit Readonly, das ich als Basis für nibegw verwende. |
||
|
||
|
I'm working on finalizing version 1.1 of NibePi and making it availibe in english, and it is supposed to be easily translated to deutch because it's just a translate.json file that needs to be edited. Example: "SE":"<b>Uppdatera grafer</b><br><i>Aktiverar att hämta registerdata och uppdatera NibePis interna grafer.</i>", "EN":"<b>Update graphs</b><br><i>If activated, this function keeps the common graphs in NibePi updated.</i>" "DE":"Deutch hier!" I have limited time of doing this unfortunally, so it will take several weeks, or months to make it complete. And as JanRi also says, there is a simplifed Node.js library availibe called "nibepi" which can work just as a simple Nibe <-> MQTT More information will be availibe.. Here is my new github for my project, the rep "nibepi" is just the library with and example.js file. http://github.com/anerdins |
||
|
||
|
Weis jemand mit welchem Partameter die Lüftunsgeschwindigkeit geändert werden kann? Da gibt es ja Stufen mit eingestelleten Parametern, wie beim Heisswasser. Ich finde aber nicht den Parameter der die Stufen beinflusst. Hartmut |
||
|
||
|
Sowas hat unsere Solepumpe ja nicht, aber eventuell klappt der übliche Trick, um das Register zu erfahren: Du stellst die Lüftungsgeschwindigkeit am Gerät ganz normal um. Danach schaust du in das Änderungsprotokoll. Falls das ein Konfigurationsparameter ist, der per Modbus zu ändern geht, dann steht da dann sowas drin wie Register xxxxx auf yyy. In jedem Fall wirst du den Luftdurchsatz der eingestellten Stufe ändern können. Schau dir mal bei nibepi das .json-File zu deiner WPWP [Wärmepumpe] an. Da sind die Register alle wunderbar dokumentiert. |
||
|
||
|
Englisch reicht eigentlich Noch mal für Dumme: ich integriere mir einen RPi mit RS485 & 12->5V Adapter in die WPWP [Wärmepumpe], darauf mache ich Raspian und dann Node.js von NibePi ? Und dann kann ich noch einen MQTT Server drauf laufen lassen und damit erst mal per Kommandozeile lesen/schreiben ? Und dann kann ich in Node RED o.ä. Programmen eine Visualierung bauen, diese greifen dann auf MQTT zu ? |
||
|
||
|
Yes, basically Raspbian installation + NodeRED installation, you can even use my NodeRED nodes which integrates into the heatpump directly without MQTT. In NodeRED you can build automations or activate the MQTT part from NodeRED. Since you're doing an integrated solution I would use my 1.0.6 image file and skip my "NibePi" user interface which is availible in NodeRED. The image file runs in read-only and can be open up for writing when needed. This add some safety/stability features and minimizes SD card wearing. The register you are looking for is 47260. It's not in the official modbus documentation. But it has been found anyway. My final version of 1.1 will have that included in the register files. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]