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
Teilen:
|
|
||
|
Noch ne Frage: Bekommt Ihr Werte für Brine Pump Speed (47418) und Supply Pump Speed (47437) bei der F1255-6? Und welche Register fragt Ihr für den Wärmemengenzähler ab? Für Warmwasser Comp.+Add. nehme ich Register 44298, was mit ca. 3.500 kWh auch plausibel aussieht. Aber für die Gesamtheizleistung inkl. WW bei Register 44300 bekomme ich nur ca. 420 kWh - das passt nicht zusammen. Die WPWP [Wärmepumpe] ist jetzt gut 2.5 Jahre in Betrieb, das waren sicher mehr als 420 kWh Heizenergie |
||
|
||
|
Hallo, ich nutze: case 'nibe/modbus/43437': return handleRegister(message,18) // WT case 'nibe/modbus/43439': return handleRegister(message,19) // WQ für WT und WQ-Pumpe. Für die WMZ verwende ich (siehe Kommentare, die Zahlen hinter message sind irrelevant, das ist nur der Index für meinen Logger): case 'nibe/modbus/44298': return handleRegister(message,31) // WMZ HW total case 'nibe/modbus/44300': return handleRegister(message,32) // WMZ total heat case 'nibe/modbus/44302': return handleRegister(message,33) // WMZ Cool case 'nibe/modbus/44306': return handleRegister(message,34) // WMZ HW Compr case 'nibe/modbus/44308': return handleRegister(message,35) // WMZ Comp heat case 'nibe/modbus/43084': return handleRegister(message,36) // add power case 'nibe/modbus/40067': "Cool" ist leider nur das aktive Kühlen. Für das passive Kühlen habe ich den WMZ noch nicht gefunden. Es gibt übrigens diverse weitere Register, die NICHT in den bisherigen Übersichten sind. Ich ergänze die nach und nach, wenn ich sie brauche. 49874 ist z.B. die minimale WT-Geschwindigkeit. Sowas bekommt man ganz leicht raus: Man ändert per Hand den Parameter der Wahl und schaut danach in die Änderungsprotokollierung. Da steht nämlich die Registernummer drin. 44300 hat bei mir einen plausiblen Wert. Stimmen da eventuell Datentyp oder Faktor nicht? 44300 ist allerdings NICHT WW WW [Warmwasser]+Heizen. Es ist Heizen mit Kompressor+Heizstab. Für Heizen + WW muss man die betreffenden Register addieren. Siehe auch die Kommentare in meinem Programmauszug aus meinem Logger. Viele Grüße, Jan |
||
|
||
|
Man kann beim NIBE ModbusManager alle Register in eine CSV-Datei exportieren. Ich habe die engl. Version, da ist es unter "File"-"Export to file". In der Datei stehen dann Einträge mit kurzer Erklärung, Datentyp und Registernr.: "Heat Meter - HW Cpr and Add EP14";"Accumulated energy production as calculated by the heat meter";44298;"kWh";u32;10;0;0;0;R; "Heat Meter - Heat Cpr and Add EP14";"Accumulated energy production as calculated by the heat meter";44300;"kWh";u32;10;0;0;0;R; "Heat Meter - Cooling Cpr EP14";"Accumulated energy production as calculated by the heat meter";44302;"kWh";u32;10;0;0;0;R; "Heat Meter - Pool Cpr EP14";"Accumulated energy production as calculated by the heat meter";44304;"kWh";u32;10;0;0;0;R; "Heat Meter - HW Cpr EP14";"Accumulated energy production as calculated by the heat meter";44306;"kWh";u32;10;0;0;0;R; "Heat Meter - Heat Cpr EP14";"Accumulated energy production as calculated by the heat meter";44308;"kWh";u32;10;0;0;0;R; |
||
|
||
|
Die kennt aber nur das, was zur entsprechenden FW-Version gehört. WT-min ist erst mit der 9xxx-FW gekommen. Wenn mich nicht alles täuscht, ist der Modbusmanager älter und dürfte das daher nicht kennen. Nibepi hat ja eine json-Datei mit den Registern, die wohl genauso aus einem Modbusmanager-Export entstanden ist. Da habe ich aber schon einige Lücken bemerkt und auf obige Weise gelöst. Wenn ich irgendwann mal Zeit habe (jetzt nicht... Homeoffice im Lehrbereich bedeutet extrem viel Arbeit), stelle ich das mal zusammen und veröffentliche es. |
||
|
||
|
Damit bekommt man aber bur die R/W Register, nicht die read-only. Die Pumpengeschwindigkeiten funktionieren bei mir immer noch nicht. WT-Pumpe bekomme ich gar nichts und bei der WQ-Pumpe immer 100 (auch wenn der Verdichter steht). Wärmemengenzähler muss ich nochmal vergleichen / durchsteigen. Nutze allerdings auch das Binding von OpenHab. Hat damit jemand Erfahrung? Viele Grüße, Klayman |
||
|
||
|
Bei mir funktionieren alle Register, u.a. Pumpengeschwindigkeiten und Wärmemengenzähler, die bei dir nicht funktionieren. Habe allerdings eine 1155. Welche openhab Version verwendest du? Ich kann mich erinnern, dass am Anfang nicht alle Register funktioniert haben. Ich habe dann das Nibe Binding manuell aktualisiert bzw. bin jetzt auf Milestone Releases umgestiegen. |
||
|
||
|
Die Version 2.5.3 und OpenHab von vor vier oder fünf Wochen. Kann die Software der Wärmepumpe noch was damit zu tun haben? Bin da glaube ich zwei oder drei Versionen hintendran... |
||
|
||
|
Ich habe auch die OH Version 2.5.3. FW der WPWP [Wärmepumpe] ist 9172R2 (ca. ein Jahr alt). |
||
|
||
|
ok, hab jetzt mal die FW der Wärmepumpe aktualisiert und die Register auch in der LOG.SET hinterlegt. Dabei habe ich entdeckt, dass das Item in der events.log erscheint und immer zwischen 70 und 1 hin und her springt (so im 10-15 Sekunden Takt). Dabei ist 70 der in der WPWP [Wärmepumpe] konfigurierte Maximalwert, die Daten müssen also richtig ankommen. Den Wert kann ich auch über die REST API auslesen, nur in der Oberfläche erscheint es nicht... Wie verhält es sich eigentlich mit der LOG.SET und den manuell ausgelesenen Registern, kann das Binding das unterscheiden? Bin jetzt erstmal an der WT-Pumpe, die restlichen Probleme folgen später |
||
|
||
|
Chrismo, Danke für den Tipp. Das Board Habe ich auch bestellt. Die Qualität ist top. Als UDP Server dient bei mir Wago Kontroller PFC200. Das Programm für die Auswertung der Datenpakete musste ich noch schreiben, jetzt läuft alles und ich habe endlich aktuelle Messwerte. Kombuination Uplink/IO-Broker/Wago war eine Zumutung. Die Daten kämmen fast immer fleißig, waren aber nicht genau und nicht aktuell. Bei mir funktionieren alle 20 Register sauber auch Pumpen und Energiewerte. Momentan kann ich nur lesen, schreiben werde ich später realisieren. |
||
|
||
|
Hallo chrismo, hier gibt es dazu Erfahrungen und Preise: DIY Alternative zu Nibe Modbus Modul |
||
|
||
|
Pumpe Quelle 43439 EP14-GP2 Brine Pump Status EP14 Pumpe WT 43437 Supply Pump Speed EP14 Energie Kompressor Heizung 44308 Heat Meter - Heat Cpr EP14 Energie Kompressor WW WW [Warmwasser] 42445 Heat Meter - HW Cpr - Total system |
||
|
||
|
Hallo. Habe auch eine pfc200 und möchte die integrieren. Kannst du mir sagen wie du das gemacht hast, bzw screenschots? Was hast du jtz am Arduino laufen? |
||
|
||
|
@NicoociN Das würde mich auch interessieren. Verwendest du auf dem MKR den openHAB Code, den ich modifiziert habe, oder hast du was eigenes geschrieben? |
||
|
||
|
Hallo zusammen, @chrismo Ich habe erst versucht die Daten per Modbus TCP zu versenden. Grundsätzlich funktioniert es auch, leider nicht stabil. WPWP [Wärmepumpe] meldet nach ein Paar Stunden Kommunikationsfehler. Wahrscheintlich MKR überfordet damit oder ich habe den Code nicht sauber geschrieben. Hatte bis jetzt mit Arduino nichts zutun. Mit von dir modifizierten Code läuft stabil, deswegen habe ich den genommen und Wago angepasst. Die Daten werden bei mir geloggt. Nach deren Auswertung habe ich festgestellt, dass die Pakete nicht immer gleich Lang sind. Mal 21 Byte (Pumpenmodel im Klartext) mal 6 Byte irgentwas und meistens 86 mit Messdaten. Erse beiden ignoriere ich und werte nur Paket mit 86Byte aus. @uzi10 bei Arduino habe ich nur IP Adressen angepasst. Bei SPS Funktionsbaustein UDP Packet Server, dann kommen Pakete schon an und müssen nur ausgewertet werden. Ich kann dir E!Cockpit (Codesys 3.5) Code zusenden. |
||
|
||
|
Der MKR müsste eigentlich performant genug sein. Ich bin auch nicht wirklich ein Arduino Programmierer, aber meist liegt es an der Implementierung, wenn irgendwas "hängt" (kann auch in einer Bibliothek passieren). Eigentlich sollte das dann aber der HW Watchdog verhindern, der das Board dann neu startet, bevor die WPWP [Wärmepumpe] in ein Timeout läuft und in den Fehlermodus geht (nach ca. ~10s). Ich hatte diese Woche den ersten WPWP [Wärmepumpe] Alarm wegen Modbus, seit ich das neue MKR Board im Einsatz habe. Passiert nach einem kompletten Stromausfall. Nachdem der Strom wieder da war, startete die WPWP [Wärmepumpe] neu und ging kurz drauf in den Fehlermodus. Nach aus-/einstecken des MKR hat es dann wieder funktioniert. Ich glaube schuld war der Cisco Switch, der nicht schnell genug bootete bzw. wegen Schleifenerkennung (STP) die Ethernet Ports noch eine Zeit lang blockiert. Das führte wohl dazu, dass das MKR Board beim Initialisieren des Ethernets hängen geblieben ist, weil das Ethernet Kabel zwar angesteckt ist, aber eben der Port noch blockiert ist. Ich habe jetzt beim Switch den Port so umgestellt, dass er sofort aktiv ist, und nach einem Neustart von WPWP [Wärmepumpe] und Switch ist kein Fehler mehr aufgetreten. Wie gesagt, eigentlich sollte der HW Watchdog das abfangen. Ich glaube dafür ist auch der ETH_INIT_DELAY Parameter im NibeGW Arduino Code gedacht. Wenn man das Delay groß genug einstellt, sollte man solche Probleme damit auch umgehen können. Ansonsten läuft das Modul sehr stabil. Habe auch verschiedene Tests gemacht wie abstecken des Ethernetkabels während des Betriebs, ausschalten des Switches, Neustart des MKR, deaktivieren/aktivieren von Modbus, etc. und keinen Fehler provozieren können. |
||
|
||
|
Weiter vorne haben wir dazu auch was geschrieben... so ein paar Seiten zurück. Wichtig ist der TYP der Nachricht. Das ist das VIERTE Byte. Hier gibt es (u.a.): 104 (0x68): Reguläre Nachricht mit den bis zu 20 Registern aus dem LOG.SET 105 (0x69): Lesetoken -> wenn das kommt, kann man danach eine Einzelleseanfrage senden 106 (0x6a): Leseantwort -> Hier kommt ein einzelner Wert, den man vorher abgefragt hat 107 (0x6b): Writetoken -> siehe oben, nur für Schreiben 109 (0x6d): Identifikation, das waren deine 21 Byte Du liest aktuell also nur Typ 104. Achtung! Der kann auch 87 oder 88 Byte lang sein. Die Bytefolge "0x5c" wird "escaped", also als 5c5c kodiert (0x5c ist nämlich das Startbyte). Jede Doppelung von 5c muss also entfernt werden. Das 5. Byte ist die Länge, und zwar inkl. der Escape-Bytes. Wie man die Lese- und die Schreibanforderung zusammenbaut, kann man sich im Quelltext von NibePi gut anschauen. |
||
|
||
|
Oder alternativ beim openHAB Nibe Binding: https://github.com/openhab/openhab-addons/tree/2.5.x/bundles/org.openhab.binding.nibeheatpump Und eine weiterer Spezialfall, der glaube ich anfangs auch vom NibePi Entwickler übersehen wurde: wenn die Checksumme zufällig "0x5c" ergibt, dann wird diese auf "0xc5" gesetzt. |
||
|
||
|
Das ist aber nur relevant, wenn man die Kommunikation mit der WPWP [Wärmepumpe] selbst machen will. Wenn man dafür NibeGW einsetzt (und das dann per UDP die Daten senden lässt), ist das Problem ja schon gelöst. |
||
|
||
|
War auf das bezogen. Anscheinend wurde es zuerst ohne NibeGW probiert. Ein Fehler nach ein paar Stunden kann evt. so ein Sonderfall sein, der nicht beachtet wurde. |
||
|
||
|
Yep. Das Problem hatte NibePi am Anfang ja auch. Auch der Autor von NibePi ist ja zuerst nur nach der Größe der Nachricht gegangen, bis wir das mit dem Escapen herausgefunden haben. Der Fehler tritt dann eben nur auf, wenn 0x5c in den Daten steht. Bei meinen Versuchen mit NibePi war das z.B. beim WW WW [Warmwasser] fast immer der Fall, wenn eine der Temperaturen durch diesen Bereich gelaufen ist... |
||
|
||
|
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 |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]