Erweiterung Helios / Vallox Plugin

[gkwlm]

Ich vermute, dass es eine Kombination aus

• allgemeiner Geschwindigkeit des Pi,
• programmierte Wartezeiten am RS485 ("nur Senden, wenn Ruhe am Bus"),
• Protokolloverhead,
• eingestellter Geschwindigkeit des RS485 (9600),
• nicht primär auf Geschwindigkeit ausgelegter Programmierung

ist (in dieser Reihenfolge).
/tom

Ja, kommt hin.
Ich habe jetzt, nachdem ich anderweitig las, dass Python auf ARM nicht gerade schnell sein soll, mal angefangen, das ganze in C neu zu programmieren. Ist noch frühestes Experimentierstadium, aber 100 einfache Lesezugriffe auf fanspeed brauchen damit gerade einmal 2.1s, also einer 0.021s (statt 0.850s). Das ist ein Faktor 40x. :-)
Es wird sicher noch etwas langsamer werden, da noch viel vom Protokoll im Code fehlt, aber das ist zumindest die Größenordnung, die C und die Baudrate hergeben.
Ich kann leider nicht versprechen, wie's damit weitergeht, denn mein Urlaub geht morgen zu Ende und mein Primärziel ist ja auch eher eine iPhone-App anzutreiben, daher wird die Schnittstelle auch eher anders ausfallen.

[gkwlm]

Ich glaube, hier ist noch etwas verkehrt, am Beispiel Schreiben der fanspeed:

2015-01-05 23:50:28,866 - root - DEBUG - Helios: Connecting...
2015-01-05 23:50:28,947 - root - DEBUG - Helios: Sending telegram '0x01 0x2F 0x20 0x29 0x03 0x7C'
2015-01-05 23:50:28,951 - root - DEBUG - Helios: Sending telegram '0x01 0x2F 0x10 0x29 0x03 0x6C'
2015-01-05 23:50:28,954 - root - DEBUG - Helios: Sending telegram '0x01 0x2F 0x11 0x29 0x03 0x6D'
2015-01-05 23:50:28,958 - root - DEBUG - Helios: Sending telegram '0x6D'
2015-01-05 23:50:28,962 - root - DEBUG - HeliosBase: Disconnecting...

Das letzte 0x6D muss man als Quittung von der 0x11 empfangen, nicht senden. Steht so auch in der Vallox-Doku. Die 0x20 und 0x10 senden hingegen keine Quittungen, daher ist hier nichts zu tun.

[Tom Bombadil]

Das letzte 0x6D muss man als Quittung von der 0x11 empfangen, nicht senden. Steht so auch in der Vallox-Doku. Die 0x20 und 0x10 senden hingegen keine Quittungen, daher ist hier nichts zu tun.

Ja, das ist mir auch schon aufgefallen - die Quittierung muesste eigentlich von der adressierten Einheit (i.d.R. 0x11) kommen. Da es aber im Original-Plugin von marsellus grundsätzlich erstmal funktioniert hat, habe ich es dabei belassen. Muss mir bei Gelegenheit nochmal auf dem Bus ansehen, was da passiert, und ob das Mainboard tatsächlich die Checksumme zurücksendet ...

/tom

[gkwlm]

Empfangt Ihr eigentlich auch so viele Nullen außerhalb der eigentlichen Telegramme?

Muss vielleicht mal meine Verkabelung ändern ... bisher ist es eine einfache zwei-Draht-Telefonleitung an die Klemmen A und B. Könnte das durch ein CAT-Kabel ersetzen, also Twisted-Pair mit Schirm. Lohnt sich der Aufwand?

Wobei mir da der Anschluss Schirm etwas Kopfzerbrechen bereitet, denn auf der Helios-Seite ist anscheinend Klemme "M" identisch mit "-" und beides nicht mit Erde verbunden, auf Pi-Seite hingegen ist USB-Schirm=Erde. Wenn ich den Schirm jetzt durchverbinde, weiß ich nicht, ob das so gut ist ...

[callidomus]

Hallo,

nachdem ich anderweitig las, dass Python auf ARM nicht gerade schnell sein soll

dieses Gerücht ist Blödsinn. Der Pi ist schnell genug um mehrere tausend Items zu verwalten und Logiken/Plugins auszuführen. Ich habe da einmal ein paar Performance-Tests mit dem KNX-Plugin gemacht.

Evtl. "Geschwindigkeitsprobleme" liegen wahrscheinlich an der langsamen Kommunikation. Evtl. kann man bei der Programmierung auch noch ein paar Dinge verbessern. Ich kenne das Plugin aber nicht.

