ElabNET Technik Forum

Habe auch eine Helios. Soweit auch zufrieden damit.
Steuere die Lüfterstufen über Edomi, ebenso lass ich mir darüber die Temperaturwerte der verbauten Sensoren anzeigen. Ebenso Lüfterdrehzal, Bypassstatus, Filterwechsel und Betriebsstunden. Ich meine der LBS gibt noch einiges mehr aus, was ich aber bis jetzt nicht benötigte.
Ja Bypass Is bissel blöd, aber wenn ich es richtig in Erinnerung habe, kann man diesen indirekt über irgend welche Temperaturvorgaben steuern. Nagelt mich ned fest, ist schon ne Weile her.
Läuft seit der Einrichtung ohne Probleme.

Ja Bypass geht nur via zwei Temperaturwerte, sieht man auch wieder in dem PDF.

Der EDOMI LBS geht via welches Protokoll?

Laut LBS ist es ModbusTCP.

Wenn ich das richtig verstanden habe, gibt es für den Weg über iobroker bereits eine Lösung. Vielleicht hilft das hier weiter:

https://forum.iobroker.net/topic/24769/ ... ff-auf-xml

Wenn Helios so schwer anzubinden ist, dann könnte das gleiche auch für Geräte von Vallox gelten, die haben einen sehr ähnlichen Stallgeruch. Ist glaube ich beides Heinemann.

Ist das dann noch Modbus TCP oder dann eher eines der IP-Zugriffe TCP oder REST_API usw.? Dann wäre das einen Eintrag in dem neuen Forumsbereich wert.

Hallo zusammen,

auch ich habe wie Göran eine Helios KWL und hatte stark auf euer Modbus Modul gebaut und bin arg überrascht über das was ich von Stefan lese.

Im FHEM Forum gibt es zu den Helios KWL auch verschiedene Einträge und sogar ein „Modul“ das nach der Beschreibung sehr gut mit der KWL arbeitet.

https://forum.fhem.de/index.php/topic,74788.0.html

Eigentlich wollte ich das FHEM mit Einzug des TWS beerdigen aber so wie es aussieht wird der RasPi wieder aktiviert werden müssen. Allein um das FHEM Modul zu testen.

Was meint ihr, würde es evtl. helfen mit dem Entwickler des FHEM Modul für die Helios-KWL in Kontakt zu treten?

Gruß Ralf

Hallo Markus,

Smart Jeanie hat geschrieben: ↑Mo Jun 08, 2020 3:14 pmWenn ich das richtig verstanden habe, gibt es für den Weg über iobroker bereits eine Lösung. Vielleicht hilft das hier weiter:

Danke. Ist dann etwas für die "Rest-/Web-API". Das muss man dann sehen ob das geht. Wenn es soweit ist, das wir das implementieren, dann werde ich das mit Göran mal prüfen, was da so kommt vom offensichtlich eingebauten Webserver.

Smart Jeanie hat geschrieben: ↑Mo Jun 08, 2020 3:14 pmWenn Helios so schwer anzubinden ist, dann könnte das gleiche auch für Geräte von Vallox gelten, die haben einen sehr ähnlichen Stallgeruch. Ist glaube ich beides Heinemann.

==> Wenn jemand eine "Modbus" Implementierung von Vallox hat, dann bitte gerne die Unterlagen in einem - separaten - Thread posten


lg

Stefan

Hallo Göran,

gbglace hat geschrieben: ↑Mo Jun 08, 2020 3:48 pmIst das dann noch Modbus TCP oder dann eher eines der IP-Zugriffe TCP oder REST_API usw.? Dann wäre das einen Eintrag in dem neuen Forumsbereich wert.

Falls Deine Frage sich auf den Eintrag von Markus bezieht, das wäre dann "Parsen von Webseiten". Ähnlich wie ein Browser den Seitenquellcode, Bilder, xml- und json-Datenstrukturen lädt, macht man dies dann mit einer "Parserengine". Während das Parsen von XML oder Json noch das herauspicken von Daten in einer ordentlichen Datenstruktur ist, ist das herauslesen von Werten aus Webseiten-Quelltexte mühsam und Detektivarbeit und man läuft immer Gefahr, dass nach einem Wechsel der Firmware sich die Zusammenstellung der Webseite ändert.

Wenn ich den kurzen Text bei io:broker dazu richtig verstehe, kann man offenbar von dem Helios-Webserver (es ist dabei mir unklar geblieben ob das ein Portal ist oder das Bestandteil des Helios-Controllers lokal ist) ein xml (also eine ordentliche Datenstruktur) laden und dies dann einlesen.

==> Wir haben auf unserem Entwicklungsplan, im Rahmen der "Rest-/Web-API", das dekodieren von xml auch zu unterstützen. Ein ETS Projektexport ist ja auch eine Sammlung von xml.

==> Hierüber gibt es dann Hoffnung, die Helios KWL dann auch einzubinden. Allerdings könnte es sein, dass dies nur eine One-Way Lösung ist, also das Lesen von Daten. Das kommt darauf an, wie das Implementiert ist, müsste man im Detail analysieren


==> Um zu sehen, wie hoch der Aufwand dafür ist, müsste man schon wissen, wieviele Interessenten es dafür gibt. Wenn man 100 Server dann verkaufen kann, dann rentiert es sich womöglich, eine spezielle Helios-Version zu entwickeln als eigenes Subsystem im TWS.

lg

Stefan

Hallo Ralf,

