Trovis 557x Heizungsregler Plugin

[wvhn]

Die gute Nachricht ist, dass das Trovis Device von der Seite des Linux-Systems her ansprechbar ist. Da sollte also alles OK sein. Das „hello world“ kommt bis zum Adapter durch.
Im „Data Monitor“ hätte ich aber jedes „hello world“ doppelt erwartet - einmal als gesendet und einmal als empfangen. Die Spalte COM / NET gibt sicher die Richtung an, oder? Da ich das Programm nicht kenne, würde ich als Gegenprüfung empfehlen, den Versuch mit aufgetrennter Verbindung RxD/TxD zu wiederholen.

Aus Interesse habe ich ein bisschen gegoogelt und recht widersprüchliche Angaben zur Schnittstelle des Trovis gefunden. Der Hersteller nennt an einer Stelle RS232 und RS458 als „Zubehör“, erwähnt im Handbuch aber nur RS458. Das müsstest Du versuchen zu klären.
In diesem Thread, an dem Tom auch schon beteiligt war, bin ich dann auf interessante Hinweise gestoßen. Die Baudrate muss wohl auf 19200 eingestellt werden und zusätzlich müssen in der Steuerung noch 2 Einstellungen gemacht werden.

EDIT: und Tom war schon wieder schneller …

[Tom Bombadil]

Wolfram: Genial - danke!!! (ich hatte den Thread bei microcontroller.net schon völlig verdrängt)

Gemäß diesem Beitrag dort spricht die 5573 tatsächlich 'TTL' (RS232). Es müsste also mit dem derzeitigen Adapter gehen.

Und hier sieht man nochmal die richtige Verkabelung. Am besten ein altes Netzwerkkabel abkneifen, dann sind die Farben eindeutig.

/tom

[TheStig]

Ach Leute, ihr überfordert mich ;-)

@wvhn: verstehe ich deinen Link richtig, dass ich die Pins 1 und 8 nutzen muss (anstelle von 3 und 6 wie in Toms Wiki?)? Oder muss ich doch dann einen anderen Adapter nutzen?

Ich habe jetzt die Genialität dieses anderen Threads noch nicht richtig erkannt. Kann mich da jemand aufschlauen?

EDIT: Ihr wisst ja, ich bin ein Freund des gepflegten Ausprobierens... Pins 1 und 8 gehen auch nicht...

EDIT 2: Es gibt ja eine Trovis 5573 und eine Trovis 5573-1 (auch so bei Trovis View auszuwählen). Kann es noch was damit zu tun haben? Dass ich eine alte Revision habe, die das gar nicht mitmacht?

[TheStig]

Bäm....Fortschritt:
2021-08-29 21_01_44-SAMSON TROVIS-VIEW 4.png
Trovis View liest aus! Verbindung steht also!!!

Zwei Dinge waren falsch: 1. es mussten tatsächlich die Pins 1 und 8 sein. 2. die Modemfunktion muss bei meiner 5573 aktiviert sein! Dieser Beitrag hier hat mich darauf gebracht: https://www.mikrocontroller.net/topic/346223#4784300

Aktuell bringt er immer noch den "not iterable"-Fehler im shNG, aber da kümmere ich mich wann anders drum. Jetzt gibts erstmal einen großen Gin Tonic! Und wenn einer von euch unermüdlichen Supportern mal im Rheinland unterwegs seid, die gibts für euch bei mir jederzeit! Vielen Dank! Ich komme bestimmt noch mit Fragen zu shNG auf euch zurück!

EDIT: Das ist der Fehler, nur falls jemand noch Lust hat, jetzt zu überlegen, womit das wieder zusammenhängt, wo Trovis View auslesen kann:

2021-08-29 21:19:01 ERROR plugins.trovis557x.poll_device Method plugins.trovis557x.poll_device exception: 'AttributeError' object is not iterable
> Traceback (most recent call last):
> File "/usr/local/smarthome/lib/scheduler.py", line 664, in _task
> obj()
> File "/usr/local/smarthome/plugins/trovis557x/__init__.py", line 84, in poll_device
> self.verarbeiteWerte(ids_mit_werten, 'register')
> File "/usr/local/smarthome/plugins/trovis557x/__init__.py", line 238, in verarbeiteWerte
> for id, buswert in _ids_mit_werten:
> TypeError: 'AttributeError' object is not iterable

[Tom Bombadil]

Sehr schön - Glückwunsch! Dann steht zumindest die Verkabelung mit allen notwendigen Einstellungen.

