Gleiches Problem hatte ich auch mit dem Weinzierl LineMaster 762.

Lösung war wie beschrieben vom Autor des Adapters, die korrekten Datenpaare in der ETS zu basteln.

Beispiel:
GA 1/1/1 , DPT 1.001 (schalten) , 1 bit , nur schreiben (obwohl meine Theben Aktoren auch komischerweise lesen können)

GA 2/1/1 , DPT 1.011 (status), 1 bit, nur lesen

Beschreibung sollte die gleiche sein, nur der "Status" im Text eben als Unterschied.

Dadurch baut der KNX Adapter ein "DatenPaar" zusammen. Erkennbar ist das an zwei eingetragenen RefID´s im Datenpunkt des Objektes. (statusGA hat actGARefId zusätzlich und die SchaltGA hat statusGARefId als extra drin)

Erst damit konnte ich dann endlich schalten.

IMHO stehe ich trotzdem bei Zentralbefehlen auf dem Schlauch, für die es keine extra Status GA gibt. Beispiel: Alle Rolläden auf/ab in einer GA

Lösung gefunden:

Punkt 1:
Nodejs neuere Version mit originaler Installationsanleitung für Ubuntu installiert.

# Using Ubuntu
curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs

Punkt 2:
Neuste Installation direkt von GitHub genommen:

curl -sL https://raw.githubusercontent.com/ioBroker/ioBroker/master/installer.sh | bash -

so läuft es ohne Probleme mit dem aktuellen 19er Server Release von Ubuntu.

Hallo Miteinander,

hab bei der Installation unter Ubuntu 19 Server auf vmware meine Sorgen.

Im Teil 3 der Installation von ioBroker kommt diese Fehlermeldung:

In file included from ../src/main.cpp:3:
../../nan/nan.h: In function ‘void Nan::AsyncQueueWorker(Nan::AsyncWorker*)’:
../../nan/nan.h:2298:62: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_                            work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type]
     , reinterpret_cast<uv_after_work_cb>(AsyncExecuteComplete)
                                                              ^
In file included from ../../nan/nan.h:54,
                 from ../src/main.cpp:3:
../src/main.cpp: At global scope:
/home/dadmin/.cache/node-gyp/10.16.3/include/node/node.h:573:43: warning: cast between incompatible function types from ‘void (*)(v8::Local<v8::O                            bject>)’ to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type]
       (node::addon_register_func) (regfunc),                          \
                                           ^
/home/dadmin/.cache/node-gyp/10.16.3/include/node/node.h:607:3: note: in expansion of macro ‘NODE_MODULE_X’
   NODE_MODULE_X(modname, regfunc, NULL, 0)  // NOLINT (readability/null_usage)
   ^~~~~~~~~~~~~
../src/main.cpp:42:1: note: in expansion of macro ‘NODE_MODULE’
 NODE_MODULE(diskusage, Init)
 ^~~~~~~~~~~
In file included from /home/dadmin/.cache/node-gyp/10.16.3/include/node/node.h:63,
                 from ../../nan/nan.h:54,
                 from ../src/main.cpp:3:
/home/dadmin/.cache/node-gyp/10.16.3/include/node/v8.h: In instantiation of ‘void v8::PersistentBase<T>::SetWeak(P*, typename v8::WeakCallbackInf                            o<P>::Callback, v8::WeakCallbackType) [with P = node::ObjectWrap; T = v8::Object; typename v8::WeakCallbackInfo<P>::Callback = void (*)(const v8:                            :WeakCallbackInfo<node::ObjectWrap>&)]’:
/home/dadmin/.cache/node-gyp/10.16.3/include/node/node_object_wrap.h:84:78:   required from here
/home/dadmin/.cache/node-gyp/10.16.3/include/node/v8.h:9502:16: warning: cast between incompatible function types from ‘v8::WeakCallbackInfo<node                            ::ObjectWrap>::Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<node::ObjectWrap>&)’} to ‘Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<                            void>&)’} [-Wcast-function-type]
                reinterpret_cast<Callback>(callback), type);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/dadmin/.cache/node-gyp/10.16.3/include/node/v8.h: In instantiation of ‘void v8::PersistentBase<T>::SetWeak(P*, typename v8::WeakCallbackInf                            o<P>::Callback, v8::WeakCallbackType) [with P = Nan::ObjectWrap; T = v8::Object; typename v8::WeakCallbackInfo<P>::Callback = void (*)(const v8::                            WeakCallbackInfo<Nan::ObjectWrap>&)]’:
../../nan/nan_object_wrap.h:65:61:   required from here
/home/dadmin/.cache/node-gyp/10.16.3/include/node/v8.h:9502:16: warning: cast between incompatible function types from ‘v8::WeakCallbackInfo<Nan:                            :ObjectWrap>::Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<Nan::ObjectWrap>&)’} to ‘Callback’ {aka ‘void (*)(const v8::WeakCallbackInfo<vo                            id>&)’} [-Wcast-function-type]