Davon abgesehen was spielt es für eine Rolle wenn der Status erst nach 2 Sekunden aktualisiert wird?

Bis bald

Marcus

[gkwlm]

Muss mir bei Gelegenheit nochmal auf dem Bus ansehen, was da passiert, und ob das Mainboard tatsächlich die Checksumme zurücksendet ...

Bei mir tut es das, wenn ich selbst das Kommando gebe. Und es bleibt aus, wenn ich extra eine falsche Checksumme sende.

Wenn man nur passiv mitlauscht, was die Fernbedienung macht, sieht man natürlich nicht, wer das Byte sendet.

[Tom Bombadil]

Ist noch frühestes Experimentierstadium, aber 100 einfache Lesezugriffe auf fanspeed brauchen damit gerade einmal 2.1s, also einer 0.021s (statt 0.850s). Das ist ein Faktor 40x. :-)

Denke auch dran, dass wir über RS485 reden - damit fällt hardwaregesteuerte Buskontrolle über RTS/CTS aus, wie man es z.B. bei RS232 machen könnte. Die Kollisionsvermeidung am Bus muss somit von Hand erfolgen.

Modbus RTU definiert zwischen den einzelnen Protokollen eine "3.5 byte inter-frame waiting time". Das sind bei 9600 baud ~4ms zwischen den Datenpaketen.

Weniger bzw. kontinuierliches Senden kann gehen, muss aber nicht - irgendwann kommt es zwangsläufig zur Kollision, und das Paket muss erneut gesendet werden.

Im Plugin ist die Wartezeit auf 7ms gesetzt. Es wartet also ab, bis von allen gesagt wurde, was zu sagen ist, samt etwas "Karrenzzeit". Erst danach wird losgelegt.

In dem von Dir zitierten Vallox-Dokument wird übrigens eine maximale Antwortzeit von 10ms für das Ack-Packet genannt (=2. Checksumme, die von der Einheit zurückkommt) - das könnte man zur Flusskontrolle bzw. Kollisionserkennung nutzen ...

/tom

[marsellus]

Hi,

warum ich das Senden der Quittung eingebaut habe, kann ich leider auch nicht mehr nachvollziehen...da ich aber als Entwickler von Natur aus faul bin - und daher sowas nicht einfach so einbaue - wird es irgendeinen Grund gegeben haben.

Zum Thema Performance: Ich hab das Plugin nochmal im Debug-Modus laufen lassen und geschaut wo die Zeiten bleiben. Das Warten auf einen freien Bus dauert gut 100ms, nach dem Senden des Request dauert es ca. 20ms bis ein Wert empfangen wird.
Die Bewertung, ob es jetzt an Python, der pyserial-Implementierung, dem Raspy, dem Modbus-Protokoll, der Baud-Rate, ... liegt überlasse ich jemand anderem.

Der Sinn, warum jetzt alle Werte möglichst im Millisekundenbereich von der Helios abgerufen werden müssen, erschließt sich mir nicht. Sämtliche Änderungen gehen sowieso über den Bus und könnten damit hier "abgefangen" und in einer schnelleren Zugriffsschicht zwischengespeichert werden - genau einer der Use Cases der durch Smarthome.py abgedeckt wird.
Das aktive "Mithören" am Bus ist in dem Plugin nicht drin - ist nach einer Kosten-Nutzen-Gegenüberstellung der für mich wichtigeren Zuverlässigkeit zum Opfer gefallen.

@gkwlm: Was sind genau deine Beweggründe, dass du das in C nachprogrammieren willst? Aktuelle Werte im Millisekundenbereich bereitgestellt zu bekommen ist für eine Regelung relevant...aber doch nicht für ein "Bedienpanel".

/Marcel

[Tom Bombadil]

Hallo Marcel,

danke für die klärenden Worte - ich kümmere mich um die "bits und pieces", ist ja eh alles noch in der Alpha-Phase. Lasse Dir dann die finale Version für das nächste Release zukommen.

warum ich das Senden der Quittung eingebaut habe, kann ich leider auch nicht mehr nachvollziehen...da ich aber als Entwickler von Natur aus faul bin - und daher sowas nicht einfach so einbaue - wird es irgendeinen Grund gegeben haben.

Yup, genug Sourcecode in 25 Berufsjahren gesehen, daher hab ich es auch nicht angefasst. Never touch a running system [unless you know what ya doing].

Die Bewertung, ob es jetzt an Python, der pyserial-Implementierung, dem Raspy, dem Modbus-Protokoll, der Baud-Rate, ... liegt überlasse ich jemand anderem.

