eBus->USB->Plugin->KNX

[JuMi2006]

Hallo Fry, eigentlich "störte" mich nur diese Aussage aber nimms nicht persönlich.

Den ebusd.pl würde ich zunächst als WG-Plugin implementieren.

Also ich versuch ich es nochmal in zwei knappen Sätzen.

Der ebusd sollte nicht nur Leuten dienen die auf KNX setzen sondern auch über Kommandozeile für andere Systeme zugänglich sein (UDP/Socket/Telnet). Das ganze dann bitte auch ohne Abhängigkeiten von kommerziellen Lösungen. Lösungen des wiregated zu nutzen halte ich für nützlich und legitim, sollten dann aber direkt im ebusd.pl liegen. KNX sehe ich im Moment (auch wenn wir im KNX-Forum sind) für eine Option die jeder über UDP/Telnet/Socket umsetzen kann (sofern man eine einfache Befehlsstruktur hat die sich im Daemon befindet -> "get HK_soll"). Dann ist es für jeden wirklich Broteinfach .

Gut ... sind jetzt 5 Sätze geworden.

Grüße

[Fry]

Und was ist, wenn ich einfach beide Möglichkeiten implementiere?

Hi yuhu/Roland,

Welche beiden Möglichkeiten meinst du? Die Antwort ist jedenfalls 42 :-)

Übrigens zu deiner Frage: ja, das "Ökosystem Wiregate" bietet das an. RRDs, Visualisierung per CometVisu, KNX-Anbindung via eibd.

Wobei nach meiner Kenntnis der Begriff "Wiregate" sich auf das Produkt (Hard+Software) von Elaborated Networks bezieht, das ist ein vorkonfiguriertes Linuxsystem mit (GPL-offener) Spezialsoftware für die Heimautomation. Nimmt man nur die Software, so nennen sie das hier auch manchmal "Communitygate". Letztlich ist eine Linux-Distri optimiert auf eine bestimmte Hardware und mit eibd, wiregated, Webmin usw.

Nebenbei: Wir befinden uns hier im offiziellen Supportforum des Wiregate. Und ich gehe davon aus, dass die ElabNet-GFs (StefanW und Makki) diesen Thread sehr aufmerksam und auch wohlwollend verfolgen, denn es gibt eine gewisse inhaltliche Nähe von Temperatur-/Feuchte-/etc.-Sensoren (ElabNets Hauptgeschäft) und der Heizungssteuerung via Ebus.

Mit anderen Worten: mit dem, was bereits existiert, plus deiner und Jumis Ebus-Anbindung, kann sich das Wiregate sehr schnell zum besten Heizungs-/Lüftungs-/Klimaregler auf dem Markt entwickeln, und das als offenes System. Was übrigens auch der Grund für mein Interesse ist, denn ich habe keine Raumtemperaturregler in meinem Haus verbaut und auch nicht eingeplant, weil ich gerne meinen eigenen selbstoptimierenden PID-Algorithmus einsetzen würde. Der ist bereits gehackt, in einer Simulation auch schon getestet, muss aber (nach meinem Einzug) noch den Realitätstest bestehen, und dann wird er ebenfalls in die Community gegeben.

VG; Fry

[Fry]

Hallo Fry, eigentlich "störte" mich nur diese Aussage aber nimms nicht persönlich.
....

Jetzt habe ich es verstanden und nichts dagegen einzuwenden.
VG, Fry

[makki]

Jungs, daher mein Ansatz: auf den KNX bringen!
Damit kann jeder, egal ob WG, HS oder xyz (im Kontekt "knxuf") ohne grossere Verrenkungen was anfangen..

Makki

[Gast]

Welche beiden Möglichkeiten meinst du? Die Antwort ist jedenfalls 42 :-)

42 verstehe ich nicht. Ist das ein "Schmäh" für Insider?

Mit beide Möglichkeiten meine ich:

* Input/Output als Bytestream - soweit sind wir jetzt schon.
* Input/Output als Befehl/Antwort - das fehlt nocht.

Jungs, daher mein Ansatz: auf den KNX bringen!

Das müsste mir jemand nähere bringen. Ich hab dazu keinen Schimmer wie und was.

roland

[JuMi2006]

@Fry:

Ja es ist auch Ehrgeiz im Spiel ... was Roland da geschrieben hat spielt schon in einer sehr guten Liga mit. Gestern Abend ergab sein Test auf meinem System 2 Kommunikationsfehler auf 1200 Telegramme . Gebastelt am eBus haben schon viele, aber so richtig fertig bekommen noch keiner.

[Gast]

Gestern Abend ergab sein Test auf meinem System 2 Kommunikationsfehler auf 1200 Telegramme

