Erweiterung Helios / Vallox Plugin

[gkwlm]

Daher auch die Warnung, dass schon die Veränderung von nur 1 Bit die Spannungsversorgung beschädigen kann.

Nicht ganz - da steht was von mehr als ein Bit.

Das Register ist aber gemäß Doku "vain luku", also r/o, somit keine Gefahr des versehentlichen Beschreibens (zumindest über das normale Businterface).

Wenn es wirklich read-only ist, wozu dann die Warnung?
Und der Hinweis, dass die Fan speed über Register 29H "turvallisesti" (safely) gesetzt werden kann (wohl im Ggs. zu 06H). Also, ich lass von dem Register mal lieber die Finger.

Vielleicht geht's ja auch darum, dass der Ventilator bei Steuerung über 29H langsam rauf und runtergefahren wird (also eine Rampe über die Zwischenstufen läuft), und dass der direkte Wechsel von 1 auf 8 (oder 1 auf 3, d.h. mehr als eine Bitposition), der über 06H auslösbar wäre, eben zuviel für das Netzteil wäre.

Oder jedes einzelne Bit sorgt in irgendeiner Weise für eine definierte Leistung des Ventilators, und wenn nun zwei Bit gleichzeitig aktiv wären, würde sich dass addieren, also in der Summe Stufe 8 übersteigen - und zu Schäden führen.

[Tom Bombadil]

Aber: In dieser finnischen Vallox-Doku steht (laut Google-Translate) bei Register 0x06 irgendwas von "DANGER!" und "burn the transformer". Weiß jemand, was das wirklich meint? In so ein Register will ich nämlich nicht durch Übertragungsfehler versehentlich was falsches reinschreiben.

Ich interpretiere die Doku so, dass 0x06 die direkt an den Motoren anliegende Gleichspannung steuert (also das "Ergebnis" der Steuerelektronik).

Ich kenne die zugrundeliegende Schaltung nicht, könnte mir aber gut vorstellen, dass es zum beschrieben Defekt kommt, wenn der Ergebniswert plötzlich nicht zu den innerhalb der Steuerung gesetzten Parametern/Spannungen passt (=höherer Spannungsabfall an Stellen, wo er nicht hingehört = Überlast an Bauelementen = bumm-blitz-aus).

Daher auch die Warnung, dass schon die Veränderung von nur 1 Bit die Spannungsversorgung beschädigen kann.

Das Register ist aber gemäß Doku "vain luku", also r/o, somit keine Gefahr des versehentlichen Beschreibens (zumindest über das normale Businterface).

Mein Kabel ist übrigens so 2-3m lang, aber die Störungen könnte natürlich auch schon das Originalkabel der Fernbedienung einfangen.

Ich vermute auch eher die Verbindung zur Fernbedienung als Ursache des Rauschens. Bei mir ist die FB z.B. über ~10m NYM 5x1.5 angeschlossen, der Raspi über ~20 cm NYM direkt am Klemmkasten an der Anlage. Sollte alles kein Problem sein, solange der Bus nur ordentlich am jeweils letzten Gerät terminiert ist.

/tom

[gkwlm]

Entweder hab ich einfach Glück, oder ihr habt Pech oder einfach extrem lange Leitungen... [...] Klappt wunderbar.

Die Frage ist ja weniger, ob es überhaupt geht, sondern wieviel Müll man zusätzlich noch auf der Leitung sieht. Das kriegt man ja im Normalbetrieb gar nicht mit, eben weil das Protokoll trotz des "Rauschens" trotzdem noch geht.

Ich habe (zumindest mit der ursprünglichen Verkabelung) häufig Blöcke von dutzenden 0x00 Bytes (d.h. wohl eigentlich Startbits mit nichts dahinter) gesehen. Für sich genommen kein Problem. Es gibt aber Kommandos, die mit nur einem einzigen Byte (nämlich der Checksumme, die auch zufällig mal null sein könnte) quittiert werden. Da könnte so ein Nullbyte, wenn es genau zum "richtigen" Zeitpunkt einstreut, schonmal Verwirrung stiften. Glücklicherweise ist das extrem unwahrscheinlich und zöge auch keine schweren Folgen nach sich.

