Neue Insider Version IP 3
NEUES Widget: Energieflussmonitor
NEUES Widget: Navigationswidget
Upgrade Gebäudeinformationssystem
Alle Informationen hier: https://elabnet.atlassian.net/wiki/x/AYDOmQ
NEUES Widget: Energieflussmonitor
NEUES Widget: Navigationswidget
Upgrade Gebäudeinformationssystem
Alle Informationen hier: https://elabnet.atlassian.net/wiki/x/AYDOmQ
[DISKUSSION] Helios KWL an Modbus TCP/IP per TWS
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 3771
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1328 Mal
- Danksagung erhalten: 1760 Mal
Helios KWL an Modbus TCP/IP per TWS
Hallo zusammen,
Modbus ist ja nun das nächste große Thema am TWS.
Um hier mal ein praktisches Versuchsobjekt beizusteuern habe ich mir eben mal meine KWL von Helios angeschaut. Ich hatte da mal was im Kopf das man die ja mit einigen RPI-Bastelprojekten steuern konnte und irgendwie hatte ich da auch Modbus im Kopf.
Also mal eben google bemüht und bin da auch direkt bei Helios im Download-Bereich gelandet.
Für die aktuellen Helios KWL-Geräte die das Easoycontrol System als Steuerung haben gibt es wohl eine native Modbus TCP/IP Schnittstelle.
https://www.easycontrols.net/de/service ... 4-software.
Und wenn ich das richtig grob überfliege scheint mir dieses pdf im Anhang auch eine sehr gut dokumentierte Schnittstelle zu sein. Die Anzahl an Parametern die da in der Steuerung angesprochen werden können, lesend als auch schreibend ist schon enorm. Und wenn ich die Tabelle richtig deute kann man auch ganz gut die interne Regelung laufen lassen, aber für Temperatur / Luftfeuchte und VOC gern extern also via TWS und 1-wire Werte reinschreiben. Das wäre ja mal eine tolle Sache. Dann braucht es im TWS eigentlich keine komplexe Lüftersteuerung wenn das da drinenn gut geht.
Wobei man die Drehzahlen aller einzelner Ventilatoren der KWL über die Spannungsregler wohl auch einstellen kann.
Das schaut alles nach ein paar Wochen Urlaub aus um das alles mal auszuprobieren.
Oder interpretiere ich da was falsch in die Angaben?
Irgendwer hier in der Runde der auch ne Helios mit Eayscontrol verbaut hat?
@StefanW
Neben der Solarelemente, die wohl viel mit Modbus machen, womöglich auch ein interessantes Objekt für die Kundschaft.
Im KNX-UF wird ja auch immer oft gefragt welche KWL kann man empfehlen, weil sie gut in den KNX integrierbar ist. Wenn das mit dem Modbus im TWS gut zu bedienen ist, ist das für mich zukünftig auf jeden Fall immer eine Empfehlung TWS+Helios.
Modbus ist ja nun das nächste große Thema am TWS.
Um hier mal ein praktisches Versuchsobjekt beizusteuern habe ich mir eben mal meine KWL von Helios angeschaut. Ich hatte da mal was im Kopf das man die ja mit einigen RPI-Bastelprojekten steuern konnte und irgendwie hatte ich da auch Modbus im Kopf.
Also mal eben google bemüht und bin da auch direkt bei Helios im Download-Bereich gelandet.
Für die aktuellen Helios KWL-Geräte die das Easoycontrol System als Steuerung haben gibt es wohl eine native Modbus TCP/IP Schnittstelle.
https://www.easycontrols.net/de/service ... 4-software.
Und wenn ich das richtig grob überfliege scheint mir dieses pdf im Anhang auch eine sehr gut dokumentierte Schnittstelle zu sein. Die Anzahl an Parametern die da in der Steuerung angesprochen werden können, lesend als auch schreibend ist schon enorm. Und wenn ich die Tabelle richtig deute kann man auch ganz gut die interne Regelung laufen lassen, aber für Temperatur / Luftfeuchte und VOC gern extern also via TWS und 1-wire Werte reinschreiben. Das wäre ja mal eine tolle Sache. Dann braucht es im TWS eigentlich keine komplexe Lüftersteuerung wenn das da drinenn gut geht.
Wobei man die Drehzahlen aller einzelner Ventilatoren der KWL über die Spannungsregler wohl auch einstellen kann.
Das schaut alles nach ein paar Wochen Urlaub aus um das alles mal auszuprobieren.
Oder interpretiere ich da was falsch in die Angaben?
Irgendwer hier in der Runde der auch ne Helios mit Eayscontrol verbaut hat?
@StefanW
Neben der Solarelemente, die wohl viel mit Modbus machen, womöglich auch ein interessantes Objekt für die Kundschaft.
Im KNX-UF wird ja auch immer oft gefragt welche KWL kann man empfehlen, weil sie gut in den KNX integrierbar ist. Wenn das mit dem Modbus im TWS gut zu bedienen ist, ist das für mich zukünftig auf jeden Fall immer eine Empfehlung TWS+Helios.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
-
- Reactions:
- Beiträge: 3800
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1207 Mal
- Danksagung erhalten: 2101 Mal
Sehr interessant!
Durchaus überraschend, wieviel da geht bzw. zugelassen wird.
Ich finde auch die genannten Tools modpoll.exe etc. sehr hilfreich, denn so kann man die Supportfälle auch gering halten, sprich erst wenn das mit den Tools läuft und am TWS in der Umsetzung was spießt, dann ist man hier im Forum richtig. Vorher soll der Herstellersupport gequält werden.
Lg
Robert
Durchaus überraschend, wieviel da geht bzw. zugelassen wird.
Ich finde auch die genannten Tools modpoll.exe etc. sehr hilfreich, denn so kann man die Supportfälle auch gering halten, sprich erst wenn das mit den Tools läuft und am TWS in der Umsetzung was spießt, dann ist man hier im Forum richtig. Vorher soll der Herstellersupport gequält werden.
Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Elaborated Networks
- Reactions:
- Beiträge: 10199
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5041 Mal
- Danksagung erhalten: 8198 Mal
- Kontaktdaten:
Hallo Göran,
danke sehr (und mein herzliches Beileid).
==> Kannst Du uns im Alpha-Bereich die IP-Adresse nennen, weil dann würden wir da gerne remote ein paar Abfrageversuche durchführen, weil das Geräte ist besonders....
Kurz, kommen wir zur Beileidsbekundung
Noch kein Drama - 1. Akt - Ein gutes Dokument verspricht einen guten Start und ein wohlwollendes Ende ohne Überraschungen
Die Formatierung des Dokumentes von Göran ist wirklich super und macht auf den unbedarften Leser einen tollen ersten Eindruck. Beim ersten darüberfliegen dachte ich mir auch, das ist eine selten gute Beschreibung der Modbus Implementierung.
Es wird Spannend - 2. Akt - Sieht nach einer Menge Funktionen aus. Wunderbar. Aber wo sind die Registeradressen?
Den Anfang des Dokuments habe ich erstmal überhüpft, schließlich kenne ich die Modbus Grundlagen. Dachte ich. Also erstmal in die Tabellen in der Mitte des Protokolls vertieft, man will ja wissen, was man so alles steuern kann.
Ja, da gibt es wohl jede Menge, sieht erstmal ordentlich aus. Sehen wir uns mal die Details an.
Hmm, kopfkratz, wo sind denn nun die Adressen der Modbus Register (dazu muss man sagen, dass ist überall ein kleines Drama, weil diese essentielle Information ist bei jedem Hersteller immer ein wenig kryptisch und versteckt, da wird mit verschiedenen Offsets gearbeitet und mal in Dezimal und mal in Hex und manchmal muss man noch den Function-Code Offset dazurechnen, also leider meist ein bisserl doof gemacht, deswegen habe ich das eigentliche große Drama nicht sofort erkannt).
Ich rolle mit den Augenbrauen, also irgendwie hat der Hersteller das in einer neuen Variante angegeben, die mir in den Dutzenden anderer Modbus Beschreibungen bislang nicht untergekommen ist. Ok, dazu lernen können wir ja, das Wetter ist eh Mist. Und ich liebe ja Herausforderungen.
Drama - 3. Akt - Mich trifft der Schlag. Es kommt zu ersten Wortfindungsstörungen
Ich lese weiter in der Tabelle und sehe unter "Type" immer char[n] und einen ominösen "Count" und eine sehr ominöse "Variable". Das kenne ich nicht.
Bei Modbus hat zwar einen einen Typ und sowas ähnliches wie Count (Anzahl der 16 Bit Register), aber Variable gibt es nur als Name, nicht als was funktionales, weil dafür hat man in Modbus die Adresse des Registers (wenn auch durchaus verklausuliert angegeben).
Aber alles in char? Auch nummerische Werte? Und warum hat eine Temperatur 7 chars?
Muss ich irgendwas an Modbus in den letzten sechs Monaten überlesen haben. Klar, kann schon passieren, zuerst immer den Fehler bei sich suchen. Fangen wir einfach mal etwas weiter vorne an, das mit den Char wollte ich doch jetzt kapieren. Lesen, staunen, lesen, kopfschütteln, lesen, schaum vor dem Mund. Ich bin erstmal sprachlos. Habe für Minuten Wortfindungssörungen. Laufe aufgeregt durch das Haus, meine Frau wundert sich über meinen Blick und das Kopfgeschüttel und das undeutliche Gemurmel. Sie sieht mich aufmunternd an und frägt "Forum ?" ich nicke kurz - sie nennt es den Forenblick - und ich ziehe erstmal weiter. Kaffee machen, an die frische Luft.
What in the hell machen die da eigentlich?
Um die Temperatur "25,5" (Grad Celsius) auszugeben, schreiben die doch tatsächlich den String "V00104=25.500000" in Register. Nicht in ein Register, sie verbrauchen dafür acht (8) ganze 16 Bit Register, weil die anstatt einem einfachen Integer einfach einen Kurzroman in acht Register schreiben.
Wenn wir uns jetzt im vergangenen Jahrtausend befinden würden, dann wäre das unter Absingen hässlicher Lieder ja womöglich noch verzeihlich, aber im Jahre 2020 den String "V00104=25.500000" auszugeben nur um "25,5" (Grad Celsius) zu übergeben ist das (aller-aller-aller)-schlechteste Codierungsbeispiel dass mir in mehreren Monaten Modbus Recherche untergekommen ist.
Für den Mitleser, so einen einfachen Zahlenwert kann man einfach in Festkomma-Integer als "255" speichern und braucht dann auch nur EINES der 16 Bit breiten Register. Oder für die Meister der fortschrittlichen Programmiertechnik als vorzeichenbehaftetes Fließkomma.
OMG und die schicken hier tatsächlich komplex formatierte ASCII Zeichenketten. Sowas habe ich zuletzt an Großrechnern gesehen aus den 60er Jahren über die man noch mit Fernschreibern kommuniziert hat und nur 5 Bit pro Zeichen zur Verfügung hatten.
Nein, wir sind noch nicht bei den Eimern. Ich dachte eigentlich nicht, dass es schlimmer kommt.
Großes Drama - 4. Akt - Brutal, hart und völlig unvorbereitet trifft mich die Wahrheit. Schock
Während ich noch diesen Codierungsmist überlege, inklusive Übergabe Null-terminierter Strings (Grüße an alle C Programmierer) suche ich immer noch meine Registeradressen.
Kurz zur Erklärung. Das ist bei Modbus so ein wenig wie auf dem Postamt bei den Postfächern oder an der Packstation. Für jeden Wert (= Empfänger) gibt es ein Fach (bei großen Werten sind auch mal mehrere unter einer Klappe zusammen) und darin ist dann der Wert. Also in Fach 1 für Temperatur, in Fach 2 für Luftfeuchte und in Fach 3 für VOC. Kennen wir auch von KNX so, da hat ein Sensor mehrere Objekte und die verbindet man mit GAs und wenn man nun eine GA abfrägt dann bekommt man den Wert von dem Objekt zurück. Nix besonderes.
Damit man also den richtigen Wert (Fach) adressieren kann, braucht man in der Liste auch die Nummern des Faches - äh - des Modbus Registers. Und manchmal auch die Breite, wenn der Wert so kodiert ist, dass er nicht in ein Fach - äh - in 16 Bit passt (lassen wir die Spezialität mit den 1 Bit Coils in Modbus mal zur Seite).
Warum haben die das hier nicht einfach hingeschrieben, zefix, muss man es einem so schwer machen?
Ok, also zurück an Anfang, gehe nicht über Los, ziehe keine Freizeit am Sonntag ein, die Kunden wollen schließlich die KWL steuern können.
Ich lese und lese. Und stocke. Ne, echt jetzt, das hab ich jetzt bestimmt falsch verstanden. Nochmal ganz kurz. Blutdruckmesser angeschlossen, 200 zu 180, das ist ungesund. Raus ins Freie, es nieselt, das kühlt ab.
Nochmal überlegt, was ich da gerade gelesen habe, das ist, nee, das glaube ich nicht, bin bestimmt überarbeitet.
Erfrischt, mit ordentlich sauberen Sauerstoff in Lunge und Adern wieder zurück an das pdf und nochmal lesen. Ganz langsam, damit wir nix übersehen.
Die mit großem Unglauben vernommene bittere Vermutung weicht der Erkenntnis, dass irgendeiner von uns beiden - das pdf oder ich - dem anderen einen Streich spielen will.
Ich hole die Eimer, sicher ist sicher. Mir wird grün im Gesicht
Die Beispiele jetzt genau ansehen. Hex für Hex vergleichen, die Aufrufparameter von dem Tool lernen, die Beispiele verinnerlichen. Ich glaube ich will weg hier und zwar schnell
Einmal alles vollkotzen, raus gehen, Baum anschreien.
Es trifft mich wie ein Schlag. Das ist ja gar kein Modbus. Also nicht im üblichen Sinn. Das ist ein selbst gebasteltes Protokoll das in einem Modbus Frame versendet wird. Ich weiß gar nicht wie ich das beschreiben soll.
Versuch einer Beschreibung:
Gehen wir nochmal zum Postamt wegen der Postfächer. Aber nicht zum normalen Postamt, sodern zu dem von Helios. Wir kommen rein und sehen dort ein Postfach. Eines. Nicht mehrere. Nicht mit verschiedenen Nummern zum einfach greifen und mitnehmen, sondern ein einziges Postfach. Für alles.
Wie komme ich nun an meine Post - äh - Werte?
1. Man nimmt einen Zettel, schreibt dort in ASCII auf, welche Werte man lesen möchte, zum Beispiel "v00004\0" um das Datum auszulesen.
Hinweis: Das "\0" steht für Null-terminierter Sting, also sowas wie "NIL" in ASCII ["00" in Hex].
2. Dann schließt man die Klappe (das Datentelegram)
3. Als nächstes liegt dann die Post - äh - der Wert für das aktuelle Datum der KWL im gleichen Fach. Im Beispiel der Dokumentation wird das dann zurück übergeben mit "v00004=11.12.0013\0"
Was soll das? Das ganze schöne Konzept der 65.000 möglichen Registernummern - eines für jeden Wert - total verhunzt für ein total verrücktes "Scratchpad" Austauschformat? Das konnten die in Frankreich damals ja noch mit den Semaphoren besser.
Oder in KNX Sprech: Es gibt nur ein Objekt und eine GA. Wenn man einen Wert von einem (solchen total verkrüpelten KNX Sensor) lesen wollen würde, müsste man auf der GA eine "v0000x\0" schreiben (nicht leseanfrage, sondern ganz normal schreiben), auf dass man dann anschließend eine Leseanfrage auf der gleichen GA schicken kann, um nun den Inhalt dieses einen verfügbaren KNX Objektes auszulesen, wobei man eine lange ASCII-Zeichenfolge erhält, die einen schönen Zahlenwert - inklusive dem Dezimalpunkt als Punkt [Hex "2E"] - sendet.
Echt jetzt Helios? Meint ihr das tatsächlich ernst im Jahre 2020? Das hat mit Modbus nicht wirklich was zu tun. Weder sind die Werte in "Hex-ASCII" kodiert (was die bei Modbus etwas unpassend als ASCII bezeichnet, weil sie jede Hex-Stelle auf 8 Bit als 7 Bit ASCII Buchstaben senden) noch in normalem 8 Bit Datenforma, dafür als Helios-proprietäres-ASCII-Buchstaben-Zahlen-Dezimalpunkt-String-Gemisch und anstelle diese wunderschöne Registervielfalt zu nutzen, morst man das ganze umständlich über ein und dieselbe Adresse, nur mit unterschiedlicher Länge?
Das Urteil - 5. Akt - Ignoranz
Im Namen der Anwender ergeht folgendes Urteil. So ein Mist wird abgelehnt.
Bitte setzt Euch hin, lest die Modbus Spezifikation und dann setzt das dann auch biite konform um.
Bitte schreibt in großen klaren Worten in Eure jetzige Dokumentation, dass Eure Implementierung von "Modbus" so stark vom üblichen abweicht, dass die Bezeichnung "Modbus" eigentlich nur schwerlich vertretbar ist und die üblichen Adressierungs- und Kodierungskonzepte von Modbus nicht wirklich beachtet werden. Mithin dass man mit der meisten Modbus-Software bzw. Modbus Gateways nicht wirklich arbeiten kann.
Alternativ sind wir unter Einwurf klingender Münzen gerne bereit, eine eigene Implementierung des Helios-Spezial-Protokolls vorzunehmen.
Mach ein Sabatical draus.
Das umzusetzen bedeutet, das ganze Modbus Konzept und die Datenstruktur, den Config-Editor - alles was darauf beruht das "ein Register - ein Wert" beruht können wir in die Tonne treten. Das kostet uns einen unteren fünfstelligen Betrag für diese völlig abweichende Implementierung.
Der Vorteil ist natürlich, das kann vermutlich kein anderes KNX-to-Modbus Gateway, das wäre ein echtes Alleinstellungsmerkmal. Aber wie soll ich meinen Entwicklern das verkaufen. Wir wollen doch auch Spaß an der Arbeit haben.
Ich bin echt ein wenig ratlos damit. Was meint ihr?
Das mindeste ist, dass Du bei denen mal anfrägst, ob die das Dokument vom letzten ersten April versehentlich haben liegengelassen. Oder ob sie das mit einer neuen Firmware ändern, weil Ihnen das schon mehrere hundert Leute um die Ohren gehaut haben. Aber vielleicht täusche ich mich ja und alles ist ganz normal so, schließlich soll man ja Kreativität unter Entwicklern fördern und nichts ist so spannend, wenn man das eine drauf schreibt und dann im Detail was anderes macht.
Falls ich jemandem auf den Schlips getreten bin, bitte ich um Entschuldigung.
lg
Stefan
danke sehr (und mein herzliches Beileid).
Ja, in dichter Folge mit MQTT und Rest-/Web-API. Wir implementieren zwar Modbus zuerst, allerdings werden sehr viele Designmerkmale für alles drei verwendet, auch von der Architektur, Editoren usw. so dass wir hoffen, dass wir in schneller Folge dann auch MQTT und Web-Schnittstellen hinbekommen. Das wird also ein heftiges Feuerwerk an Möglichkeiten im Spätsommer - Winter geben und DMX und anderes gewünschtes vergessen wir nicht dabei.
Ist diese freigeschaltet?
==> Kannst Du uns im Alpha-Bereich die IP-Adresse nennen, weil dann würden wir da gerne remote ein paar Abfrageversuche durchführen, weil das Geräte ist besonders....
Ich habe es mir durchgelesen, gestutzt, nochmal gelesen, am Kopf gekrazt, nochmal gelesen, das Drama erfassend zehn Eimer vollgekotzt, zwischendurch alles aufgewischt, bin raus, habe ein paar Bäume angeschrieben, das Universum um eine Erklärung gebeten und mich nun niedergeschlagen und leicht entrücktem Blick wieder hier an den Computer gesetzt.
Kurz, kommen wir zur Beileidsbekundung
Noch kein Drama - 1. Akt - Ein gutes Dokument verspricht einen guten Start und ein wohlwollendes Ende ohne Überraschungen
Die Formatierung des Dokumentes von Göran ist wirklich super und macht auf den unbedarften Leser einen tollen ersten Eindruck. Beim ersten darüberfliegen dachte ich mir auch, das ist eine selten gute Beschreibung der Modbus Implementierung.
Es wird Spannend - 2. Akt - Sieht nach einer Menge Funktionen aus. Wunderbar. Aber wo sind die Registeradressen?
Den Anfang des Dokuments habe ich erstmal überhüpft, schließlich kenne ich die Modbus Grundlagen. Dachte ich. Also erstmal in die Tabellen in der Mitte des Protokolls vertieft, man will ja wissen, was man so alles steuern kann.
Ja, da gibt es wohl jede Menge, sieht erstmal ordentlich aus. Sehen wir uns mal die Details an.
Hmm, kopfkratz, wo sind denn nun die Adressen der Modbus Register (dazu muss man sagen, dass ist überall ein kleines Drama, weil diese essentielle Information ist bei jedem Hersteller immer ein wenig kryptisch und versteckt, da wird mit verschiedenen Offsets gearbeitet und mal in Dezimal und mal in Hex und manchmal muss man noch den Function-Code Offset dazurechnen, also leider meist ein bisserl doof gemacht, deswegen habe ich das eigentliche große Drama nicht sofort erkannt).
Ich rolle mit den Augenbrauen, also irgendwie hat der Hersteller das in einer neuen Variante angegeben, die mir in den Dutzenden anderer Modbus Beschreibungen bislang nicht untergekommen ist. Ok, dazu lernen können wir ja, das Wetter ist eh Mist. Und ich liebe ja Herausforderungen.
Drama - 3. Akt - Mich trifft der Schlag. Es kommt zu ersten Wortfindungsstörungen
Ich lese weiter in der Tabelle und sehe unter "Type" immer char[n] und einen ominösen "Count" und eine sehr ominöse "Variable". Das kenne ich nicht.
Bei Modbus hat zwar einen einen Typ und sowas ähnliches wie Count (Anzahl der 16 Bit Register), aber Variable gibt es nur als Name, nicht als was funktionales, weil dafür hat man in Modbus die Adresse des Registers (wenn auch durchaus verklausuliert angegeben).
Aber alles in char? Auch nummerische Werte? Und warum hat eine Temperatur 7 chars?
Muss ich irgendwas an Modbus in den letzten sechs Monaten überlesen haben. Klar, kann schon passieren, zuerst immer den Fehler bei sich suchen. Fangen wir einfach mal etwas weiter vorne an, das mit den Char wollte ich doch jetzt kapieren. Lesen, staunen, lesen, kopfschütteln, lesen, schaum vor dem Mund. Ich bin erstmal sprachlos. Habe für Minuten Wortfindungssörungen. Laufe aufgeregt durch das Haus, meine Frau wundert sich über meinen Blick und das Kopfgeschüttel und das undeutliche Gemurmel. Sie sieht mich aufmunternd an und frägt "Forum ?" ich nicke kurz - sie nennt es den Forenblick - und ich ziehe erstmal weiter. Kaffee machen, an die frische Luft.
What in the hell machen die da eigentlich?
Um die Temperatur "25,5" (Grad Celsius) auszugeben, schreiben die doch tatsächlich den String "V00104=25.500000" in Register. Nicht in ein Register, sie verbrauchen dafür acht (8) ganze 16 Bit Register, weil die anstatt einem einfachen Integer einfach einen Kurzroman in acht Register schreiben.
Wenn wir uns jetzt im vergangenen Jahrtausend befinden würden, dann wäre das unter Absingen hässlicher Lieder ja womöglich noch verzeihlich, aber im Jahre 2020 den String "V00104=25.500000" auszugeben nur um "25,5" (Grad Celsius) zu übergeben ist das (aller-aller-aller)-schlechteste Codierungsbeispiel dass mir in mehreren Monaten Modbus Recherche untergekommen ist.
Für den Mitleser, so einen einfachen Zahlenwert kann man einfach in Festkomma-Integer als "255" speichern und braucht dann auch nur EINES der 16 Bit breiten Register. Oder für die Meister der fortschrittlichen Programmiertechnik als vorzeichenbehaftetes Fließkomma.
OMG und die schicken hier tatsächlich komplex formatierte ASCII Zeichenketten. Sowas habe ich zuletzt an Großrechnern gesehen aus den 60er Jahren über die man noch mit Fernschreibern kommuniziert hat und nur 5 Bit pro Zeichen zur Verfügung hatten.
Nein, wir sind noch nicht bei den Eimern. Ich dachte eigentlich nicht, dass es schlimmer kommt.
Großes Drama - 4. Akt - Brutal, hart und völlig unvorbereitet trifft mich die Wahrheit. Schock
Während ich noch diesen Codierungsmist überlege, inklusive Übergabe Null-terminierter Strings (Grüße an alle C Programmierer) suche ich immer noch meine Registeradressen.
Kurz zur Erklärung. Das ist bei Modbus so ein wenig wie auf dem Postamt bei den Postfächern oder an der Packstation. Für jeden Wert (= Empfänger) gibt es ein Fach (bei großen Werten sind auch mal mehrere unter einer Klappe zusammen) und darin ist dann der Wert. Also in Fach 1 für Temperatur, in Fach 2 für Luftfeuchte und in Fach 3 für VOC. Kennen wir auch von KNX so, da hat ein Sensor mehrere Objekte und die verbindet man mit GAs und wenn man nun eine GA abfrägt dann bekommt man den Wert von dem Objekt zurück. Nix besonderes.
Damit man also den richtigen Wert (Fach) adressieren kann, braucht man in der Liste auch die Nummern des Faches - äh - des Modbus Registers. Und manchmal auch die Breite, wenn der Wert so kodiert ist, dass er nicht in ein Fach - äh - in 16 Bit passt (lassen wir die Spezialität mit den 1 Bit Coils in Modbus mal zur Seite).
Warum haben die das hier nicht einfach hingeschrieben, zefix, muss man es einem so schwer machen?
Ok, also zurück an Anfang, gehe nicht über Los, ziehe keine Freizeit am Sonntag ein, die Kunden wollen schließlich die KWL steuern können.
Ich lese und lese. Und stocke. Ne, echt jetzt, das hab ich jetzt bestimmt falsch verstanden. Nochmal ganz kurz. Blutdruckmesser angeschlossen, 200 zu 180, das ist ungesund. Raus ins Freie, es nieselt, das kühlt ab.
Nochmal überlegt, was ich da gerade gelesen habe, das ist, nee, das glaube ich nicht, bin bestimmt überarbeitet.
Erfrischt, mit ordentlich sauberen Sauerstoff in Lunge und Adern wieder zurück an das pdf und nochmal lesen. Ganz langsam, damit wir nix übersehen.
Die mit großem Unglauben vernommene bittere Vermutung weicht der Erkenntnis, dass irgendeiner von uns beiden - das pdf oder ich - dem anderen einen Streich spielen will.
Ich hole die Eimer, sicher ist sicher. Mir wird grün im Gesicht
Die Beispiele jetzt genau ansehen. Hex für Hex vergleichen, die Aufrufparameter von dem Tool lernen, die Beispiele verinnerlichen. Ich glaube ich will weg hier und zwar schnell
Einmal alles vollkotzen, raus gehen, Baum anschreien.
Es trifft mich wie ein Schlag. Das ist ja gar kein Modbus. Also nicht im üblichen Sinn. Das ist ein selbst gebasteltes Protokoll das in einem Modbus Frame versendet wird. Ich weiß gar nicht wie ich das beschreiben soll.
Versuch einer Beschreibung:
Gehen wir nochmal zum Postamt wegen der Postfächer. Aber nicht zum normalen Postamt, sodern zu dem von Helios. Wir kommen rein und sehen dort ein Postfach. Eines. Nicht mehrere. Nicht mit verschiedenen Nummern zum einfach greifen und mitnehmen, sondern ein einziges Postfach. Für alles.
Wie komme ich nun an meine Post - äh - Werte?
1. Man nimmt einen Zettel, schreibt dort in ASCII auf, welche Werte man lesen möchte, zum Beispiel "v00004\0" um das Datum auszulesen.
Hinweis: Das "\0" steht für Null-terminierter Sting, also sowas wie "NIL" in ASCII ["00" in Hex].
2. Dann schließt man die Klappe (das Datentelegram)
3. Als nächstes liegt dann die Post - äh - der Wert für das aktuelle Datum der KWL im gleichen Fach. Im Beispiel der Dokumentation wird das dann zurück übergeben mit "v00004=11.12.0013\0"
Was soll das? Das ganze schöne Konzept der 65.000 möglichen Registernummern - eines für jeden Wert - total verhunzt für ein total verrücktes "Scratchpad" Austauschformat? Das konnten die in Frankreich damals ja noch mit den Semaphoren besser.
Oder in KNX Sprech: Es gibt nur ein Objekt und eine GA. Wenn man einen Wert von einem (solchen total verkrüpelten KNX Sensor) lesen wollen würde, müsste man auf der GA eine "v0000x\0" schreiben (nicht leseanfrage, sondern ganz normal schreiben), auf dass man dann anschließend eine Leseanfrage auf der gleichen GA schicken kann, um nun den Inhalt dieses einen verfügbaren KNX Objektes auszulesen, wobei man eine lange ASCII-Zeichenfolge erhält, die einen schönen Zahlenwert - inklusive dem Dezimalpunkt als Punkt [Hex "2E"] - sendet.
Echt jetzt Helios? Meint ihr das tatsächlich ernst im Jahre 2020? Das hat mit Modbus nicht wirklich was zu tun. Weder sind die Werte in "Hex-ASCII" kodiert (was die bei Modbus etwas unpassend als ASCII bezeichnet, weil sie jede Hex-Stelle auf 8 Bit als 7 Bit ASCII Buchstaben senden) noch in normalem 8 Bit Datenforma, dafür als Helios-proprietäres-ASCII-Buchstaben-Zahlen-Dezimalpunkt-String-Gemisch und anstelle diese wunderschöne Registervielfalt zu nutzen, morst man das ganze umständlich über ein und dieselbe Adresse, nur mit unterschiedlicher Länge?
Das Urteil - 5. Akt - Ignoranz
Im Namen der Anwender ergeht folgendes Urteil. So ein Mist wird abgelehnt.
Bitte setzt Euch hin, lest die Modbus Spezifikation und dann setzt das dann auch biite konform um.
Bitte schreibt in großen klaren Worten in Eure jetzige Dokumentation, dass Eure Implementierung von "Modbus" so stark vom üblichen abweicht, dass die Bezeichnung "Modbus" eigentlich nur schwerlich vertretbar ist und die üblichen Adressierungs- und Kodierungskonzepte von Modbus nicht wirklich beachtet werden. Mithin dass man mit der meisten Modbus-Software bzw. Modbus Gateways nicht wirklich arbeiten kann.
Alternativ sind wir unter Einwurf klingender Münzen gerne bereit, eine eigene Implementierung des Helios-Spezial-Protokolls vorzunehmen.
Ob ich das noch glauben kann?gbglace hat geschrieben: ↑So Jun 07, 2020 12:37 pmDie Anzahl an Parametern die da in der Steuerung angesprochen werden können, lesend als auch schreibend ist schon enorm. Und wenn ich die Tabelle richtig deute kann man auch ganz gut die interne Regelung laufen lassen, aber für Temperatur / Luftfeuchte und VOC gern extern also via TWS und 1-wire Werte reinschreiben. Das wäre ja mal eine tolle Sache. Dann braucht es im TWS eigentlich keine komplexe Lüftersteuerung wenn das da drinnen gut geht.
Oder interpretiere ich da was falsch in die Angaben?
Mach ein Sabatical draus.
Ich hoffe nicht.
Ja, das ist echt eine Herausforderung
Was soll ich sagen?
Das umzusetzen bedeutet, das ganze Modbus Konzept und die Datenstruktur, den Config-Editor - alles was darauf beruht das "ein Register - ein Wert" beruht können wir in die Tonne treten. Das kostet uns einen unteren fünfstelligen Betrag für diese völlig abweichende Implementierung.
Der Vorteil ist natürlich, das kann vermutlich kein anderes KNX-to-Modbus Gateway, das wäre ein echtes Alleinstellungsmerkmal. Aber wie soll ich meinen Entwicklern das verkaufen. Wir wollen doch auch Spaß an der Arbeit haben.
Ich bin echt ein wenig ratlos damit. Was meint ihr?
Das mindeste ist, dass Du bei denen mal anfrägst, ob die das Dokument vom letzten ersten April versehentlich haben liegengelassen. Oder ob sie das mit einer neuen Firmware ändern, weil Ihnen das schon mehrere hundert Leute um die Ohren gehaut haben. Aber vielleicht täusche ich mich ja und alles ist ganz normal so, schließlich soll man ja Kreativität unter Entwicklern fördern und nichts ist so spannend, wenn man das eine drauf schreibt und dann im Detail was anderes macht.
Falls ich jemandem auf den Schlips getreten bin, bitte ich um Entschuldigung.
lg
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 65
- Registriert: Mo Sep 10, 2018 3:10 pm
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 68 Mal
Das klingt nicht gut.
Im KNX-UF gibt es einen Thread zum ähnlichen Thema. Offensichtlich nimmt die Helios von außen noch nicht einmal Sensorwerte wie Feuchte, Temperatur oder Luftqualität entgegen. Auch der Bypass lässt sich von extern nicht steuern (Stand 2016).
Bei Geräten von Vallox soll es ähnlich sein.
D.h. selbst wenn man das dechiffriert, kann man ggf. am Ende nicht viel beeinflussen.
Im KNX-UF gibt es einen Thread zum ähnlichen Thema. Offensichtlich nimmt die Helios von außen noch nicht einmal Sensorwerte wie Feuchte, Temperatur oder Luftqualität entgegen. Auch der Bypass lässt sich von extern nicht steuern (Stand 2016).
Bei Geräten von Vallox soll es ähnlich sein.
D.h. selbst wenn man das dechiffriert, kann man ggf. am Ende nicht viel beeinflussen.
Markus
TWS 950Q #268, Software-Stand V3.5x, nicht in Verwendung
TWS 950Q #268, Software-Stand V3.5x, nicht in Verwendung
-
- Elaborated Networks
- Reactions:
- Beiträge: 10199
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5041 Mal
- Danksagung erhalten: 8198 Mal
- Kontaktdaten:
Ja, würde mich nicht wundern. Wer so ein Protokolmurks abliefert, dessen Kompetenz für Steuerung / Monitoring von außen wirkt nicht hoffnungsvoll.Smart Jeanie hat geschrieben: ↑So Jun 07, 2020 5:29 pmIm KNX-UF gibt es einen Thread zum ähnlichen Thema. Offensichtlich nimmt die Helios von außen noch nicht einmal Sensorwerte wie Feuchte, Temperatur oder Luftqualität entgegen. Auch der Bypass lässt sich von extern nicht steuern (Stand 2016).
Mir sträuben sich da alle Nackenhaare.
Ja, womöglich ist der Aufwand umsonst.Smart Jeanie hat geschrieben: ↑So Jun 07, 2020 5:29 pmD.h. selbst wenn man das dechiffriert, kann man ggf. am Ende nicht viel beeinflussen.
Wenn uns das nicht separat bezahlt wird, werden wir das nicht implementieren.
lg
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Elaborated Networks
- Reactions:
- Beiträge: 10199
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5041 Mal
- Danksagung erhalten: 8198 Mal
- Kontaktdaten:
Hallo Göran,
sorry dass Du da so eine exotische Implementierung hast, das ist echt ein Hindernis.
Und sorry, dass ich das etwas satirisch geschrieben habe, mache ich sonst nicht. Wir stecken gerade so viel Aufwand und Liebe in die Modbus Implementierung und Helios wäre wegen der Verbreitung natürlich wichtig, so dass ich echt super enttäuscht bin. Es kostet soviel Kraft und Zeit, so eine Super-Speziallocke zu implementieren, das wäre jetzt echt nicht nötig gewesen, dass die mit so einer Krücke daher kommen. Andere können sich ja auch einfach dran halten.
Wie soll man das den Kunden erklären, dass so eine marktgängige KWL schwer integrierbar ist?
==> Bitte frag mal dort nach, womöglich gibt es einen neuen Softwarestand
lg
Stefan
sorry dass Du da so eine exotische Implementierung hast, das ist echt ein Hindernis.
Und sorry, dass ich das etwas satirisch geschrieben habe, mache ich sonst nicht. Wir stecken gerade so viel Aufwand und Liebe in die Modbus Implementierung und Helios wäre wegen der Verbreitung natürlich wichtig, so dass ich echt super enttäuscht bin. Es kostet soviel Kraft und Zeit, so eine Super-Speziallocke zu implementieren, das wäre jetzt echt nicht nötig gewesen, dass die mit so einer Krücke daher kommen. Andere können sich ja auch einfach dran halten.
Wie soll man das den Kunden erklären, dass so eine marktgängige KWL schwer integrierbar ist?
==> Bitte frag mal dort nach, womöglich gibt es einen neuen Softwarestand
lg
Stefan
Zuletzt geändert von StefanW am So Jun 07, 2020 6:41 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 14
- Registriert: Mi Nov 28, 2018 2:38 pm
- Hat sich bedankt: 4 Mal
- Danksagung erhalten: 12 Mal
Ja!
Allerdings mit dem zugehörigen KNX Modul. Da damit jedoch die Bypass-Steuerung nicht möglich ist und auch sonst die Möglichkeiten sehr begrenzt sind, werde ich bei Zeiten wohl auch noch auf eine andere Lösung setzen.
Es gibt freie Software auch für die Helios KWL (z.B. aktuell helios2mqtt).
Damit gibt es auch eine Möglichkeit dafür einen Docker Container zu erstellen.
PS: Wenn der Timberwolf Server jetzt auch ein Feature "Eigene Apps" unterstützen würde, dann könnte sich jeder hier eine solche App mit einem Klick installieren und die App würde im Hintergrund automatisch verborgen einen Docker Container anlegen, starten und ein paar vom App-Ersteller angegebene Objekte zur Weiterverwendung im Logik-Editor o.ä. bereitstellen.
Mit dem Reiter "Apps" beim Timberwolf Server und der Einführung der CometVisu als "App" hatte ich eigentlich erwartet, dass binnen kurzer Zeit weitere auch von Kunden erstellte Docker-Container dort verfügbar gemacht werden und das App-System für interessierte Kunden/Firmen geöffnet wird. Leider hatte ich mich da damals zu früh gefreut und die Entwicklung Richtung ekey geht scheinbar auch eher in eine andere Richtung...
TWS 950Q #300, VPN aus
-
- Elaborated Networks
- Reactions:
- Beiträge: 10199
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5041 Mal
- Danksagung erhalten: 8198 Mal
- Kontaktdaten:
Ja, die Idee ist gut und darüber haben wir intern mehrmals gesprochen. Es ist aber nicht so trivial wie es aussieht und daher ist das erstmal zurück gestellt, weil eine Erweiterung um Kommunikationsfähigkeiten und Protokolle wichtiger ist. APPs und zudem auch noch "Eigene APPs" wurde nie von uns in einem Katalog versprochen, andere Dinge schon, daher haben die auch Prio.John hat geschrieben: ↑So Jun 07, 2020 8:29 pmPS: Wenn der Timberwolf Server jetzt auch ein Feature "Eigene Apps" unterstützen würde, dann könnte sich jeder hier eine solche App mit einem Klick installieren und die App würde im Hintergrund automatisch verborgen einen Docker Container anlegen, starten und ein paar vom App-Ersteller angegebene Objekte zur Weiterverwendung im Logik-Editor o.ä. bereitstellen.
Das mag eines Tages durchaus kommen, weil es würde ja gut zu einem erweiterbaren System passen.John hat geschrieben: ↑So Jun 07, 2020 8:29 pmMit dem Reiter "Apps" beim Timberwolf Server und der Einführung der CometVisu als "App" hatte ich eigentlich erwartet, dass binnen kurzer Zeit weitere auch von Kunden erstellte Docker-Container dort verfügbar gemacht werden und das App-System für interessierte Kunden/Firmen geöffnet wird.
Es ist jetzt aber auch kein großer Aufwand für einen externen Anbieter, einen fertigen Docker-Contaner auf Dockerhub bereitzustellen und ein paar Parameter dazu anzugeben, mit denen das installiert werden kann. Ist vielleicht mehr als ein Klick in APPs, aber es dürften unter 20 Klicks sein für einen Nutzer, das kann man durchaus beschreiben und das funktioniert bereits jetzt schon.
Wenn es eine MQTT zu Helios-Lösung gibt, dann bitte her mit dem Container. Sobald wir die MQTT Unterstützung haben, würde sich das gut einbinden lassen.
Verstehe ich nicht? Was hat das nun mit ekey zu tun? Welche andere Richtung?
lg
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 3800
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1207 Mal
- Danksagung erhalten: 2101 Mal
Ich denke du gibst dir hier selbst schon indirekt die Antwort. Alle Docker können derzeit nur über KNX-Objekte indirekt mir dem TWS kommunizieren.John hat geschrieben: ↑So Jun 07, 2020 8:29 pmWenn der Timberwolf Server jetzt auch ein Feature "Eigene Apps" unterstützen würde, dann könnte sich jeder hier eine solche App mit einem Klick installieren und die App würde im Hintergrund automatisch verborgen einen Docker Container anlegen, starten und ein paar vom App-Ersteller angegebene Objekte zur Weiterverwendung im Logik-Editor o.ä. bereitstellen.
Erst mit zB MQTT kann man dann auch über andere Wege direkt in das Objektsystem kommunizieren, was dann vielleicht auch zu APPs mit vorinstalliertem MQTT etc. führen könnte - mal sehen.
Aber mit den Anleitungen in der KB sollten Container auch für weniger versierte User möglich sein (mit Blick auf den Speicherplatz...).
lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 3771
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1328 Mal
- Danksagung erhalten: 1760 Mal
Ja das mit dem Bypass scheint einfach grundsätzlich nicht zu gehen bei denen. Auch in diesem "Modbus"-Protokoll gibt es nur die zwei Temperaturwerte auf dessen Basis die intern die Klappe steuern. Da müsste man sich dann extern die Temperaturen so gestalten das man dann halt mal AUF/ZU erhält.
Wenn die da wirklich so einen Telegramm-Murks ins Modbus gequetscht haben könnt ich mir vorstellen das die Eigenbaulösungen derzeit einfach auch sich ander Modbus-Logik orientieren hier aber wohl an der Helios Version scheitern und dann nur reads und keine writes hinbekommen.
@StefanW
Ich habe ja wirklich nur mal schnell geschaut. Ich wollte ja wirklich nicht das Du da beim Lesen an Dein zuletzt gelerntes wieder zweifelst.
Wenn das so murksig ist, muss das wirklich nicht umgesetzt werden in Modbus. Mal sehen wie das in MQTT ausschaut, ggf ist das da besser zu adressieren. Das wird ja eh alles in Strings-verpackt, wenn man die dann nicht unbedingt bei denen in HEX schicken muss, dann könnte das ja einfacher werden.
Aktuell dreht die KWl so recht einsam Ihre Runden. Am LAN usw. hab ich die nicht hängen. Im Einpersonenhaushalt muss das Ding nicht viel regeln, wobei jetzt bei 100% Homeoffice ist ja auch nen anderer Bedarf als nur die 2-3 Tage WE.
Das Helios KNX-Modul habe ich auch noch irgendwo im Schrank liegen, das war mal gar nicht so teuer, kam nur die Hälfte dessen was Viessmann so für einen KNX-Adapter aufruft.
Deren Ankopplung ist ja auch noch so ein offenes Projekt bei mir im Keller. Aber da hat sich wohl gerade so ein nettes Forum bei denen etabliert worüber die auch die IP-Schnittstelle etwas begleiten. Das muss ich mir dann wenn es ernst wird, auch mal anschauen.
Bei meinen Empfehlungen lasse ich dann ggf Helios besser erstmal noch weg.
Mal sehen ob man in 2021 wieder messen besuchen darf. auf der ISH sind die ja auch immer da, da kann man denen ja mal direkt Kundtun, das deren Umsetzungen bisher nicht wirklich so dolle sind.
Wenn die da wirklich so einen Telegramm-Murks ins Modbus gequetscht haben könnt ich mir vorstellen das die Eigenbaulösungen derzeit einfach auch sich ander Modbus-Logik orientieren hier aber wohl an der Helios Version scheitern und dann nur reads und keine writes hinbekommen.
@StefanW
Ich habe ja wirklich nur mal schnell geschaut. Ich wollte ja wirklich nicht das Du da beim Lesen an Dein zuletzt gelerntes wieder zweifelst.
Wenn das so murksig ist, muss das wirklich nicht umgesetzt werden in Modbus. Mal sehen wie das in MQTT ausschaut, ggf ist das da besser zu adressieren. Das wird ja eh alles in Strings-verpackt, wenn man die dann nicht unbedingt bei denen in HEX schicken muss, dann könnte das ja einfacher werden.
Aktuell dreht die KWl so recht einsam Ihre Runden. Am LAN usw. hab ich die nicht hängen. Im Einpersonenhaushalt muss das Ding nicht viel regeln, wobei jetzt bei 100% Homeoffice ist ja auch nen anderer Bedarf als nur die 2-3 Tage WE.
Das Helios KNX-Modul habe ich auch noch irgendwo im Schrank liegen, das war mal gar nicht so teuer, kam nur die Hälfte dessen was Viessmann so für einen KNX-Adapter aufruft.
Deren Ankopplung ist ja auch noch so ein offenes Projekt bei mir im Keller. Aber da hat sich wohl gerade so ein nettes Forum bei denen etabliert worüber die auch die IP-Schnittstelle etwas begleiten. Das muss ich mir dann wenn es ernst wird, auch mal anschauen.
Bei meinen Empfehlungen lasse ich dann ggf Helios besser erstmal noch weg.
Mal sehen ob man in 2021 wieder messen besuchen darf. auf der ISH sind die ja auch immer da, da kann man denen ja mal direkt Kundtun, das deren Umsetzungen bisher nicht wirklich so dolle sind.
Zuletzt geändert von gbglace am So Jun 07, 2020 9:45 pm, insgesamt 1-mal geändert.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU