Entwicklung / OLA + knxdmxd

[tger977]

JNK
so ich habe mich mal mit cmake versucht. Habe von Git alles geklont und dann folgenden Befehl versucht:

root@5036dcc1e9cd:/knxdmxd/src# cmake /knxdmxd/src/
CMake Error at cmake/LibFindMacros.cmake:259 (message):
  REQUIRED PACKAGE NOT FOUND

  We could not find development headers for json_c.  Do you have the
  necessary dev package installed? This package is REQUIRED and you need to
  install it or adjust CMake configuration in order to continue building
  knxdmxd.

  Relevant CMake configuration variables:

    json_c_INCLUDE_DIR=<not found>
    json_c_LIBRARY=<not found>

  You may use CMake GUI, cmake -D or ccmake to modify the values.  Delete
  CMakeCache.txt to discard all values and force full re-detection if
  necessary.

Call Stack (most recent call first):
  cmake/Findjson_c.cmake:32 (libfind_process)
  CMakeLists.txt:5 (find_package)

Es scheint nun tatsächlich noch irgendwie an den json_c Libs zu liegen. Nach meiner Recherche sollten aber über das Paket libson-c-dev die json_c Quellpaket installiert sein. Muss man da noch irgendwo in den Configfiles von cmake was anpassen weil das Installationspaket nun anders heisst? Wo kann ich da weiter suchen?

[tger977]

leider gibt es auch keine (einfache) Möglichkeit mehr ein lenny per Docker laufen zu lassen.

JNK Nochmal zum libson0 Paket: ich habe da mal recherchiert, das Paket sollte ja die json-c Umfänge enthalten und ist nun damit wohl als neues Paket libjson-c-dev verfügbar. Das konnte ich schon mal installieren. Jetzt ist noch die andere Frage wie ich den knxdmxd noch für Debian Stretch hinbekomme. Vielleicht hast Du mir da auch noch einen kurzen Tip? Ich würde dann wieder versuchen weiterzukommen...

[tger977]

ok, danke für die schnelle Antwort. Ich schau mal ob ich ggf. noch per Docker ein lenny wieder zum laufen bekomme um dann die fertigen binary wieder zu verwenden.

[JNK]

Ich fürchte, wenn libjson nicht verfügbar ist, wird das eine größere Aktion. Dabei kann ich allerdings kaum helfen, ich bin mit Arbeit zu und habe im Augenblick weder ein Debian9 noch nutze ich den knxdmxd. Tut mir leid.

[tger977]

Hallo Jan JNK,

ich würde gerne den knxdmxd von meinem wiregate auf den neuen Timberwolf Server verlagern. Der Timberwolf ist nun auf Debian Linux9 stretch und hat auch eine amd64 Architektur. Wie kann ich dafür ein binary erzeugen bzw. knxdmxd installieren?

Wenn ich ein "apt-get install ola libjson0 knxdmxd" mache findet er nur ola als Paket:

root@f69f6521a221:/# apt-get install ola libjson0 knxdmxd
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libjson0
E: Unable to locate package knxdmxd

Über einen kurzen Hinweis wäre ich dankbar.

[Andreas]

Hallo zusammen,

ist es möglich in der knxdmxd.conf unter "dimmers" mehrere GA für das Dimmen zu vergeben? Wenn ja, wie müssen diese gertrennt sein?

Ich habe in meinen Fall mehrere LED Leisten, welche ich gern zusammen dimmen möchte.

Danke vorab.

Andreas

[JNK]

Mhm. Eventuell kannst Du auch probieren mittels setsockopt SO_REUSEADDR auf 1 zu setzen, vor dem bind(...). Dann sollte da nichts blockieren. Die andere Änderung muss da trotzdem hin, sonst fängt er nach einem Fehler nie mehr an zu senden.

[jorues]

Hallo Jan und der Rest,

schon mal vielen Dank für die Hilfe.
Ich hätte den Code der ganzen Funktion einfügen sollen.

send_error

wird gleich am Anfang bereits mit false initialisiert (s.u.). Das "continue" in der while(1) - Schleife sorgt ja dafür dass, sie gleich wieder neu durchlaufen wird.

Ich denke es hängt am

sock = socket(AF_INET, SOCK_DGRAM, 0);