Aber: In dieser finnischen Vallox-Doku steht (laut Google-Translate) bei Register 0x06 irgendwas von "DANGER!" und "burn the transformer". Weiß jemand, was das wirklich meint? In so ein Register will ich nämlich nicht durch Übertragungsfehler versehentlich was falsches reinschreiben.

Mein Kabel ist übrigens so 2-3m lang, aber die Störungen könnte natürlich auch schon das Originalkabel der Fernbedienung einfangen.

[tuxedo]

Entweder hab ich einfach Glück, oder ihr habt Pech oder einfach extrem lange Leitungen...

Die Lüftungsanlage habe ich mit "einfachem" 8-adrigen Telefonkabel (verdrillte Paare) auf Klemmen in der Verteilung aufgelegt. Länge der Leitung: ca. 8m.
Von da geht's mit 3m ungeschirmten Kabel auf einen 1,50EUR CHINA-Usb-RS485 Adapter. Funktioniert bestens. Die Heizungsanlage mit einem identischen Telefonkabel (jedoch ca. 2m länger) und einen identischen ungeschirmten Kabel auf einen ebenso günstigen RS232-RS485 Adapter.

Klappt wunderbar.

[gkwlm]

Der Digitus hat bei mir nicht funktioniert...da kam zu 90% Schrott über die Leitung.

So schlimm ist es bei mir ja nun nicht ... ich habe heute endlich mal das Kabel getauscht (unverdrilltes Telefonkabel gegen ein CAT5-Adern-Paar, Schirm nur an der R-Pi-Seite angeschlossen). Kann aber noch nicht wirklich sagen, ob es was gebracht hat. Geschadet hat's sicher nicht...

Ich verwende jetzt den Adapter EXSYS EX-1303, der funktioniert deutlich zuverlässiger.

Der ist aber teuer (>40€). Wenn ich nochmal wechseln sollte, dann eher auf das schon erwähnte "Linker Kit RS485" (~17€), bei dem ich zusätzlich noch die Latenzen aufgrund des Umwegs über USB loswerden würde.
Allerdings würde es vermutlich mein R-Pi-Gehäuse sprengen, was nicht so schön wäre. Und an den UART, den es belegt, wollte ich eigentlich schon was anderes anschließen (Stromzähler) - dann bräuchte ich dafür wieder einen USB-Adapter.

Mal abwarten, das Protokoll scheint ja trotz schwacher Fehlerdetektion doch einigermaßen robust zu sein.

[marsellus]

Der Digitus hat bei mir nicht funktioniert...da kam zu 90% Schrott über die Leitung.
Ich verwende jetzt den Adapter EXSYS EX-1303, der funktioniert deutlich zuverlässiger.

/Marcel

[gkwlm]

Hab mal mein grosses Sammelsurium an Helios-Vallox-Dokumenten durchgekramt - guckst Du Anhang ...

Nee, das ist dasselbe, was im Handbuch steht. Interessant wäre der Teil oben - wo diese 11 Adern hinführen, oder zumindest welche Farbe was ist. Falls man sich mal versehentlich eine rausreißt. Ja, Fotos habe ich natürlich gemacht, aber ein Plan wäre besser.

Jetzt wo Du es sagst - sooo viel ist da wirklich nicht drin ...

Zwei Ventilatoren regeln ist ja nun auch nicht gerade "rocket science". Vielleicht gibt's die hier auch gar nicht und sie sind bloss in größeren Modellen vorhanden.

Warum die Fernbedienung überhaupt an sie sendet, ist mir auch nicht klar - denn das Mainboard schickt sowieso alles nochmal an sie weiter. Diese Telegramme könnte man evtl. also auch weglassen.

[Tom Bombadil]

Gibt es eigentlich eine Anleitung für die Verkabelung zwischen Klemmkasten und Anlage? Im Handbuch geht es ja erst ab Klemmkasten los.

