ebusd

[Gast]

Hi Leute,

im Wiregate Forum hat vor etwa zwei Jahren die Entwicklung von ebusd angefangen.

ebusd ist ein Linux Dämon welcher sich über einen Koppler mit dem ebus als aktiven Teilnehmer verbindet.

Mittlerweile ist ebusd in einer beta Version v0.5.0 verfügbar und will getestet werden.

Die zugehörigen Konfigurationsdateien befinden sich hier: ebusd-0.5.x.

Das zugehörigen Wiki ist im entstehen.

[JuMi2006]

Hallo Roland,

wenn ich das recht verstehe hat sich da einiges seit dem Start an Features getan.

Ich würde das gern nutzen um das Plugin für sh.py evtl. komplett zu überarbeiten habe da aber einige Fragen:

Was hat es mit dem Polling auf sich? Pollt der ebusd bestimmte Werte jetzt automatisch?
Die alten Konfigurationen scheinen absolut inkompatibel zu sein - was nicht schlimm ist?
Die Templates übersetzen direkt im ebusd die empfangenen Werte in ein anderes Format (dec->str) ?


Super Arbeit ...

Gruß Mirko

[Gast]

Was hat es mit dem Polling auf sich? Pollt der ebusd bestimmte Werte jetzt automatisch?

Ja, ebusd pollt definierte Werte automatisch und hält diese für eine Abfrage bereit. Zyklische Nachrichten arbeiten nach dem selben Prinzip werden nun jedoch als 'Update' bezeichnet.

Die alten Konfigurationen scheinen absolut inkompatibel zu sein - was nicht schlimm ist?

Sollte aus meiner Sicht kein Problem sein. Die aktuellen Konfigurationsdateien sollten für deine Anlage passen.

Die Templates übersetzen direkt im ebusd die empfangenen Werte in ein anderes Format (dec->str) ?

Mit den Templates legst du einen neuen Datentyp mit einem Basisdatentype und einem Divisor(früher Faktor) bzw. mit gültigen Werten fest. Die neuen Datentypen können wieder wie Basistypen verwendet werden. Auch kannst du damit zusammengesetzt Werte definieren.

template name     type / templates     divider / values          
 temp              d2c
 sensor            uch                  0=ok;85=circuit;170=cutoff
 tempsensor        temp;sensor

[mivola]

Hi Roland,

danke für die super Arbeit! Ich versuche auch nach Weihnachten mal die neue Version zu installieren. Ich möchte den ebud weiterhin mit dem "alten" knxd benutzen. Hat sich an der Zusammenarbeit diesbzgl. etwas geändert?

Danke,
Micha

[Gast]

Ja.

Es gibt nach wie vor die TCP Socket Schnittstellen. Es ist egal ob Du darauf mit ebusctl, Telnet, knxd oder sonst was darauf zugreifst.

Die im Server implementierten Befehle und das Format findest Du im Wiki.

Im Gegensatz zu früheren Versionen wird nun read statt get bzw. cyc verwendet. Aus set wurde ein write.

[JuMi2006]

Das bedeutet dass die Plugins umgeschrieben werden müssen.
Ist eine UDP-Schnittstelle in Planung?

[Gast]

Ja. Da es get, set, cyc und hex nicht mehr gibt muss das wohl auf read und write angepasst werden.

Wie müsste eine UDP Schnittstelle aussehen?

[JuMi2006]

Auch wenn wir lange nichts voneinander gehört haben packe ich mal meine Wunschliste aus.

Im ebusd konfiguriere ich die Abfragegeschwindigkeit und er pollt automatisch, richtig?
Das ändern von Werten würde ich gern per UDP-Paket machen statt des Sockets. Demzufolge würde ich natürlich auch gern die UDP PAkete vom ebusd versendet haben um mit anderer Software (sh.py) darauf zu lauschen. Ebenso würde ich natürlich gern alle zyklischen Nachrichten per UDP empfangen wollen.

Das würde dann ein remake des Plugins für sh.py lohnen ... vielleicht reicht fürs erste auch ein einfaches ersetzen der entsprechenden Befehle im Code.

Wo ich noch nicht hinter gestiegen bin ist das Format der neuen Konfigurations-Dateien. Das Lesen ist mir halbwegs helle aber wie darf ich auf den ebus schreiben. Die Funktion ist für mich zumindest essentiell. Wird das in den öffentlichen Konfigurationen unterstützt?

Ich habe leider nur noch unsere uralten configs hier zu liegen die wir in der Anfangszeit ermittelt haben.

Viele Grüße
Mirko


P.S.: Mit meiner Visualisierung bin ich immer noch auf dem Stand von vor 2 Jahren .. was nutzt Du zur Zeit?
P.P.S.: Fürs Packaging des ebusd würde ich wieder helfend zur Verfügung stehen.

[Gast]

Im ebusd konfiguriere ich die Abfragegeschwindigkeit und er pollt automatisch, richtig?

Ja, ebusd pollt automatisch und hält die Antworten genauso wie zyklischen Nachrichten vorrätig. Damit kann man auf einen Schwung eine Menge Daten zu einem Zeitpunkt abfragen.

Das ändern von Werten würde ich gern per UDP-Paket machen statt des Sockets. Demzufolge würde ich natürlich auch gern die UDP Pakete vom ebusd versendet haben um mit anderer Software (sh.py) darauf zu lauschen. Ebenso würde ich natürlich gern alle zyklischen Nachrichten per UDP empfangen wollen.