Dieser wirft beim erneuten "erzeugen", einen Fehler. Ich hab irgendwo gelesen, dass der Kernel den socket blockiert und dies nicht zulässt. Ich kennen mich aber zugegebener Maßen nicht wirklich mit der socket Programmierung aus.

Oder stehe ich komplett auf dem Schlauch? Anbei nochmal die komplette Funktion:

void *dmx_sender() {

    int16_t i, addrlen, cnt;

    struct sockaddr_in sockaddr;

    int sock;

    bool send_error = false;



    if (e131_receiver) {

        syslog(LOG_DEBUG, "dmx_sender: using unicast to %s", e131_receiver);

    } else {

        syslog(LOG_DEBUG, "dmx_sender: using standard multicast");

    }



    while (1) {

        bzero((char *) &sockaddr, sizeof(sockaddr));

        sockaddr.sin_family = AF_INET;

        sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);

        sockaddr.sin_port = htons(E131_MCAST_PORT);



        sock = socket(AF_INET, SOCK_DGRAM, 0);



        addrlen = sizeof(sockaddr);

        if (e131_sender) {

            syslog(LOG_DEBUG, "dmx_sender: using %s as source address",

                   e131_sender);

            inet_pton(AF_INET, e131_sender, &(sockaddr.sin_addr.s_addr));

            bind(sock, (struct sockaddr *) &sockaddr, addrlen);

        }

        if (sock < 0) {

            syslog(LOG_ERR,

                   "init_network: cannot open UDP socket for transmission");

            sleep(RETRY_TIME);

            continue;

        }

        else {

            send_error = false;

        }



        addrlen = sizeof(sockaddr);

        while (!send_error) {

            for (i = 1; i < universe_num + 1; i++) {

                if (e131_receiver) {

                    inet_pton(AF_INET, e131_receiver,

                              &(sockaddr.sin_addr.s_addr));

                } else {

                    sockaddr.sin_addr.s_addr = E131address(universe_list[i]); // 0 is empty universe, do not send

                }

                pthread_mutex_lock(&universe_lock[i]);

                universes[i].packet.FL.sequence_number++; // increase sequence number, overflow ok

                cnt = sendto(sock, &universes[i].packet, sizeof(E131_packet_t),

                             0, (struct sockaddr *) &sockaddr, addrlen);

                pthread_mutex_unlock(&universe_lock[i]);

                if (cnt < 0) {

                    syslog(LOG_ERR, "Could not send UDP data, closing socket");

                    close(sock);

                    send_error = true;

                    break;

                }

            }



            msleep(DMX_INTERVAL);

        }

    }

}

[JNK]

Ohne es probiert zu haben (nutze den knxdmxd nicht mehr):

if (sock<0) {
...
} else {
send_error = false;
}

[jorues]

Hallo Miteinander,

auch wenn länger nichts mehr hier geschrieben wurde, wollte ich das Thema nochmals aufgreifen.
Wie hier bereits geschrieben wurde gibt es ein Problem wenn der knxdmxd im Unicast-Modus betrieben wird, wenn die Netzwerkverbindung unterbrochen wird, muss er neu gestartet werden, damit er wieder Daten sendet. Ich wollte dies nun mal fixen, komme aber leider nicht wirklich weiter.

Der entsprechende Abschnitt im Code sollte der folgende sein:

    while (1) {

        bzero((char *) &sockaddr, sizeof(sockaddr));

        sockaddr.sin_family = AF_INET;

        sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);

        sockaddr.sin_port = htons(E131_MCAST_PORT);



        sock = socket(AF_INET, SOCK_DGRAM, 0);



        addrlen = sizeof(sockaddr);

        if (e131_sender) {

            syslog(LOG_DEBUG, "dmx_sender: using %s as source address",

                   e131_sender);

            inet_pton(AF_INET, e131_sender, &(sockaddr.sin_addr.s_addr));

            bind(sock, (struct sockaddr *) &sockaddr, addrlen);

        }

        if (sock < 0) {

            syslog(LOG_ERR,

                   "init_network: cannot open UDP socket for transmission");

            sleep(RETRY_TIME);

            continue;

        }



        addrlen = sizeof(sockaddr);

        while (!send_error) {

            for (i = 1; i < universe_num + 1; i++) {

                if (e131_receiver) {

                    inet_pton(AF_INET, e131_receiver,

                              &(sockaddr.sin_addr.s_addr));

                } else {

                    sockaddr.sin_addr.s_addr = E131address(universe_list[i]); // 0 is empty universe, do not send

                }

                pthread_mutex_lock(&universe_lock[i]);

                universes[i].packet.FL.sequence_number++; // increase sequence number, overflow ok

                cnt = sendto(sock, &universes[i].packet, sizeof(E131_packet_t),

                             0, (struct sockaddr *) &sockaddr, addrlen);

                pthread_mutex_unlock(&universe_lock[i]);

                if (cnt < 0) {

                    syslog(LOG_ERR, "Could not send UDP data, closing socket");

                    c

                    send_error = true;

                    break;

                }

            }



            msleep(DMX_INTERVAL);

        }