Hab mal mein grosses Sammelsurium an Helios-Vallox-Dokumenten durchgekramt - guckst Du Anhang ...

Ich wüsste auch zu gerne mal, wo die adressierten Slaveboards überhaupt stecken sollen (bei der nächsten Filterreinigung suche ich mal)...

Jetzt wo Du es sagst - sooo viel ist da wirklich nicht drin ...

/tom

[gkwlm]

Hatte am Anfang relativ viel Schrott empfangen, nach einem Wechsel des USB-Adapters ist es deutlich besser geworden.
Die 0x00 halten sich seit dem auch in Grenzen, sind aber nicht ganz verschwunden. Verwende relativ gutes Netzwerkkabel für die Verbindung, Schirmung habe ich nirgends aufgelegt.

Na, dann werde ich wohl doch mal das Kabel wechseln. Die 0x00 sind ja vermutlich einzelne Spikes, die als Startbit (mit nichts, also 0x00, dahinter) fehlinterpretiert werden.

Ich habe den Adapter DIGITUS DA-70157 (bei Reichelt gekauft). Von den Nullen abgesehen sehe ich leichte Verzögerungen: Die Quittungen auf eigene Telegramme kommen nicht binnen der geforderten 10ms zurück. Also, entweder hält Helios selbst die Zeit nicht ein, oder die RS485/USB-Umsetzung bringt hier eine kleine Verzögerung rein. Vielleicht sollte man einen echten UART in Verbindung mit einer Treiberstufe wie "Linker Kit RS485" (bei elv) nehmen. Was hast Du?

@tom:
Masse hat er schon ("M" und "-"), aber die ist nicht mit Erde/Gehäuse verbunden. Jedenfalls bei mir nicht, vielleicht hängt das auch vom Installateur ab!
Gibt es eigentlich eine Anleitung für die Verkabelung zwischen Klemmkasten und Anlage? Im Handbuch geht es ja erst ab Klemmkasten los.

Ich wüsste auch zu gerne mal, wo die adressierten Slaveboards überhaupt stecken sollen (bei der nächsten Filterreinigung suche ich mal)...

[marsellus]

Hatte am Anfang relativ viel Schrott empfangen, nach einem Wechsel des USB-Adapters ist es deutlich besser geworden.
Die 0x00 halten sich seit dem auch in Grenzen, sind aber nicht ganz verschwunden. Verwende relativ gutes Netzwerkkabel für die Verbindung, Schirmung habe ich nirgends aufgelegt.

@Tom: Kannst gern mal einen Zwischenstand posten, vielleicht kann man ja helfen.

[Tom Bombadil]

Das "Rauschen" am Bus kann viele Ursachen haben, angefangen mit fehlenden Abschlusswiderständen, über ein "Übersprechen" von parallel verlaufenden Leitungen, bis hin zu korrodierten Klemmen. Vom unbekannten Verhalten der "China-RS485-billig-Adapter" und möglichen Hardware-/Firmwarefehlern mal ganz abgesehen.

Der von Dir angedeutete Austausch des Kabels wäre meiner Meinung nach ein guter Schritt, um zumindest Probleme in der Busverkabelung auszuschließen. In dem Zuge würde ich dann auch alle anderen Busteilnehmer nochmal überprüfen.

Übrigens: Der Klemmkasten hat sehr wohl Masse, siehe Handbuch der Anlage S. 19. Wenn Du die Masse nicht durchschleifen willst - auch einseitiges Klemmen der Abschirmung dürfte die Ausgangslage schon deutlich verbessern ...

/tom

[gkwlm]

Performance läßt sich sicherlich noch rausholen, aber das würde ich nicht um jedem Preis versuchen...die KWL (mit u.U. angeschlossenen Bedienpanels und Senoren) soll ja weiterhin zuverlässig (!) funktionieren. Die "Wartezeit" ist ja nicht aus Langeweile drin, sondern weil das Protokoll das als Marker für Start und Ende der Telegramme definiert.