Nicht ganz. Es war mein System. :-)

    from: 2013-01-13 22:28:24
      to: 2013-01-13 22:31:09
wait (s): 0
 repeats: 100 commands: 12
    send: 1200
  errors: 2

und mit ebus_send -r 10 (also 10 Versuche den Bus zu bekommen).

Mit der Vorgabe von -3 komme ich so auf 12 - 20 Fehler.

Wenn jetzt noch ein "Telegramm erneut senden" hinzukommt geht es Richtung 0.

[Fry]

42 verstehe ich nicht. Ist das ein "Schmäh" für Insider?

Guckst du hier.

Mit beide Möglichkeiten meine ich:

* Input/Output als Bytestream - soweit sind wir jetzt schon.
* Input/Output als Befehl/Antwort - das fehlt nocht.

Das müsste mir jemand nähere bringen. Ich hab dazu keinen Schimmer wie und was.

Aus meiner Sicht, bzw. nach meinem Bedarf ist das erste sozusagen die Pflicht (mit CRC und Pufferung, ggf. bei fehlerhaftem CRC Unterdrückung von empfangenen bzw. Wiederholung von gesendeten Telegrammen), das zweite wäre dann die Kür. Aus meiner individuellen Bedarfssituation reicht der Bytestream (oder Hexcodestream für leichteres Handling) aus.

Wenn du keinen KNX/EIB-Bus betreibst, ist Makkis Empfehlung, "alles auf den EIB" zu bringen, für dich ein Umweg. Dann lieber auf UDP.

VG, Fry

[makki]

42 verstehe ich nicht. Ist das ein "Schmäh" für Insider?

Sowas in der Art, eigentlich gehts um 21
Egal..

Das müsste mir jemand näher bringen. Ich hab dazu keinen Schimmer wie und was.

Nun, da könnte ich einspringen, erfordert aber das man eine "stabile" config, Vorstellung von den Werten usw. hat.
Also in der config (so wie ich verstanden habe, arbeitet ihr daran noch?) eine mögliche Zuordnung zu KNX-DPT usw.
Im Kern ist es dann nichts anderes als (fürchterlicher Spaghetticode!) der russconnectd; ein Thread zum lesen, einer zum schreiben, fertig..
Das funktioniert im Rückblick erheblich besser als die ganze Perl-Suppe

Makki

[Fry]

Im Kern ist es dann nichts anderes als (fürchterlicher Spaghetticode!) der russconnectd; ein Thread zum lesen, einer zum schreiben, fertig..
Das funktioniert im Rückblick erheblich besser als die ganze Perl-Suppe
Makki

Hi Makki,
nix für ungut, aber gerade der russconnectd liefert ein starkes Argument FÜR die "Perl-Suppe".

Nämlich kürzerer, leichter lesbarer (jawoll!) Code und die damit erleichterte Codepflege, weil mehr Leute mal eben was ändern können. Die Folge ist leicht zu erkennen: für RIO und die Russound C5 gibt es bisher keine Anpassung des russconnectd. Nicht weil es keiner könnte, sondern weil es keiner macht.

Übertragen auf unsere Aufgabenstellung hier wäre das in etwa so, wie wenn yuhu und Jumi ihre Vaillant-WP zum Laufen brächten, kleinklausi und ich aber dann in den C-Code reingehen müssten, um mit unseren Wölfen zu reden. Und morgen kommt dann noch einer mit Vissmann, oder einer Pelletheizung, und hat vielleicht irgendwelche Non-Standard-Telegramme, und der Spaß geht wieder von vorne los.

Übrigens @alle, bitte versteht meine Kommentare nicht falsch, ich möchte euch hier nicht meine Meinung aufzwingen, im Gegenteil - egal was ihr macht, ich bin dankbarer Abnehmer, und wenn ich mal mehr Ruhe habe als diese Tage, kann ich gerne auch was dazu hacken. Vorzugsweise in Perl (ja, ich kann auch C, aber siehe oben).

VG, Fry

PS. nochmal @Makki betr. russconnectd: Allerdings nervt mich die Verzögerung bei der Perl-Lösung auch, in diesem Punkt gebe ich dir Recht. Dein Geschimpfe auf Perl klingt mir allerdings überzogen, wenn man mal bedenkt, was du alles mit Perl hingekriegt hast - nämlich u.a. den wiregated.pl - was in C ja doch etwas kniffliger gewesen wäre. Perl, und nicht Python, Ruby oder Java (ha!) ist und bleibt nunmal das Schweizer Taschenmesser.

[Gast]