Nach einem Netzwerkausfall bekomme ich im Syslog zunächst ein "Could not send UDP data, closing socket" und dann fortwährend "cannot open UDP socket for transmission". Sock muss also -1 angenommen und somit die Socket-Funktion ein Fehler geworfen haben. Auch wenn die Netzwerkverbindung wieder steht ändert sich nichts mehr.

Kann es sein, das der Socket noch belegt ist? Und es deswegen nicht funktioniert? Hat irgendjemand eine Ahnung wo hier der Fahler liegt?

Kann mir hier jemand weiterhelfen?

Vielen Dank und beste Grüße

Johannes

[MiniMaxV2]

Es wird - so ich StefanW richtig verstanden habe - in Zukunft weder die Möglichkeit geben, eigene Software auf einem WG zu installieren noch einen eibd.

Im großen Wolf wirds ja den Docker geben samt entsprechender API zur Kommunikation mitm BUS (steht ja im Timberwolf Thread). Es wäre somit möglich und flexibler als bisher (abgeschirmtes System). Allerdings wird der Wiregate eigene DMX Stack vermutlich bequemer sein als knxdmxd ich bin gespannt was da kommt ...

[JNK]

Zum Featurewunsch: ich glaube das wird eher nichts. Prinzipiell ist das vermutlich nicht besonders kompliziert, der grundlegende Code zum verarbeiten von Packets ist ja vorhanden, und die Channel-Werte sind auch relativ einfach verfügbar. Das Problem ist eher, dass mein Elan da weiterzuentwickeln sehr, sehr klein ist. Es wird - so ich StefanW richtig verstanden habe - in Zukunft weder die Möglichkeit geben, eigene Software auf einem WG zu installieren noch einen eibd.
Ich habe mich inzwischen wieder etwas mit OpenHAB 2/ESH angefreundet und alle Logiken dorthin portiert. Mit dem neuen E1.31 (Sub-)Binding ist auch der knxdmxd für mich überflüssig geworden, da OpenHAB im DMX Bereich bereits (fast, Multi-Universe wäre nett) alles kann was ich benötige.

Über den OctoNode habe ich auch schon nachgedacht, aber mich noch nicht zu einer Bestellung durchringen können.

Gruss,

der Jan

[murelli146]

Update für alle mit Interesse an e1.31 kompatibler Hardware:

Laut Aussage von U. Radig sollte sowohl die von ihm angebotene Octo ArtNet Node als auch die ArtNet Box e1.31/sACN beherrschen!

Edit: Für die Octo ArtNet Node gibt es jetzt definitiv die passende Firmware für e1.31.
Wenn die Bausätze mit 4 bzw. einem Universum diese Funktion auch erhalten wäre für jede Größenordnung etwas zu haben...

Hat jemand schon Erfahrung mit dem Octo Node und E1.31?

Würde mir gerne so ein teil als Backup zulegen.

Schöne Grüße
Gernot

[murelli146]

Hallo Jan,

hätte mal eine Frage bzw. einen Featurewunsch.

Könnte man die Statusadressen lesbar machen?
Dann wäre der knxdmxd wie ein eigenes knx-Gerät.

Hab immer noch die letzte Testversion in Betrieb (mit 4bit Dimmen) läuft äußerst stabil.

Zur Info: Ich betreibe den knxdmxd unicast. Wenn die Netzwerkverbindung unterbrochen wird,
muss ich den knxdmxd neu starten damit die Verbindung zur E1.31 Bridge wider aufgebaut wird.

Schönen Gruß
Gernot

[murelli146]

Mit -r IP der E1.31 Bridge läuft knxdmxd mit Unicast. Weglassen dann läuft er im Multicast-Modus (ist Standard)

Gruß Gernot