Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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:
Code:
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.
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.
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 ...
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.
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)...
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.
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.
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.
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.
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.
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.
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.
Hier für die geneigten Mitbastler mal wieder ein (teilweises) Zwischenupdate.
Ich habe mittlerweile den Abschnitt [ventilation] aus der items.conf in eine separate Datei 'helios.conf' verschoben (hauptsächlich aus Gründen der Übersichtlichkeit).
Das Ergebnis im Anhang. Neben den früher schon vorhandenen Werten sind jetzt auch diverse Berechnungen enthalten, z.B. aktueller Volumenstrom, Stromverbrauch, Luftaustauschrate, thermischer Wirkungsgrad etc.
Hinweis: Die unteren Items der Fehlerbehandlung unter [[device_error]] sind gerade in Bearbeitung und noch nicht funktional.
Ansonsten hält mich immer noch die Visu massiv auf, aber ich glaube, die größten Probleme dort habe ich mittlerweile gelöst, so dass hoffentlich auch mit dem Plugin bald weitergehen kann ...
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.
Hab eigentlich keinerlei Störblöcke. Läuft also soweit ganz sauber.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar