Noch eine: knxd auf zweitem Server

[MGK]

Aber auch hier ohne das „KNX:“ vor den Adressen, oder ist das neu in der CV11?

[peuter]

Ja auch hier ohne KNX: in der CV11 wurde an den Adressen nichts geändert.

[Chris M.]

Aus der Demo-Config: Der erste Abruf ist:

http://wiregate/cgi-bin/r?t=0&s=SESSION&a=12/7/9&a=12/7/1&a=12/7/2&a=12/7/20&a=12/7/5&a=12/7/105&a=12/7/16&a=12/7/10&a=12/7/100&a=12/7/50&a=12/7/51&a=12/7/52

und bei den folgenden wäre es z.B.

http://wiregate/cgi-bin/r?i=59331&s=SESSION&a=12/7/9&a=12/7/1&a=12/7/2&a=12/7/20&a=12/7/5&a=12/7/105&a=12/7/16&a=12/7/10&a=12/7/100&a=12/7/50&a=12/7/51&a=12/7/52

Filter sind in Vorbereitung für große Installationen. Ich kenne aber nur eine, die bisher an die Grenzen gekommen ist.
Der Nachteil an Filtern ist, dass hier das Backend nicht mehr State-Less sein kann. Dies wird beim klassischen Interface dem eibd/knxd überlassen, warum ein dummes CGI reicht. Aber schon bei einem FastCGI könnte man es implementieren - und müsste dann den Client mit den Möglichkeiten nachziehen

[snowdd]

peuter
Chris M.
MGK

Danke Euch! Filter lasse ich also erst mal weg.

Das rrdfetch das für die Diagramme verwendet wird, was muss das können? Wenn ich die Telegramme eh' einsammle, kann ich ja auch gleich loggen.

[snowdd]