Die 100ms könnten auch am "rauschenden" Bus liegen, je nach Leitungslänge und -qualität. Ist aber alles "Lesen in der Glaskugel" und eigentlich irrelevant im Bereich sh.py/smartVISU.

@gkwlm: Was sind genau deine Beweggründe, dass du das in C nachprogrammieren willst? Aktuelle Werte im Millisekundenbereich bereitgestellt zu bekommen ist für eine Regelung relevant...aber doch nicht für ein "Bedienpanel".

Wenn ich raten sollte (hatte die gleichen Gedanken vor einer Weile, dann aber aus verschiedenen Gründen verworfen): Da gibt es einen wartenden Markt an Helios-/Vallox-Eigentümern da draussen, die lieber 300 € für eine App + Raspi als für ein (weniger könnendes) Bedienpanel bzw. KNX-Modul für 400 € berappen würden ...

Vielleicht liege ich ja aber auch nur falsch.

/tom

p.s.
Habe nur in den letzten paar Tagen ein wenig "fck tht sht"-Mentalität, weil ich seit Wochen mit einem Visu-Problem kämpfe, das ich partout nicht gelöst bekomme (direktes Auslesen von Werten aus sh.py und Bereitstellen als TWIG-Variable - da fehlen mir an verschiedensten Stellen einfach Kenntnisse, wie man die Kombination py -> js -> php -> TWIG am effektivsten bändigen kann, habe bereits mehrere Lösungsansätze verfolgt, z.B. globale TWIG-Variablen, hat alles keine Früchte getragen).

Da ich Top-Down von der Visu entwickle, ist das für mich eine ziemlich nervenaufreibende Geschichte. Aber ja, ich werde die Logiken und Items und natürlich das Plugin zu Ende bringen.

[gkwlm]

@gkwlm: Was sind genau deine Beweggründe, dass du das in C nachprogrammieren willst? Aktuelle Werte im Millisekundenbereich bereitgestellt zu bekommen ist für eine Regelung relevant...aber doch nicht für ein "Bedienpanel".
/Marcel

Also vorweg: Ich hoffe hier niemandem damit auf den Schlips getreten zu sein, dass ich diese Implementierung für etwas langsam halte. Das war nicht meine Absicht.

Nun die Hintergründe:
- KNX habe ich im Haus nicht (nichts gegen KNX, aber es war zu teuer). Ich will auch nur Heizung, Strom, Gas und Lüftung an den RaspberryPi anschließen - das geht alles mit UART oder RS485, ich brauche aber noch passenden Code für die gefahrenen Protokolle. Nur die Lüftung will ich steuern (weil da einfach Features fehlen), alles andere nur Status/Logging. In diesem KNX-Forum bin ich nur gelandet, weil ich nirgends sonst Informationen über das Helios-Protokoll fand.


- da ich nunmal Spass daran habe, sowas zu programmieren, will ich alles über eine native iPhone-App abfragen bzw. steuern. Siehe Screenshot des aktuellen Standes. Ich habe auch einfach lieber eine spezialisierte App als eine Webseite. Die App holt sich die Daten natürlich auch bloß über URL-Anfragen von einem Webserver - nur kommt da eben kein zu renderndes HTML zurück, sondern die nackten Daten als Strings. Auf meinem R-Pi läuft bereits für viele andere Dienste der "nginx" als Webserver. Dessen Konfiguration war schon bisher schwierig genug (dieser Teil ist nicht so mein Ding!) - aber da das python-Script als CGI anzubinden, war mir zu kompliziert. CGI mit PHP und C hingegen sind beim nginx hingegen einfach. Im Moment läuft deshalb ein primitives PHP-Script als Wrapper vor dem Python-Script (meine Zeitmessungen bezogen sich aber auf nur letzteres, ohne den Überbau). Einen C-Code könnte ich problemlos direkt anbinden.

- Natürlich gibt es keinen zwingenden Grund, hier Echtzeit-Verhalten zu fordern. Temperaturen ändern sich nur langsam, die Lüftung im Sekundentakt rauf- und runterfahren will auch keiner. Aber in einer App will man auch nicht dauernd irgendwelche Fortschrittsbalken einblenden, bloß weil ein einzelnes Bit gesetzt wird. Ich könnte jetzt entweder auf dem R-Pi oder in der App irgendeine Zwischenschicht einziehen, die den Status periodisch abfragt und einen Cache verwaltet sowie umgekehrt alle Kommandos sammelt und gebündelt weiterleitet. Oder ich versuche eben, den Unterbau so zu beschleunigen, dass es für eine direkte Einbindung in die GUI schnell genug läuft. Ich finde letzteres vom Programmierspaß her attraktiver.