Wenn ich dich richtig verstanden habe, soll ebusd Befehle per UDP empfangen können ohne direkt eine Antwort zu schicken.
Des weiteren soll ebusd UDP Pakete an definierte Empfänger senden/boradcasten? Was soll da drinnen stehen? zb Aussentemperatur 20.2 °C;Fühler OK?

Wo ich noch nicht hinter gestiegen bin ist das Format der neuen Konfigurations-Dateien. Das Lesen ist mir halbwegs helle aber wie darf ich auf den ebus schreiben. Die Funktion ist für mich zumindest essentiell. Wird das in den öffentlichen Konfigurationen unterstützt?

Schreiben wird für alle Datentypen unterstützt. Sieh dir mal die aktuellen Konfigurationsdateien an. Dort wo ein 'w' in der ersten Spalten vorkommt ist der Befehl schreib bar.

Ich habe leider nur noch unsere uralten configs hier zu liegen die wir in der Anfangszeit ermittelt haben.

Dir Konfiguration auf github ist nun vollständiger.

P.S.: Mit meiner Visualisierung bin ich immer noch auf dem Stand von vor 2 Jahren .. was nutzt Du zur Zeit?

Bis vor 2 Monaten noch die von unseren Anfängen. Zeit Zeit keine :-/

P.P.S.: Fürs Packaging des ebusd würde ich wieder helfend zur Verfügung stehen.

Das ist im Moment nicht notwendig.

[JuMi2006]

Richtig, ebusd soll auf UDP senden und empfangen.
Am besten mit leicht auswertbarem Format. Also irgendwas das sich leicht durch Regex jagen lässt, oder mit einer Befehlsnummer. Hauptsache man bekommt das relativ simpel geparst. Einheiten möglichst nicht enthalten oder optional.
Nach dem Empfang eines Wertes im ebusd sollte er natürlich eine Rückmeldung geben. Das kann ein ACK sein oder der gesendete Wert.
Sobald ein neuer Wert, oder neu eingelesen, erwarte ich ein UDP-Paket. Hintergrund ist mir momentan eine zu hohe Latenz bei einigen Werten. Diese erhoffe ich natürlich in "neuen" zyklischen Telegrammen oder eventuell in befehlsbezogenem Intervall. So können wir wenige kritische Werte mit kleinem Intervall und andere in großen Intervallen abrufen.

Ich muss mir wohl doch noch einen Adapter löten zum testen. Falls es viele betrifft würde ich das WireGate/knxd Plugin versuchen zeitnah zu aktualisieren.

[mivola]

Falls es viele betrifft würde ich das WireGate/knxd Plugin versuchen zeitnah zu aktualisieren.

Ich verstehe noch nicht so ganz warum du UDP statt der Sockets nutzen willst. Kannst du das nochmal erklären? Dann wäre ich evtl auch an einer Aktualisierung des knxd interessiert ;-)

VG
Micha

[Gast]

Richtig, ebusd soll auf UDP senden und empfangen.
Am besten mit leicht auswertbarem Format. Also irgendwas das sich leicht durch Regex jagen lässt, oder mit einer Befehlsnummer. Hauptsache man bekommt das relativ simpel geparst. Einheiten möglichst nicht enthalten oder optional.
Nach dem Empfang eines Wertes im ebusd sollte er natürlich eine Rückmeldung geben. Das kann ein ACK sein oder der gesendete Wert.

Der Rückgabe Werte ohne Einheit, dass sollte sich machen lassen.

Sobald ein neuer Wert, oder neu eingelesen, erwarte ich ein UDP-Paket. Hintergrund ist mir momentan eine zu hohe Latenz bei einigen Werten. Diese erhoffe ich natürlich in "neuen" zyklischen Telegrammen oder eventuell in befehlsbezogenem Intervall. So können wir wenige kritische Werte mit kleinem Intervall und andere in großen Intervallen abrufen.

Du kannst einfach das pollen ebusd überlassen, dann bekommst du die Antwort ohne Verzögerung.

[XueSheng]

Falls es viele betrifft würde ich das WireGate/knxd Plugin versuchen zeitnah zu aktualisieren.

Ich verwende auch noch das alte ebusd mit knxd. Habe mich bislang auch davor gescheut zu aktualisieren, weil der Aufwand recht hoch erscheint und das Wesentliche erst mal funktioniert.
Das einzige Problem das ich habe ist, dass ebusd sporadisch nicht mehr über telnet reagiert (ein Restart des daemons reicht dann aus). Vielleicht würde das neue ebusd hier Abhilfe schaffen!?
Bin auf jeden Fall auch an knxd interessiert (wobei der Name dann vielleicht geändert werden sollte, Stichwort: fork eibd)

[mivola]

Das einzige Problem das ich habe ist, dass ebusd sporadisch nicht mehr über telnet reagiert (ein Restart des daemons reicht dann aus).

Das Problem hatte ich auch. Abhilfe brachte eine Integration in monit. Der startet den ebusd dann einfach automatisch neu :-)

VG
Micha

[XueSheng]

Monit habe ich eigentlich am Laufen (hatte JuMi ja alles ordentlich zusammengeschnürt!).