darauf quittierte dann das Ubuntu mit folgender Aussage von vmware den Dienst:

The CPU has been disabled by the guest operating system. Power off or reset the virtual machine. 

vorher hatte ich das Ganze unter debian 10 probiert..... da kam der Aufhänger mit gleicher Meldung erst beim Konfigurieren des ioBroker.
Auf beiden Systemen :

dadmin@iobroker:~$ nodejs -v
v10.16.3
dadmin@iobroker:~$ node -v
v10.16.3
dadmin@iobroker:~$ npm -v
6.11.3

Irgendeine Idee , was hier schief ist ? bin ich zu aktuell mit den Versionen ?

fehlpost....

Naja, iobroker im Docker und dann Docker Swarm.... das dürfte fast jeder, der iobroker installieren kann auch hinbekommen.

Anleitung hier:
https://docs.docker.com/engine/swarm/swarm-tutorial/

und dann als Service den iobroker installieren:

https://hub.docker.com/r/buanet/iobroker/

Was spricht gegen lokale Storages ?
Auf jedem Storage ist von einem anderen ein Teil oder ganzes vorhanden einer anderen Node. Somit verhält es sich wie SAN-Multicluster. Wozu also ein dedizierter Storage, der dann wieder redundant sein muss ?

Beispiel Pacemaker mit Corosync als Cluster - Engine:
Die Corosync Cluster Engine besteht im Aufbau aus vier Kernkomponenten:
Einer zwischen den einzelnen Nodes verteilten Zustandsmaschine deren Zustände und gespeicherte Information virtuell synchronisiert ist.
Einer Instanz zum Starten, Stoppen und Verteilen von den jeweiligen Anwendungen auf die einzelnen Nodes.
Einem Quorum, das über die Anzahl der verfügbaren Nodes im Verbund informiert und dazu dient, bei Teilausfällen die Datenintegrität im Cluster sicherzustellen.
Einer Datenbank zum Sammeln von Zustandsinformationen und deren zeitlichen Verlauf und Konfigurationseinstellung des Clusters. Inhalte dieser Datenbank können bei entsprechender Auswertung beispielsweise Auskunft über verschiedene Betriebsparameter wie die Ausfallzeiten einzelner Nodes liefern.
MIninal braucht man hier gerade mal 2 Maschinen.

Bei Docker Swarm , kommt es auf die Konfiguration an, die du selber bestimmst, ob auf allen nodes für deinen Service die Daten liegen , oder ob du eine bestimmte Anzahl von Replicas über deinen Cluster haben möchtest. Ebenso wieviele Worker-Nodes und wieviele Master Nodes du haben möchtest. Eine ungerade Anzahl an Master nodes ist als quorum erforderlich. Man kann eine Master-Node auch gleichzeitig als Worker-Node betreiben . Also minimal sollten es somit 2 Maschinen sein, jedoch ist einer davon gleichzeitig der Master und somit die redundanz nur n. Somit ist eine Redundanz erst mit 3 Maschinen , sowohl Master als auch Worker , mit n+1 möglich.

Bei Kubernetes spricht man von Persistent Volumes (PVs) und Persistent Volume Claims (PVCs) die aus StorageClasses (SC) einzelner Nodes mit einem bind zusammengeführt werden, und so mit einer gewissen Redundanz und Kapazität über dem Cluster (Pod) verteilt sind. Somit ist es sehr flexibel den bedürfnissen anpassbar. Auch hier braucht man minimum 3 Maschinen , damit auch die Konfiguration (etcd) redundant ausgelegt ist und ein quorum entstehen kann. Kubernetes ist hier nur über dem Docker , somit als manager und provider , aber bietet diverse vorteile, entsprechend mehr komplexität als docker swarm.

Mesos lasse ich mal lieber weg, denn das wird zu groß für unser Ziel.....(ab 9 Maschinen , wenn ich es richtig interpretiert habe)

Wie wäre es mit Kubernetes als Cluster.... Dabei ist es egal, was unten drunter liegt, z.b. Docker.

also ioBroker im Docker: https://github.com/nils/docker-ioBroker
als Hypervisor der Nodes ein Master, das deployment auf einem Pod (z.b. RasPI).

Oder Docker im Swarm Mode..... nicht ganz so flexibel aber einfacher.

Falls keiner Docker nutzen möchte und eine normale Installation nutzen möchte, gibt es Pacemaker:
https://www.linuxhelp.com/how-to-configure-high-availability-linux-cluster-with-pacemaker-in-centos

was haltet ihr von den Varianten ?