« Heizung, Lüftung, Klima  |

DIY Alternative zu Nibe Modbus Modul

Teilen: facebook    whatsapp    email
 
 1  2 ... 3 ... 13  14  15  16 ... 17 ... 49  50  51 
  •  chrismo
  •   Gold-Award
29.1.2019 - 25.4.2024
1.009 Antworten | 62 Autoren 1009
127
1136
Weil es hier immer wieder zu Diskussionen zum Thema Modbus-Anbindung der Nibe kommt, wollte ich hier mal kurz meine Erfahrungen mit dem Nachbau einer DiY Lösung, auf Basis von im Netz vorhandener Infos, teilen. Für mich war es eine Spielerei und Zeitvertreib der letzten Tage. Der Post dient vor allem als Speicherort für meine gesammelten Infos und evt. dem Austausch von Leuten, die das so oder so ähnlich bei sich installiert haben. Ich kann und will hier keine Empfehlung abgeben, sowas selbst zu machen!

Die Lösung basiert im Wesentlichen auf den Nibe Bindings von openHAB (https://www.openhab.org/addons/bindings/nibeheatpump/), das eine Umsetzung Modbus auf UDP macht. Infos zur Funktionsweise findet man auf der openHAB Seite bzw. dem entsprechenden github Repo.

Die grobe Vorgangsweise war folgend:
1) Auf einen Arduino mit Ethernet Shield und RS485 Adapter die NibeGW Software (Teil des Bindings) installieren. Der Ardunio Code muss dabei an die eigenen Netzwerkeinstellungen angepasst werden. 

2) Den Arduino an die Wärmepumpe und ans LAN anschließen.

3) Die Nibe Modbus Manager Software auf einem Rechner installieren und bis zu 20 Register auswählen, die periodisch von der Wärmepumpe exportiert werden sollen. Diese Konfig muss gespeichert und per USB-Stick auf die WPWP [Wärmepumpe] übertragen werden.

4) Das Modbus Modul in der WPWP [Wärmepumpe] aktivieren. Wenn alles geklappt hat, bleibt die Wärmepumpe im Normalbetrieb. Falls irgendwas bei der Kommunikation mit dem Arduino schief geht, wird eine Fehlermeldung am Display ausgegeben und die WPWP [Wärmepumpe] geht in einen Alarmmodus.

5) Das nibeopenhab Binding in openHAB installieren und konfigurieren.

zu 1) Man könnte dazu auch einen Raspberry Pi mit RS485 Adapter verwenden, auf dem dann auch openHAB selbst läuft. Das finde ich aber nicht optimal. Ein Pi wäre mir da nicht robust genug. Selbst ein einfacher Neustart des Pis würde zu einem Fehler der WPWP [Wärmepumpe] führen und ein SD-Kartenfehler wäre sowieso ungemütlich.

zu 5) Da ich derzeit noch nicht weiß ob es openHAB oder was anderes wird - über Erfahrungen bzw. Empfehlungen würde ich mich freuen(!) - habe ich das Binding so adaptiert, das es ohne openHAB läuft. Derzeit verwende ich die Log-Dateien dieses "Stand-Alone Bindings" zur Speicherung der Werte. Eine Erweiterung für "richtige" Ausgabeformate bzw. Kanäle (Umsetzung auf KNX wurde hier mal in einem anderen Thread diskutiert) wäre aber von hier weg leicht machbar.

von energiesparhaus

  •  klayman