- Python hab' ich noch nie programmiert, daher ist es für mich sehr mühsam, das Script auf meine Bedürfnisse anzupassen. Für die App-Anbindung wären aber einige Änderungen sinnvoll, etwa pro Aufruf gleich mehrere Werte zu lesen/schreiben (aber nicht gleich alle), andere Formatierung der Werte, etc.pp.

Ich hoffe, meine Motivation für einen C-Code wird nun etwas klarer.

Zum Thema Performance: Ich hab das Plugin nochmal im Debug-Modus laufen lassen und geschaut wo die Zeiten bleiben. Das Warten auf einen freien Bus dauert gut 100ms, nach dem Senden des Request dauert es ca. 20ms bis ein Wert empfangen wird.

Da muss einfach viel mehr drin sein, wenn man bedenkt, dass die sechs Bytes gerade mal 6-7ms benötigen und laut Vallox ein Sender auch nur max. 10ms auf Antwort warten soll.
Das mit dem Warten auf den Bus verstehe ich auch nicht - egal, wie lange ich warte, die Wahrscheinlichkeit, dass ein anderer Teilnehmer gleichzeitig losfunkt, wird dadurch nicht geringer. ModBus (das hier ist keiner, aber orientieren wir uns halt mal dran) wartet auch nur 3,5 chars (4ms), wie hier schon geschrieben wurde.

[gkwlm]

Hallo Marcel,
Wenn ich raten sollte (hatte die gleichen Gedanken vor einer Weile, dann aber aus verschiedenen Gründen verworfen): Da gibt es einen wartenden Markt an Helios-/Vallox-Eigentümern da draussen, die lieber 300 € für eine App + Raspi als für ein (weniger könnendes) Bedienpanel bzw. KNX-Modul für 400 € berappen würden ...

Leider nein, denn die neueren Helios-Modelle kommen bereits mit LAN-Anschluss und App daher, wenn ich dass richtig mitbekommen habe. Ich hatte Pech, noch vorher zu bauen. Hab' jetzt nicht genau Preise verglichen oder sonstwie das Markpotential ausgelotet - ich hab hier halt die beschriebenen Geräte stehen und will die nun irgendwie zusammenbringen.

[Tom Bombadil]

Leider nein, denn die neueren Helios-Modelle kommen bereits mit LAN-Anschluss und App daher, wenn ich dass richtig mitbekommen habe. Ich hatte Pech, noch vorher zu bauen. Hab' jetzt nicht genau Preise verglichen oder sonstwie das Markpotential ausgelotet - ich hab hier halt die beschriebenen Geräte stehen und will die nun irgendwie zusammenbringen.

Na dann haben wir ja die gleiche Ausgangssituation - lass uns bei sh.py bleiben, das wird schon (muss die Visu für die iP.... sowieso fertigmachen - ist halt wie immer bei unseren Hasi's: Buchste mal eben den Italiener für heut Abend <- Machste mal schnell den Urlaub fertig <- Kann man das nicht auch einfacher bedienen <- Wolltest Du nicht ein Haus bauen?)

/tom

[marsellus]

Hi,

@gkwlm:
Glaube nicht, dass sich hier jemand auf den Schlips getreten fühlt - bleibt ja alles sachlich. Das mit dem "Programmierspaß" kann ich nachvollziehen, ich kümmer' mich nur gern um Problem die so noch nicht gelöst worden sind und nehme alles mit was jemand anderes bereits ausreichend gelöst hat.

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. Und wenn es einen Busteilnehmer gibt der ständig "dazwischen plappert" ohne die anderen ausreden zu lassen, kann das mMn zu Problemen führen.

Was spricht generell dagegen Smarthome.py als Integrationslösung für deine verschiedenen Systeme zu verwenden? Inzwischen gibt es sicherlich 50 oder mehr Plugins für die verschiedensten Systeme...da sind bestimmt noch weitere interessante Sachen bei. Eine Integration in eine native App ist über verschiedene Plugins sicherlich auch recht unkompliziert.

@Tom:
Dein "fck tht sht"-Problem hab ich noch nicht ganz verstanden...ich hab den Eindruck, dass du die "Direktverbindung zwischen Smarthome.py und der smartVisu" noch nicht ganz aus deinem Kopf gelöscht hast. ;-) 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.

/Marcel

[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

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