eBus->USB->Plugin->KNX

[kleinklausi]

Ich halte wenig vom Zeitstempel:
- Was mache ich wenn der Wert zu alt ist? Gerade bei zyklischen Daten (CYC) macht das doch wenig Sinn. Wer soll das wie auswerten ... der Wert kann ja nur zu alt sein weil irgendwas mit der Heizung nicht stimmt.
- Der letzte ist zwangsläufig der aktuelle - egal wie alt

Ja sehe ich auch so.
Die Idee kam daher, dass hier z.B. die Solarpumpe wohl nur sendet wenn sie aktiv ist. Dementsprechend könnte der Wert sehr alt werden. Jetzt kann ich das aber ja alles aufzeichnen und dann sehe ich ja, ob das Probleme machen wird.

Könntest Du Dir Option 1 vorstellen?

1. ein weiterer optionaler Parameter "maximales Alter in Minuten". Wenn dieser nicht angegeben ist, wird der letze empfangene Wert zurückgegeben - egal wie alt der ist. Ist der Parameter angegeben, wird ein Wert nur zurückgegeben, falls der Wert nicht älter als X Minuten ist.

[JuMi2006]

1. ein weiterer optionaler Parameter "maximales Alter in Minuten". Wenn dieser nicht angegeben ist, wird der letze empfangene Wert zurückgegeben - egal wie alt der ist. Ist der Parameter angegeben, wird ein Wert nur zurückgegeben, falls der Wert nicht älter als X Minuten ist.

Fall 1:
Wert entspricht dem angegebenen Alter -> wird gesendet
Information: Wert

Fall 2:
Wert ist zu alt -> wird nicht gesendet bzw. Fehlermeldung
Information: keine bzw. "Wert zu alt"

Fall 3:
Wert ist gar nicht vorhanden -> wird nicht gesendet bzw. Fehlermeldung
Information: keine bzw. "Wert nicht da"

Fall 4:
Wert mit unbestimmtem Alter -> wird gesendet
Information: Wert

Wozu brauche ich die Information "Wert zu alt" oder "Wert nicht da".
Ich will das nicht ausreden, sehe aber keinen Sinn darin. Wenn es um eine Fehlerüberwachung geht kann ich die Heizung ja auch aktiv abfragen.

Ich denke da vorrangig an eine schlanke config damit das auch noch vermittelbar ist. Irgendwann wird man sich um die ebus-csv ja nicht mehr kümmern müssen wenn genügend Leute ihre Daten bereitstellen, aber der Rest ...

Grüße

[Gast]

Hi, Internet in Deutschland funktionniert. Krass.

Zum Thema:

Wenn ich darüber nachdenke muss ich JuMi recht geben.
Da die zyklischen Telegramme ja regelmässig kommen sollte sich der Wert in definierte Zeitabständen ändern. Falls nicht liegt also ein Fehler vor.
Der Zeitstempel könnte maximal für eine Alarmierung genutzt werden. Das kann sicher auch anders erfolgen.

[JuMi2006]

So ... CYC sollte jetzt auch unterstützt werden

[makki]

Weitermachen !
Ich weiss wie enervierend das ist (ich durfte meine WP auch alleine Reverse-Intschen-ören)

Aber sollten wir das Thema von Juhu und Jumi nicht auftrennen?
Nicht falsch verstehen, hat definitiv beides Platz hier - aber ich glaube nicht das Otto da nach 65 Seiten noch folgen kann, weil ich komm schon kaum hinterher
(?)
Spontane Idee: zwei neue Threads mit Verweis auf diesen als Basis ? Ich sehe da einfach zwei gute Lösungen, die glaube ich aber leider für gelegentliche Mitleser im Wust untergehen könnten(?!)

Makki

[Gast]

@makki:

Eine Trennung macht eventuell Sinn, da der knxd auch für Anderes als den ebus verwendet werden kann. Bitte korrigiert mich falls dem nicht so ist.

Beim ebusd bin ich an einem Punkt angelangt, wo dieser ausreichend gut funktioniert.
Vielleicht wäre jetzt ein guter Zeitpunkt eine Beschreibung bzw. Doku zu erstellen WAS bereits alles geht, damit dadurch mehr potentielle Nutzer angesprochen werden.
Es sind mit Sicherheit einige Bugs vorhanden. Diese zu finden bedarf es jedoch einer genügend großen Benutzerzahl.
Nicht falsch verstehen, aber ich wünsche mir ab und zu etwas mehr Rückmeldungen.
Wünsche für neue Funktionen des ebusd sind sehr willkommen. Da hat JuMi ein gutes Gefühl was gut ist, bzw. begründet es auch wenn nicht.

Roland

[MarcusF]

Wie ich schon geschrieben habe, ich komm bei der schnellen Entwicklungsfolge kaum noch nach mit dem Installieren und Testen. Wenn jetzt ein stabiler Zustand erreicht ist und die Syntax sich nicht mehr tiefgreifend ändert, dann kommen auch wieder mehr Rückmeldungen von mir.

Marcus

[JuMi2006]