Keine Angst, ich habe nicht vor es unsicherer zu machen. Aber die einzige mir bekannte wohldefinierte Wartezeit sind die 10ms laut Vallox-Doku, die ein Sender auf Antwort wartet. Wann der Bus frei ist, scheint hingegen komplett undefiniert zu sein (Modbus haben wir hier nicht, denn der hat even parity, 16 bit CRC usw. - also deutlich andere Struktur.), mal abgesehen von der expliziten Sperre/Freigabe durch die Codes 91/8F. Eine lange Pause zwischen zwei Telegrammen verhindert auch nicht, dass zwei Teilnehmer gleichzeitig den vermeintlich freien Bus belegen wollen. Kollisionen sind also nicht auszuschließen und leider nur mäßig gut über die (schwache XOR-) Checksumme zu detektieren. Und die Einzel-Byte Quittungen sind komplett ungeschützt, ich bin noch am rätseln, wie ich die von Störungen unterscheiden soll. Davon habe ich nämlich sehr viele auf der Leitung - deshalb nochmal meine (bisher leider unkommentierte) Frage:

Habt ihr auch solche Massen von 0x00-Bytes auf dem Bus? Ich habe hier pulkweise dutzende bis hunderte davon hintereinanderweg, dann wieder über viele Sekunden Ruhe (bzw. ordentliche Telegramme). Dabei sende ich selbst gar nichts, sondern höre nur den Bus ab.

Ich hätte halt noch die Option, ein CAT- statt Telefonkabel zu nehmen ... will das Fass aber auch nicht unnötigerweise wieder aufmachen.

[Tom Bombadil]

Bin zwar keiner der Experten - aber da das ganze interpretativ abgearbeitet wird und Python im Vergleich zu anderen Sprachen sowieso recht "lax" mit Variablen und ihren Inhalten umgeht, kann man sicher sowas hier machen:

import sys
python_version = sys.version_info[0]
  
...
  
if python_version == 3:
 mach dies
else:
  mach das

Werde ich selbst aber in absehbarer Zeit nicht einbauen können, da diverse andere Punkte derzeit Vorrang haben.

/tom

[tuxedo]

Kleine Frage am Rande an die Python-Experten:

Kann man in das Helios Basisscript nicht was einbauen das die Python-Version erkennt und wahlweise die alte (String basiert) bzw. neue Variante (byte basiert) mit dem Schreiben auf dem Socket verwendet?!

Aus Gründen die ich nicht nennen kann bin ich für's erste auf Python 2.6.6 festgenagelt :-( Und bei jedem Update des Basisscript aus diesem Thread meine Anpassung auf 2.6.6 einzupflegen ist irgendwie lästig.

[Tom Bombadil]

Du hast - um in der Visu Daten aus sh.py zu bekommen - immer den Zwischenschritt über die Item-Namen die nur über die Websocket-Verbindung zu sh.py erst in deinem Browser mit Daten&Leben gefüllt werden. Ein direkte Verbindung zwischen dem php-Code / Twig-Templates der serverseitigen smartVisu-Komponente und sh.py existiert nicht, die smartVisu-Komponente produziert dir "lediglich" die html-Seiten.

Yup. Das Zitat ist übrigens mittlerweile mein abendlicher Standardspruch nach dem üblichen stundenlangem Rumprobieren - bisschen Emotionen müssen ja beim Programmieren auch mal sein dürfen.

Leider bekomme ich die für die Visu geplanten Auswahldialoge (etliche Radiobuttons) ohne den jeweiligen Wert des zugehörigen sh.py-Items nicht sauber initialisiert. Bin mittlerweile schon bei eigenem Websocket, JSON und Konsorten gelandet, um die Ergebnisse dann "hinten herum" in globale TWIG-Variablen zu exportieren und somit im HTML verfügbar zu haben. Irgendwie kriege ich das schon noch geknackt ...

Mal wieder zurück zum Thema: Im Nachbarforum wird das Plugin für eine erste TCP-Anbindung der alten KWL-Modelle genutzt. Interessanter Ansatz, sollten wir im Auge behalten - mal sehen, wo das noch hingeht.

So, heute mach ich mal eher Schluss, ohne obigen Standardspruch.

/tom