2. die Modemfunktion muss bei meiner 5573 aktiviert sein!

Ich befürchte, dass das mit shNG nicht funktionieren wird, siehe auch weiter unten im zitierten Thread.

Erklärung: Es gibt grundsätzlich 2 Betriebsweisen der Trovis:

• echte binäre Kommunikation auf direktem Weg (siehe mein Sniffer-Screenshot auf der ersten Seite),
• Kommunikation über Klartext-Befehle, wie sie früher bei Modems üblich waren:
  AT (steht für "Attention")
  Ok (Antwort der Gegenstelle - 'bin bereit')
  AT XXYYZZ (nächster AT-Befehl, z.B. bestimmtes Register abfragen)
  1234567 (Antwort der Gegenstelle, z.B. Inhalt des Registers)
  usw.

TrovisView beherrscht vermutlich beide Spielarten, das shNG Plugin nur die erste, also 'echtes Modbus'. Ich hatte schon in Deinem letzten Sniffer-Screenshot gesehen, dass Trovis-View versucht hat, einen AT-Befehl abzusetzen, und offenbar auf ein 'Ok' wartet.

Falls Du das Plugin im Dauerbetrieb fahren willst, wirst Du die Modemfunktion also vermutlich ausschalten müssen - zumindest bei der 5576 kann ich Plugin und TrovisView so gleichzeitig betreiben (wenn letzteres nicht grad mal wieder rumzickt, z.B. weil eine zu hohe COM-Schnittstelle gewählt wurde).

/tom

[TheStig]

Falls Du das Plugin im Dauerbetrieb fahren willst, wirst Du die Modemfunktion also vermutlich ausschalten müssen - zumindest bei der 5576 kann ich Plugin und TrovisView so gleichzeitig betreiben (wenn letzteres nicht grad mal wieder rumzickt, z.B. weil eine zu hohe COM-Schnittstelle gewählt wurde).

/tom

Tjo, das ging vorhin leider nicht, also das Modemfunktion deaktivieren. Teste ich die Tage aber nochmal. So habe ich jetzt aber erstmal Ruhe, da ich immerhin Fortschritt gemacht habe (und mich beim Verkabeln ja auch nicht zu doof angestellt habe, da es für mein Gerät einfach die falschen Pins waren).

Aber was würde es denn bedeuten, wenn es nur mit aktivierter Modemfunktion gehen würde? Würde es da einen Weg des regelmäßigen Auslesens geben? Mir ist das System wie es gelesen wird eigentlich egal, möchte es nur gerne tracken und verfolgen dauerhaft.

[Bonze]

Dann musst du vermutlich die AT befehle implementieren

[wvhn]

Oder nochmal ab dem von mir verlinkten Post weiter lesen. Z.B. hier. Dort werden die AT-Kommandos abgeschaltet.

[Tom Bombadil]

Mir ist das System wie es gelesen wird eigentlich egal, möchte es nur gerne tracken und verfolgen dauerhaft.

Und genau da sind wir am 'casus knactus'.

Folgendes Szenario: Du rufst Omma an. Es klingelt, sie hebt ab, ihr redet. Ihr habt also eine funktionierende Punkt-zu-Punkt-Verbindung (Oma und Du sind die 'Punkte'). In heutigen Voip-Zeiten bedeutet das:

• Dein Körper erzeugt durch Sprache Schallwellen,
• die Luft überträgt die Schallwellen in das Mikro des Telefonhörers,
• hier werden die Schallwellen in analoge elektrische Signale umwandelt,
• dann flitzen die Signale vermutlich erstmal durch ein Stück Kupferkabel in den Router,
• dort sitzt ein Analog-Digital-Wandler, der die Signale in lauter Nullen und Einsen umwandelt,
• dann verpackt Dein Router die Digitalsignale in Datenpakete und schickt sie per Kupfer / Glasfaser / LTE über das 'große, weite Internet' mit all seinen Switches, Hubs und Nodes an die richtige IP auf der anderen Seite,
• dort passiert die komplett die umgekehrte Umwandlung, bis wieder Schallwellen am Ohr von Oma ankommen: Hallo, i bims!
• Da Oma und Du die gleiche Sprache sprechen, versteht Ihr Euch prächtig, und so plaudert fleißig vor Euch hin. Schallwellen gehen ständig hin und her, und Ihr beide seid fröhlich.