17.4.2020  (#281)
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 emoji

1
  •  JanRi
  •   Gold-Award
17.4.2020  (#282)
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

1
  •  chrismo
  •   Gold-Award
19.4.2020  (#283)

zitat..
JanRi schrieb: 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.



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;

1
  •  JanRi
  •   Gold-Award
19.4.2020  (#284)

zitat..
chrismo schrieb: 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".

 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.


1
  •  klayman
19.4.2020  (#285)
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

1
  •  chrismo
  •   Gold-Award
19.4.2020  (#286)
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.

1
  •  klayman
20.4.2020  (#287)
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...

1
  •  chrismo
  •   Gold-Award
20.4.2020  (#288)
Ich habe auch die OH Version 2.5.3. FW der WPWP [Wärmepumpe] ist 9172R2 (ca. ein Jahr alt).

1
  •  klayman
21.4.2020  (#289)
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 emoji

1
  •  NicoociN
28.4.2020  (#290)

zitat..
chrismo schrieb: Ich hatte heuer zwei Modbus-Alarme. Nach Ab-/Anstecken bzw. Herumdrücken auf meinem DIY Modbus Modul ging es wieder. Wahrscheinlich eine kalte Lötstelle o.ä. bei einem Pin. Da ich keine Lust hatte, da jetzt nochmal die Löststellen zu kontrollieren, habe ich mir ein Prodino-Modul gekauft, das schon die Ethernet- bzw. Modbus-Schnittstelle integriert hat: https://kmpelectronics.eu/products/prodino-mkr-zero-ethernet-v1/

Das Board macht einen sehr guten Eindruck und ist qualitativ sicher mit dem offiziellen Nibe Modbus 40 Modul gleichwertig. Preis ca. 70 Eur inkl. Versand.

Eine ältere Version vom Prodino wird bereits von NibeGW unterstützt. Es waren aber ein paar kleine Anpassungen am Arduino Code nötig, da die neue Version nicht mehr auf einem Arduino Leonardo, sondern auf einem Arduino MKR basiert. Falls wer Interesse hat, kann ich gerne den Code schicken bzw. werde ich die Anpassungen an den NibeGW Maintainer weiterleiten, damit sie evt. ins openHAB Repository aufgenommen werden.

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.

1
  • ▾ Anzeige
    Energiesparhaus.at ist Teilnehmer des Amazon-Partnerprogramms, das zur Bereitstellung eines Mediums für Webseiten konzipiert wurde, mittels dessen durch die Platzierung von Partner-Links zu Amazon.de Entgelte verdient werden können.
Hallo chrismo,
hier gibt es dazu Erfahrungen und Preise: DIY Alternative zu Nibe Modbus Modul

  •  NicoociN
28.4.2020  (#291)

zitat..
klayman schrieb: 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

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

1
  •  uzi10
  •   Gold-Award
29.4.2020  (#292)

zitat..
NicoociN schrieb:
__________________
Im Beitrag zitiert von chrismo: Ich hatte heuer zwei Modbus-Alarme. Nach Ab-/Anstecken bzw. Herumdrücken auf meinem DIY Modbus Modul ging es wieder. Wahrscheinlich eine kalte Lötstelle o.ä. bei einem Pin. Da ich keine Lust hatte, da jetzt nochmal die Löststellen zu kontrollieren, habe ich mir ein Prodino-Modul gekauft, das schon die Ethernet- bzw. Modbus-Schnittstelle integriert hat: https://kmpelectronics.eu/products/prodino-mkr-zero-ethernet-v1/

Das Board macht einen sehr guten Eindruck und ist qualitativ sicher mit dem offiziellen Nibe Modbus 40 Modul gleichwertig. Preis ca. 70 Eur inkl. Versand.

Eine ältere Version vom Prodino wird bereits von NibeGW unterstützt. Es waren aber ein paar kleine Anpassungen am Arduino Code nötig, da die neue Version nicht mehr auf einem Arduino Leonardo, sondern auf einem Arduino MKR basiert. Falls wer Interesse hat, kann ich gerne den Code schicken bzw. werde ich die Anpassungen an den NibeGW Maintainer weiterleiten, damit sie evt. ins openHAB Repository aufgenommen werden.

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. 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?


1
  •  chrismo
  •   Gold-Award
29.4.2020  (#293)

zitat..
uzi10 schrieb: 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?

1
  •  NicoociN
30.4.2020  (#294)
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.

1
  •  chrismo
  •   Gold-Award
30.4.2020  (#295)

zitat..
NicoociN schrieb: 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,


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.

1
  •  JanRi
  •   Gold-Award
30.4.2020  (#296)

zitat..
NicoociN schrieb: 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.

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.


1
  •  chrismo
  •   Gold-Award
30.4.2020  (#297)

zitat..
JanRi schrieb: 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

zitat..
JanRi schrieb: Die Bytefolge "0x5c" wird "escaped", also als 5c5c kodiert (0x5c ist nämlich das Startbyte).


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.

1
  •  JanRi
  •   Gold-Award
1.5.2020  (#298)

zitat..
chrismo schrieb: 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.


1
  •  chrismo
  •   Gold-Award
1.5.2020  (#299)

zitat..
NicoociN schrieb: @­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.

 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.

1
  •  JanRi
  •   Gold-Award
1.5.2020  (#300)

zitat..
chrismo schrieb: 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...


1
  •  NicoociN
2.5.2020  (#301)

zitat..
JanRi schrieb:
__________________
Im Beitrag zitiert von NicoociN: 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.

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.

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

1


Beitrag schreiben oder Werbung ausblenden?
Einloggen

 Kostenlos registrieren [Mehr Infos]


next