Ankündigung

Einklappen
Keine Ankündigung bisher.

eBus->USB->Plugin->KNX

Einklappen
Dieses Thema ist geschlossen.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Zitat von Fry Beitrag anzeigen
    Wie komme ich hier einen Schritt weiter?
    VG, Fry
    Hast Du die Möglichkeit mit hterm und Windows an den Bus zu kommen. Nur um erstmal zu sehen ob was kommt? Manchmal ist so eine GUI doch was feines
    Umgezogen? Ja! ... Fertig? Nein!
    Baustelle 2.0 !

    Kommentar


      @JuMi2006:

      Gut so.

      Solange uns kein Master-Master-Telegramm bekannt ist, werde ich dieses nicht implementieren.

      Meinst Du mit Trimmung das Poti am Adapter? << Edit: JA

      roland

      Kommentar


        [QUOTE=Fry;280229]dmesg liefert zu diesem Thema:

        Code:
        [79800.637913] usb 1-4.3: New USB device found, idVendor=152a, idProduct=8390
        ..
        Ich schätze das würde anstregend werden, den USB-Vendor findet man nirgends und was das Ding tut gleich 2x nicht..
        Wie wärs mit nem USB-serial fürn paar Euro? ttyS0 sollte aber natürlich auch gehen..

        Makki
        EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
        -> Bitte KEINE PNs!

        Kommentar


          Hallo,

          es gibt eine neue Version von serial_write.

          Die Sendefunktion ist nun in mehrere Funktionen gegliedert.

          Das Versenden von Broadcast und Master-Master Telegramme habe ich mit eingebaut.

          Im Sourcecode ist jedoch das Master-Slave Telegramm fix vorgeben.

          Viel Spass beim testen.

          roland

          Kommentar


            So, nach den Feiertagen komme ich nun endlich auch wieder zum Basteln am eBus.

            Geräte: Vaillant Geotherm VWS 63/2, RS232-eBus-Interface (Eigenbau) am ttyS0

            - Die neue Version vom serial_write (Revision 1288) kann senden und empfangen. Nur manchmal bekomme ich die Fehlermeldung:
            serial_write.c: 288: serial_ebus_read: Warning received and sent message are different or SYN received.
            serial_write.c: 335: serial_ebus_send_msg: Error Success
            Error during sending ebus message.
            Vermutlich eine Kollision, wenn da gerade ein anderes Telegramm auf dem Bus ist?
            - Bei der vorigen Version bekam ich immer den Fehler "Hope, we never saw this."
            - Der ebusd läuft auch, da ist ständig was los auf dem Bus und dazwischen kommen immer die "AA". Das ist aber korrekt so, denn wenn man sich mit dem Speicheroszi den eBus mal direkt anschaut, sieht man da auch zwischen den Telegrammen immer die Sync-Pulse.

            Einen Featurewunsch für den ebusd hätte ich noch: Nicht nur auf lokalen Schnittstellen (RS232, USB), sondern auch übers Netzwerk mittels Deviceserver (Port, Lantronix, Moxa...) das Interface anzubinden wäre cool. Dann könnte man den ebusd einfacher in einer virtuellen Umgebung laufen lassen.

            Marcus

            Kommentar


              Hallo Roland,

              gestern beim Verwenden der ersten serial_write Version funktionierten einige Befehle - jedenfalls kam eine Antwort ohne Fehlermeldung. Den Rückgabewert hatte ich nicht weiter geprüft.

              Wenn ich jetzt serial_write ausführe bekomme ich folgendes:
              Code:
              ./serial_write -s /dev/ttyUSBHeizung 
              serial device /dev/ttyUSBHeizung successfully opened.
              Input: FF 03 03 08 00
              
              in: ff 03 03 08 00 
              
              last SYN found
              <<< ff 03 03 08 00 6e 
              >>> f1 fe 05 03 08 01 01 00 ff 3a ff 15 05 2e 10 03 08 00 08 00 aa 00 05 80 00 00 0a d4 
              serial_write.c: 288: serial_ebus_read: Warning received and sent message are different or SYN received.
              serial_write.c: 335: serial_ebus_send_msg: Error Success
              Error during sending ebus message.
              Sieht irgendwie danach aus, als ob sich das Broadcast Telegramm "vordrängelt". An sich sollte meine Anfrage den Brennstoffmengenzähler abfragen.

              Gruß Moritz

              Kommentar


                serial_write.c: 288: serial_ebus_read: Warning received and sent message are different or SYN received.
                serial_write.c: 335: serial_ebus_send_msg: Error Success
                Das ist zu 99% ein Schreibproblem auf den Bus. Derzeit wird einfach nach einem SYN losgeschrieben, ohne das Arbitrierungsverfahren zu beachten.

                Näheres dazu in "Spec_Prot_12_V1_3_1.pdf"

                Einen Featurewunsch für den ebusd hätte ich noch: Nicht nur auf lokalen Schnittstellen (RS232, USB), sondern auch übers Netzwerk mittels Deviceserver (Port, Lantronix, Moxa...) das Interface anzubinden wäre cool. Dann könnte man den ebusd einfacher in einer virtuellen Umgebung laufen lassen.
                Sowas habe ich noch nie gemacht. Ist das ein einfacher Netzwerkzugriff? Zum Testen fehlt mir dazu auch das Equipment.

                roland

                Kommentar


                  Zitat von MarcusF Beitrag anzeigen
                  Einen Featurewunsch für den ebusd hätte ich noch: Nicht nur auf lokalen Schnittstellen (RS232, USB), sondern auch übers Netzwerk mittels Deviceserver (Port, Lantronix, Moxa...) das Interface anzubinden wäre cool. Dann könnte man den ebusd einfacher in einer virtuellen Umgebung laufen lassen.

                  Marcus
                  Hallo Marcus, das sollte mit Moxa ja ohne Probleme gehen. Man muss auf der VM ja lediglich den entsprechenden Treiber oder eine Socketverbindung zum eigentlichen Device zur Verfügung stellen.

                  Ähnlich mache ich derzeit mit meinem Perl-Daemon:

                  - Socket#1 sitzt auf der Schnittstelle und leitet die Rohdaten via UDP weiter bzw. emfpängt sie per UDP und sendet auf die Schnittstelle
                  - Daemon lauscht auf Socket#1 und baut die Telegramme sauber zusammen. Sind xx Telegramme zusammen sendet der diese über Socket#2 an das Plugin
                  - Plugin lauscht auf Socket#2 und trennt die Telegramme wieder und wertet sie aus
                  - Plugin kann aber auch auf Socket#1 direkt schreiben und wartet dabei auf ein 0xAA was er vom Socket#1 liest

                  Das ist natürlich ne Krücke die aus Laufzeitproblemen entstanden ist, aber eigentlich genau das was was Du willst. Wichtig ist nur dass der Daemon denkt er habe eine "serielle Schnittstelle" ... ob die übers LAN kommt oder direkt anliegt ist eigentlich Wurst.

                  Gruß
                  Umgezogen? Ja! ... Fertig? Nein!
                  Baustelle 2.0 !

                  Kommentar


                    Nach dem dezenten Hinweis auf die Allzweckwaffe socat hab ich es selbst gelöst:

                    Code:
                    socat -t1 PTY,link=lantronix TCP:192.168.2.83:10001
                    erzeugt ein serielles Device namens lantronix und verbindet es mit dem angegebenen TCP-Port des Deviceservers. Und dann einfach
                    Code:
                    ebusd -s lantronix -l3 -f
                    und schon benutzt der ebusd dieses Device. Das sollte dann für XPort oder Moxa ebenso funktionieren.

                    Marcus

                    Kommentar


                      @Marcus: sehr schön

                      @all:
                      Ich müsste jetzt wirklich mal ein paar Befehle anderer Hersteller bekommen. Die Vaillant-WP config ist auf einem guten Stand und irgendwann müssten wir uns da auf was brauchbares für Hautec, Wolf und Vaillant einigen sonst stricken wir das später 1000x um und dabei geht es dann auch an den Code von dem ich keine Ahnung hab .

                      Ich will in einer Woche spätestens mit dem Befehlen die ich auslesen kann fertig sein. Ich hab das aber nicht ohne Grund in einer Tabellen-Datei gemacht. So lassen sich schnell mal ein paar Spalten verschieben.

                      1. Haben wir uns denn jetzt schon auf einen Parser für die config-Datei geeinigt bzw. ein Dateiformat? Ich präferiere immernoch CSV. Die config kann so direkt aus der Quelldatei ausgegeben werden ("save as *.csv") und änderungen sind bequem einzupflegen. Wer späte was über RegEx machen will kann das auch recht einfach tun.

                      2. Die Anbindung an den KNX ... was stellt man sich da so vor? Alles Befehle wird man nie auf den Bus bringen. Ich bin mittlerweile bei ca. 80 "set" Befehlen und 150 "get" Befehlen. Vergleiche SVN (config_set/config_get): SourceForge.net Repository - [openautomation] Index of /tools/ebus/doc


                      Grüße
                      Umgezogen? Ja! ... Fertig? Nein!
                      Baustelle 2.0 !

                      Kommentar


                        Hi Mirko,

                        schön wäre es, aber bei mir schaut es düster bei der Hautec aus bzgl. der verwendbaren Befehle. Nachdem ich auch das Servicetool nicht zur Verfügung habe geht die Aktion ziemlich zäh von der Stange...
                        Was mir echt helfen würde wäre der "No Sync" switch bei einem Dump, dann könnte ich leichter den Traffic mitschneiden.
                        Das Ghost-Phänomen habe ich zum Glück nur in ganz vereinzelten Fällen, hier hatte ich Dich so verstanden, dass ggf. der Poti etwas nachjustiert werden sollte, richtig?

                        Ansonsten sind meine Versuche leider kläglich gescheitert, da ich eigentlich immer die Meldung "Hope, we never saw this" erhalte (da passt was nicht mit den Commands).

                        Insgesamt aber nochmal vielen Dank an Dich und Roland, dass Ihr das Thema so pusht und auch verdammt gut ranklotzt! KLASSE! Ich versuche dranzubleiben...

                        Cheers,
                        Oliver

                        Kommentar


                          @Oliver: Ich verstehe das mit dem "no sync" switch nicht. die 0xaa kommen am Ende, die tun doch nicht weh ? Vorerst würde es mir reichen wenn Du ein paar Befehle hast, damit man sieht wohin die Reise geht.

                          Das "Ghost-Phänomen war tatsächlich eine Einstellung am Poti. Damit, jetzt fällt es mir auf, macht natürlich ein "no-sync" Sinn. Sonst rasseln die Befehle durch ohne Ende.

                          Ich mache die Decodierung der Befehle übrigens immer noch mit hterm. Das ist da einfach am praktischsten.

                          Gruß
                          Umgezogen? Ja! ... Fertig? Nein!
                          Baustelle 2.0 !

                          Kommentar


                            Zitat von JuMi2006 Beitrag anzeigen
                            @all:
                            Ich müsste jetzt wirklich mal ein paar Befehle anderer Hersteller bekommen. Die Vaillant-WP config ist auf einem guten Stand und irgendwann müssten wir uns da auf was brauchbares für Hautec, Wolf und Vaillant einigen sonst stricken wir das später 1000x um und dabei geht es dann auch an den Code von dem ich keine Ahnung hab .
                            Hallo,

                            ich versuche an den Wolf Gastherme Befehlen zu arbeiten. Allerdings funktioniert das Senden im Moment nicht so richtig - hattest Du ja schon geschrieben, woran das sehr wahrscheinlich liegt. Von daher bin ich da noch etwas unsicher.
                            Prinzipiell sollte es ja machbar sein, da Wolf wohl viele Standard-Befehle verwendet...

                            Hilft es wenn ich mal versuche die Telegramme, die zyklisch gesendet werden, in das Tabellenformat zu bringen?

                            Gruß Moritz

                            Kommentar


                              Zitat von JuMi2006 Beitrag anzeigen
                              @Oliver: Ich verstehe das mit dem "no sync" switch nicht. die 0xaa kommen am Ende, die tun doch nicht weh ? Vorerst würde es mir reichen wenn Du ein paar Befehle hast, damit man sieht wohin die Reise geht.
                              Naja, das TEM Protokoll ist leider hidden und dadurch sehe ich als einzige Chance die Dekodierung nach Trial und Error. Dazu parse ich kiloweise in ein Textfile und dann habe ich angefangen das Protokoll zu zerlegen (nach EBUS-Spec).
                              Auf einer Seite sind halt dann ungefähr 4-5 Commands und der Rest sind AA.
                              Ich scheitere halt im Moment wieder an dem RegEx Suchen/Ersetzen im Notepad++, daher halt viel manuelles löschen. Wenn das out of the box kommen würde wäre geholfen.... Aber ich mach mich nun nochmal an das Suchen/Ersetzen im Notepad++, dann geht es auch schneller....

                              Aufgabe: Lösche bspw. "2013-00-02 15:21:11.546 [DBG] aa"

                              Sobald ich mal den ersten Command sauber durchbekomme geht es fixer, aber bis dorthin ist viel grundrauschen auf der Leitung, dass es zu eliminieren gilt....

                              Kommentar


                                Zitat von Sandman60 Beitrag anzeigen
                                Aufgabe: Lösche bspw. "2013-00-02 15:21:11.546 [DBG] aa"
                                Bin zwar nicht sicher ob Dir das hilft. Aber anstatt mit RegEx könntest Du im Debug Output auch den Spalten Modus von Notepad++ benutzen. Cursor platzieren, Alt und Shift drücken und mit der Maus den Block markieren.

                                Gruß

                                Kommentar

                                Lädt...
                                X