Ich denke auch das eine Trennung Sinn macht ... ich weiß nur nicht so recht wohin mit dem knxd
Irgendwie ist der ja DIY ... andererseits steckt da ein WG-Plugin irgendwie dahinter ... ich weiß nur nicht ob wir in der weiteren Entwicklung den "Wiregate-Plugin-Standard" halten können was Laufzeiten etc. betrifft. Bislang sind wir (Fehlerfall mal ausgenommen) noch immer locker unter 1 Sekunde und damit für ein WG-Plugin akzeptabel.

Da würde ich mir von makki mal ne Aussage wünschen ob der knxd im WireGate-Supportforum schadet oder geduldet wird...ansonsten zieht er in die Code-Schnipsel oder DIY um.

Grüße


ad Featurewunsch:
KNX: eibconnection.h
RRDs

Dann kann man den knxd für andere Zwecke missbrauchen.

Grüße

[Gast]

Hinweis:

Die Verarbeitung der CYC Telegramme funktioniert im Moment ausschließlich für den Typ Broadcast.

Sind Andere (Master-Master oder Master-Slave) notwendig bzw. sinnvoll?

[JuMi2006]

Sind Andere (Master-Master oder Master-Slave) notwendig bzw. sinnvoll?

Ja und Ja.

Sorry ist und bleibt ne kurze Antwort

[Gast]

Ok - somit wird bei zyklischen Telegrammen (falls CRC ok) folgendes gespeichert.

BroadCast ==> Speicherung der Nutzdaten
MasterMaster ==> Speicherung des ACK Byte
MasterSlave ==> Speicherung der Slave Antwort

[Frank0207]

knxd Fragen

Hallo an alle,

versuche jetzt über den knxd die ebus Infos auf den Bus zu bekommen.
Hab mich mal auf eine Einfache Abfrage beschränkt.

Leider bekomme ich keinerlei Infos auf den KNX bzw. vom KNX auf den eBus.
Zur Vorgehensweise habe ich nun ein paar Fragen:

1. Die eBus_plugin.conf muss schon so aussehen?

#### Einstellungen
$config = "/etc/knxd/testcfg.csv";
$ip = '192.168.0.100';        #IP des ebusd
$port = '8888';                #Port des ebusd
$base_time = 120;             #Abrufzyklus
$debug = "";
#### Ende Einstellungen

#GA;DPT;RRD_TYPE;RRD_STEP;TYPE;CMD;COMMENT
0/0/107;1;;;get;ci hydraulic;Hydraulics.

Beim Ausführen von:

perl make_config.pl -i /tmp/vaillant.csv -o /etc/knxd/eBus_plugin.conf

werden die Einstellungen überschrieben. Passt das so?
2. Die eibga.conf soll irgendwo in der knxd.conf angegeben werden. Wo muss ich hier was eintragen?

Mir fehlt jetzt nur noch die Brücke zwischen dem ebusd und dem knxd. Die bekomme ich irgendwie nicht auf die Reihe.
Zudem ist mir folgendes Verhalten des ebusd seit der zyklischen Abfrage aufgefallen. Der ebusd läuft ne gewisse Zeit stabil und man kann über telnet get/send und auch cyc Abfragen machen /Werte setzen. Plötzlich wird der ebusd dann beendet und muss neu gestartet werden.

Die Abfrage des Datums, Uhrzeit und Außentemp liefert mir auch nur folgende Ergebnisse:

Escape character is '^]'.
cyc broad load_vf_temp temp
  0.00
cyc broad date_time_temp
   0.000 Mon 00.00.2000 00:00:00
cyc broad date_time_temp temp
   0.000
Connection closed by foreign host.

Hat jemand auch so ein Verhalten oder hab ich etwas übersehen? Alle anderen Abfragen funktionieren und Schreiben geht auch.

Grüße

Frank

ERGÄNZUNG: Sorry habe die knxd Geschichte jetzt erst an der anderen Stelle im Forum entdeckt. Werde mir nun das nochmals dort sauber durchlesen und beschränke mich hier auf das plötzliche, unerwartete Beenden des ebusd.

[JuMi2006]

Hallo Frank,

die Geschichte mit dem knxd war noch leicht unterdokumentiert.
Wir haben das jetzt mal getrennt:

https://knx-user-forum.de/forum/supp...wiregate/26135

Sollten danach noch Fragen zum knxd/Plugin sein einfach dort nochmal. Dieser Thread gehört jetzt Roland

Zu den CYC, ich hab die ehrlich gesagt noch nicht getestet.
Hast Du die letzte Version des ebusd? Rland hatte nochmal was bzgl. der Telnet Stabilität geändert (1-2 Versionen her)

Die Zeilen GA,DPT etc. gehören in die csv die Du in der ebus-plugin.conf unter $config angiebst.

[Frank0207]

knxd schon gelesen:-)

Hallo JuMi,

jepp hab das jetzt vorne in der Themenliste gesehen und werde mich morgen mal an das schrittweise Umsetzen Deiner Angaben machen.

Ich hab mir die aktuellste Version aus'm SVN vom ebusd gezogen. Werde das mal beobachten.

Grüße

Frank

[Gast]

Zudem ist mir folgendes Verhalten des ebusd seit der zyklischen Abfrage aufgefallen. Der ebusd läuft ne gewisse Zeit stabil und man kann über telnet get/send und auch cyc Abfragen machen /Werte setzen. Plötzlich wird der ebusd dann beendet und muss neu gestartet werden.

Kann man das Verhalten irgendwie eingrenzen?