Aus meiner Sicht, bzw. nach meinem Bedarf ist das erste sozusagen die Pflicht (mit CRC und Pufferung, ggf. bei fehlerhaftem CRC Unterdrückung von empfangenen bzw. Wiederholung von gesendeten Telegrammen)

FYI: Die Implementierung der ebus Funktionen habe ich nach der vorhandenen Doku Spec_Prot_12_V1_3_1.pdf gemacht.

Daß bedeutet,
* es gibt maximal 1 Wiederholung für Master bzw. Slave Nachrichten bei fehlerhaftem CRC. Ansonsten gilt das Telegramm als verloren.
* der freie Buszugriff inkl. Wartezeit und das Arbitrierungsverfahren berücksichtigt werden.
* auf Slave Nachrichten eine Quittung senden und den Bus aktiv wieder freigeben.
* Broadcast, Master-Master und Master-Slave Nachrichten versendet werden können.
* das nicht erlaubten Bytes (AA/A9) in den Nachrichten erweitert bzw. reduziert werden.

Für die Datenhaltung werden intern 2 Strukturen verwendet.
*Eingangsdaten + Erweiterung + CRC
*Antwortdaten + Reduzierung + CRC berechnet + CRC erhalten

Zum aktiven Senden wird das hier gebraucht
* serial_open()
* ebus_send_data()
* serial_close()

und natürlich der Hexstring

Als Antwort von ebus_send_data() kommt dies zurück
* -1 error
* 0 ACK
* 1 NAK

Für die Master-Slave Nachrichten gibt es eine Funktion ebus_print_result()
um die Anwort zu erhalten.



So, was meinst Du nun mit Pufferung?

[makki]

Hi Makki,
nix für ungut, aber gerade der russconnectd liefert ein starkes Argument FÜR die "Perl-Suppe".

Hmm, höchstens ein "Jein" - weil nachdem ich es in HS-Baustein (py), Perl und Shell-Script - mit sehr mässigem Erfolg - implementiert hatte, kam das als "Wut-Produkt" bei raus (mein erstes ernsthaftes C-Programm nach dem qHSMon)

Nämlich kürzerer, leichter lesbarer (jawoll!) Code und die damit erleichterte Codepflege, weil mehr Leute mal eben was ändern können. Die Folge ist leicht zu erkennen: für RIO und die Russound C5 gibt es bisher keine Anpassung des russconnectd. Nicht weil es keiner könnte, sondern weil es keiner macht.

Korrekt, die 20 IMHO unbrauchbaren (sorry..), lahmen implementierungen mit Latenzen im Lieferzeit-Bereich bringen aber auch keinen weiter..
OT: Die Anbindung der C5 (mit RNet!) ist bestellt und wird demnächst.

Übertragen auf unsere Aufgabenstellung hier wäre das in etwa so, wie wenn ..

Richtig und verständlich soweit - mit einer flexiblen Struktur allerdings lösbar, so das alle auf ihre Kosten kommen
-> Ein (sofern möglich?!?) simples Mapping von eBus-Wert->KNX und alle wären glücklich zu machen, oder?

Makki

[Fry]

yuhu -
Hut ab und Respekt vor deiner Arbeit. Sehr professionell.

So, was meinst Du nun mit Pufferung?

Mit Pufferung meine ich, dass ebusd und sein Client (ein ebusd.pl oder was-auch-immer) asynchron laufen.

D.h. dass der ebusd auf dem Ebus lauscht und ggf. sendet, und wenn der Client per UDP sagt "Gib mir mal das nächste Telegramm", dann kriegt er vom ebusd das nächste empfangene Telegramm seit der letzten Anfrage, und wenn der Client ein Telegramm zum Senden übergibt, kann er sofort weitermachen und muss nicht warten, bis der ebusd dieses Telegramm tatsächlich senden konnte.

VG, Fry

PS. Übrigens schlage ich vor, in krasser Abweichung vom Standard auch mehrfaches Senden im Fehlerfall (also >1 Wiederholung) per Option zuzulassen.

[Fry]

OT: Die Anbindung der C5 (mit RNet!) ist bestellt und wird demnächst.

Ebenfalls kurz OT: Heißt RNet automatisch RS232? Oder kann ich damit meine Russound C5 im existierenden Hardware-Setup (Anbindung per Ethernet) nutzen? Das wäre toll!
Fry

[makki]

Mega-OT: Goto: einem der Threads über Rnet (die über RIO lese ich nicht, nur so am Rande, weil das ist mir schlicht wurscht!) -> Rnet geht via RS232, socat->IP oder Moxa->IP..

Zurück zum Thema: wenn die config steht, hielte ich eBus->KNX für eine Lösung

Makki