Im Grunde passiert bei Deiner Konstellation (Trovis View, virtueller COM-Port, LAN, Adapter mit Umsetzer auf RS232, Trovis) genau dasselbe. Eine lange Kette von Signalen, Medien und Konvertierungen/Umsetzungen und zwei Teilnehmer, die dieselbe Sprache sprechen.

Wenn jetzt aber die beiden Endpunkte anfangen, unterschiedliche 'Sprachen' zu sprechen (AT-Befehle vs. Modbus) - dann wird das nix. Oder mit anderen Worten: Ihr seid zwar verbunden, aber Du quatscht Omma plötzlich in Hoch-Mandarin zu - da versteht sie vermutlich kein Wort, obwohl rein technisch gesehen die Verbindung ja steht ...

Hoffe, das hilft zum Verständnis.

/tom

Edit/p.s.: Die Profis mögen mir bitte die vereinfachte Darstellung verzeihen.

[wvhn]

😂 welch Freude am frühen Morgen.
Nun ist es doch so, das Opa auch noch da ist und der versteht die Omma - zumindest sprachlich Und ihn kann man vielleicht fragen, welche Sprache er da spricht.

Also wenn Trovis View die Daten korrekt anzeigt, muss man doch nur nachsehen, wie die Kommunikation dort eingestellt ist. Und zur Not hört man das Ganze per Wireshark mit, wenn Opa nichts erzählt..

Gruß
Wolfram

[TheStig]

Aaaaalso ihr Lieben! Im Grundsatz ist mir das mit den unterschiedlichen Protokollen klar. Ich denke aber ja vom Ergebnis her. Also wie löse ich das Problem jetzt?

In Trovis View kann ich nur die Baudrate und den Com-Port einstellen (oder halt direkte TCP/IP Kommunikation). Das hilft mir also nicht weiter.
Mit Wireshark auslesen bekomme ich vielleicht auch irgendwie hin, aber was mache ich dann damit?

EDIT: Wobei sich das hier liest, als ob es auch mit deaktivierter Modemfunktion bei der 5573 geht: https://www.mikrocontroller.net/topic/346223#6064605

[TheStig]

Oder nochmal ab dem von mir verlinkten Post weiter lesen. Z.B. hier. Dort werden die AT-Kommandos abgeschaltet.

Hier könnte es sein, dass der User eine andere Revision der 5573 hat. Ich habe ja wie gesagt die einfache "5573" und es gibt noch eine "5573-1". Der User gibt seine Box mit 5573-0001 an.

[wvhn]

Als Ingenieur würde ich jetzt halt versuchen, die Situation komplett zu erfassen und eindeutig nachzuweisen, ob es am Protokoll liegt. Um bei der Übersicht von Tom zu bleiben, sieht es doch jetzt so aus:
Übersicht.png
D.h. jetzt musst Du nachvollziehen, ob das /dev/trovis korrekt arbeitet Das war m.E. mit dem local loopback von RxD und TxD am Adapter noch nicht vollständig verifiziert. Der nächste Schritt ist dann die Prüfung der Verbindung zwischen /dev/trovis und dem Trovis-Plugin. Und im Plugin stellt sich dann die Frage, ob das Protokoll so eingestellt ist / werden kann, dass das heutige Plugin dieses versteht.
Dieses Vorgehen erübrigt sich, wenn Du einen Hinweis findest, dass Dein Gerät tatsächlich nur im Modem-Modus läuft. Wegen der in dieser Hinsicht mageren Dokumentation der Trovis-Geräte und des etwas verworrenen Threads auf microcontroller.net halte ich das aber für unwahrscheinlich.

[TheStig]

D.h. jetzt musst Du nachvollziehen, ob das /dev/trovis korrekt arbeitet Das war m.E. mit dem local loopback von RxD und TxD am Adapter noch nicht vollständig verifiziert. Der nächste Schritt ist dann die Prüfung der Verbindung zwischen /dev/trovis und dem Trovis-Plugin. Und im Plugin stellt sich dann die Frage, ob das Protokoll so eingestellt ist / werden kann, dass das heutige Plugin dieses versteht.

Also 1. Schritt: Funktioniert /dev/trovis? Wie soll das jetzt nochmal verifiziert werden? Meinst du das, was du hier beschrieben hast: https://knx-user-forum.de/forum/supp...19#post1684519 ?
Und auflösen meint dann, so testen wie es jetzt verbunden ist?

[TheStig]

Tom Bombadil , was sagt dir die automatische Modemkonfiguration?
2021-08-30 20_18_56-SAMSON TROVIS-VIEW 4.png
Kann das ggf. dazwischenfunken?