SchlaubySchlu hat geschrieben: ↑Mo Jun 08, 2020 11:39 pmauch ich habe wie Göran eine Helios KWL und hatte stark auf euer Modbus Modul gebaut und bin arg überrascht über das was ich von Stefan lese.

Wir sind auch enttäuscht.

wir haben uns wirklich viel Mühe gegeben. Haben im Vorfeld alle Handbücher von Wettbewerbsprodukten gelesen damit wir ein gutes Gefühl bekommen, was man unterstützen muss (und was man besser machen kann) und zusätzlich die Dokumentation von gut 80 Modbus Geräten durchgearbeitet, damit unsere Implementierung mit allem kompatibel ist.

Daraus haben wir die sicherlich umfassendste, flexibelste und leistungsfähigste Modbus-Implementierung, die der Markt je gesehen hat, designed und entwickeln das gerade. Ja, das hört sich großspurig an, aber es wird wirklich richtig gut, was da entsteht. Wir wollen schon, dass es mit jedem ordentlichen Modbus-Gerät auch funktioniert und die Bandbreite der Modbus-Dialekte, der Datenformate usw. ist groß, gerade weil der Standard hier sehr viel zulässt.

Aber das was Helios hier implementiert hat lässt sich nach meiner Einschätzung mit keinem mir bekannten, generisch angelegten Modbus Gateway, ansprechen.

Der Modbus Standard beruht weniger auf der seriellen Kommunikation (oder über TCP/IP) und dem Rahmenformat, sondern vor allem auf dem Adressierungskonzept der Register und auf den Functionscodes ("Kommando") zum Zugriff auf diese Register. Das wesentliche Merkmal einer Modbus Implementierung - und das sieht man ja an all den Listen die es für Modbus-Geräte gibt - ist das es für jeden Wert ein eigenes Register gibt und mithin manche Geräte hunderte bis tausende von solchen Registern beinhalten. So wie bei KNX auch, jeweils ein Objekt für jeden Wert, der dann mit einer GA verknüpft wird.

Und genau diese Zuordnung von "Ein Wert" auf "Ein Register" (oder manchmal auch über ein Set von Registern) ist DAS wesentliche Merkmal von Modbus, plus dem Kommunikationsanteil drumherum. Und genau dieses Kernmerkmal, diese Zuordnung wird von der Implementierung hier von Modbus nicht gemacht. Sonder die gesamte Kommunikation wird über ein - und immer das gleiche - Set von Registern geführt. Kein Mapping, sondern man hat ein eigen entwickeltes Protokoll über das (damit verkrüppelte) Modbus gestülpt. Also Protokoll in Protokoll verschachtelt, noch dazu komplex formatiert, also eigentlich Protokoll in Protokoll in Protokoll. Sowas unpraktisches (um höflich zu sein) habe ich noch nicht gesehen in diesem Jahrtausend.

Es wirkt eher so, als hätte man bei Helios eine früheres Protokoll einer serielle Kommunikation gehabt und nun wurde "Modbus" verlangt und man hat dieses alte serielle Protokoll dann dem Modbus Transport übergestülpt, damit man dann (unpassender Weise) "Modbus" auf die Spezifikation dieses Machwerks schreiben kann. ICH würde mich in Grund und Boden schämen sowas an die Kunden auszuliefern. Meiner persönlichen Ansicht nach wäre es einem Techniker von Ehre unmöglich, das reinen Gewissens als Modbus Implementierung zu bezeichnen.

SchlaubySchlu hat geschrieben: ↑Mo Jun 08, 2020 11:39 pmIm FHEM Forum gibt es zu den Helios KWL auch verschiedene Einträge und sogar ein „Modul“ das nach der Beschreibung sehr gut mit der KWL arbeitet.

Wenn man es speziell für diese Implementierung programmiert, kann man das sicherlich nutzen. Speziell geht immer. Nur ist das halt verkehrt, dafür gibt es Protokolle und Standards, damit man das Rad nicht jeweils neu erfinden muss.

SchlaubySchlu hat geschrieben: ↑Mo Jun 08, 2020 11:39 pmEigentlich wollte ich das FHEM mit Einzug des TWS beerdigen aber so wie es aussieht wird der RasPi wieder aktiviert werden müssen. Allein um das FHEM Modul zu testen.

Ein Test wäre sicherlich interessant für die Community.


==> Uns würde eher ein Test des mqtt2Helios Modules interessieren von dem irgendwo auch die Rede war. Weil auf der Basis könnte man für den TWS vielleicht eine APP bauen.

lg

Stefan

Hallo miteinander

StefanW hat geschrieben: ↑Di Jun 09, 2020 10:54 am Es wirkt eher so, als hätte man bei Helios eine früheres Protokoll einer serielle Kommunikation gehabt und nun wurde "Modbus" verlangt und man hat dieses alte serielle Protokoll dann dem Modbus Transport übergestülpt, damit man dann (unpassender Weise) "Modbus" auf die Spezifikation dieses Machwerks schreiben kann.

Ja, das unterschreibe ich. Genau so würde ich das auch einschätzen.

StefanW hat geschrieben: ↑Di Jun 09, 2020 10:54 am ICH würde mich in Grund und Boden schämen sowas an die Kunden auszuliefern. Meiner persönlichen Ansicht nach wäre es einem Techniker von Ehre unmöglich, das reinen Gewissens als Modbus Implementierung zu bezeichnen.

Kein Sorge, geht nicht nur Dir so.