Beim Schreiben habe ich gesehen, dass die Codierung irgendwie zur Hälfte in der Visu passiert (aus DPT1.001 "0" wird "80", "1" wird "81"; aus DPT5 "ff" wird "80ff", bei DPT9 kommen Kommawerte raus (Slider: 0; 0.5; …, 100) die aber nicht immer einen Dezimalpunkt haben - wie stellt heute cgi-bin/w sicher, dass die Konvertierung auf den DPT passt? Der wird ja nicht mitgesendet, oder [muss zugeben dass ich immer noch mit der 0.10.2 arbeite, die neue ist noch nicht entpackt... mach ich gleich mal.]

[MGK]

Das rrdfetch holt die Daten aus einer rrd Datenbank. Leider nicht rrd Standard sondern entweder ein spezielles rrd oder man ruft ein Script auf. Siehe http://cometvisu.de/wiki/CometVisu/I...ion/RRDtool/en

[Chris M.]

Das rrdfetch das für die Diagramme verwendet wird, was muss das können? Wenn ich die Telegramme eh' einsammle, kann ich ja auch gleich loggen.

rrdfetch greift auf die RRDs zu, die über das ganz normale RRD (Round Robin Database) erzeugt werden. Die ist super, da die aktuellen Daten hochaufgelöst und immer ältere Daten immer gröber aufgelöst gespeichert werden. Also sehr platzoptimal für lange Zeitreihen.
Durch das Umkopieren aber evtl. für Flash-Speicher (z.B. SSD) nicht unbedingt das beste - auf modernen großen Speichern vermutlich nicht so schlimm, auf einer SD-Card im RPi aber nicht zwingend prickelnd.

Was Du aber auch überlegen kannst wäre die Daten in einer InfluxDB zu speichern. Die PA und GA könnte da dann als Tag dazu kommen.
Der Pull-Request, damit die CometVisu auch die InfluxDB als Datenquelle für das Diagram-Plugin hernehmen kann, ist schon fast gestellt.

Beim Schreiben habe ich gesehen, dass die Codierung irgendwie zur Hälfte in der Visu passiert (aus DPT1.001 "0" wird "80", "1" wird "81"; aus DPT5 "ff" wird "80ff", bei DPT9 kommen Kommawerte raus (Slider: 0; 0.5; …, 100) die aber nicht immer einen Dezimalpunkt haben - wie stellt heute cgi-bin/w sicher, dass die Konvertierung auf den DPT passt? Der wird ja nicht mitgesendet, oder [muss zugeben dass ich immer noch mit der 0.10.2 arbeite, die neue ist noch nicht entpackt... mach ich gleich mal.]

Nicht halb - ganz!
Die CometVisu bekommt nur die Roh-Daten vom Bus (und sendet nur Roh-Daten). Die Umrechnung passiert im Browser, basierend auf der Config-Datei.
Wenn da Fehler drinnen sind, tja, das ist dann genau so, wie wenn man in der ETS was falsch konfiguriert hat.

[snowdd]

peuter Es gibt ja noch kein Release von der 0.11 - ich scheitere beim bauen auf meinem Raspi. npm install wirft viele Warnungen (soweit ich überblicken konnte hauptsächlich depreciation warnings) und ./generate.py build endet mit:

>>> Executing shell command "./cv build -bp"...
Traceback (most recent call last):
  File "./cv", line 23, in <module>
    from utils.commands.doc import DocGenerator
  File "/home/homebridge-pi/CometVisu/utils/commands/__init__.py", line 22, in <module>
    import configparser
ImportError: No module named configparser
<type 'exceptions.RuntimeError'> :
Shell command returned error code: 1
[LEFT][COLOR=#000000][FONT=Arial][SIZE=15px][/SIZE][/FONT][/COLOR][/LEFT]

Wo würde es den die erzeugten Dateien ablegen, die ich in mein cometvisu/release-Verzeichnis kopieren müsste?

Danke
Raoul

[snowdd]

Chris M.
Ich habe mir mal angesehen, was cgi-bin/r zurückgibt: Für DPT1 kommt "00" und "01" in der CometVisu an, diese schickt aber "80" und "81" zurück?
Bei DPT9 sehe ich z.B. von cgi-bin/r "0cf4" und an cgi-bin/w "800cf4"

Ich schließe daraus, dass Du unter den "Rohdaten" verstehst, dass das "Write" flag aus den Befehlsbits mit sendest (Befehlsbits umfassen u.a. die ersten beiden Bits aus dem ersten Datenbyte - beim node-eibd haben wir das gerade erst korrigiert, dass die nicht mit rauspurzeln).

Das heißt für mich, dass ich die Länge ohne die führenden zwei Bits ansehe und entsprechendes Telegram daraus baue. Probiere ich aus.

[snowdd]

Das heißt für mich, dass ich die Länge ohne die führenden zwei Bits ansehe und entsprechendes Telegram daraus baue. Probiere ich aus.

Stimmt nicht, ich gucke nur ob das die ersten zwei bit 01 sind und lasse sie drin. "Schreiben" ist ja schon der richtige Befehl.

EDIT: Das gucke ich mir noch mal an, ob ich das richtig gesehen habe.

[snowdd]

Sieht gut aus. Ich habe mal was zum Testen gebaut und bei GitHub geparkt: https://github.com/snowdd1/comet-knx-backend Absolute erste Beta, nur zum Testen.

[Chris M.]

Chris M.
Ich habe mir mal angesehen, was cgi-bin/r zurückgibt: Für DPT1 kommt "00" und "01" in der CometVisu an, diese schickt aber "80" und "81" zurück?
Bei DPT9 sehe ich z.B. von cgi-bin/r "0cf4" und an cgi-bin/w "800cf4"

Ich schließe daraus, dass Du unter den "Rohdaten" verstehst, dass das "Write" flag aus den Befehlsbits mit sendest (Befehlsbits umfassen u.a. die ersten beiden Bits aus dem ersten Datenbyte - beim node-eibd haben wir das gerade erst korrigiert, dass die nicht mit rauspurzeln).

Das ist einfach das, was die CLI Tools des eibd groupread/groupwrite brauchen...

Beim Read ist's einfach der Roh-Wert.
Beim Write ist's wenn der Wert <= 6 Bit ist: 0x80+Wert als einziges Byte, ab einem Byte ist's 0x80 0x..., d.h. der Rohwert mit einem 0x80 als Extra Byte vorne dran.

[peuter]

peuter Es gibt ja noch kein Release von der 0.11 - ich scheitere beim bauen auf meinem Raspi. npm install wirft viele Warnungen (soweit ich überblicken konnte hauptsächlich depreciation warnings) und ./generate.py build endet mit...

Versuch mal noch ein:

sudo pip install -r utils/requirements.txt

Da fehlen scheinbar ein paar Python-Pakete.

Wo würde es den die erzeugten Dateien ablegen, die ich in mein cometvisu/release-Verzeichnis kopieren müsste?

Da würde es ein "build" Unterverzeichnis geben indem die Dateien abgelegt werden. Mit dem Build lässt sich aber nur umständlich entwickeln (da man den ja nach jeder Code-Änderung neu erstellen müsste. Zur Entwicklung kann man sich einen "Source-Build" erstellen, der muss einmalig erstellt werden und nur neu gemacht werden, wenn man eine neue Source-Datei anlegt, oder eine neue Abhäbigkeit hinzufügt (also eine existierende Source-Datei benutzt, die vorher noch nicht benutzt wurde).

Wenn Du ein "./generate.py source" machst, und das Root-Verzeichnis des CV-Repos von einem Browser ausliefern lässt, dann kannst Du den Source-Build im Browser über den /source -Pfad erreichen (also z.B. Webserver auf localhost => http://localhost/source/?config=demo). Das geht genauso mit dem "richtigen" Build => "./generate.py build" => http://localhost/build/?config=demo.

Ganz ohne eigenenes Bauen und lokales Repo gehts auch mit den Nightly-Builds: https://bintray.com/cometvisu/CometV...ightlies#files

[snowdd]

Chris M. Super das läuft soweit - ich kann jetzt über die URLs verlässlich schalten und bekomme auch die Streams zurück. Allerdings gefällt irgendetwas der CV noch nicht, die startet nach einiger Zeit einen neuen Lese-Prozess. Dachte zurerst es wäre der apache2-Proxy, aber im Browser über die URL läufts auch mit den Antworten.

[snowdd]

peuter Danke, ich habe gerade herausgefunden dass ich kein pip installiert hatte, und wahrscheinlich die meisten Module fehlten.. :-(