NEWS
Was fehlt um das ioBroker Grundprinzip zu verstehen?
Was fehlt um das ioBroker Grundprinzip zu verstehen?
-
@liv-in-sky sagte in Das ioBroker Grundprinzip verstehen:
habe noch das gemacht - aber auf dauer alles mögliche abzudecken
nee, nee - lass mal.
Das war IMHO schon gut, dass du nur die "internen" Zusammenhänge hattest.
Da jetzt noch die externen Anbinduungen reinzubringen wird wirklich zu viel.Textlich muss auch nicht alles in der Grafik stehen. Da kann man dann im Text erklären.
Gib mir mal was Zeit.
Ich muss mir erst das Grundgerüst überlegen.
Wenn ich dann nochmal auf die zukommen darf wäre das SpitzeVideos sollen andere machen.
Die sind veraltet bevor sie fertig sind. Und dann geht kein Hai mehr dran, weil er keinen Schimmer davon hat@liv-in-sky sagte in Das ioBroker Grundprinzip verstehen:
noch ein anderer gedanke:
so ging es mir 2013/14
@homoran @liv-in-sky
Die Schaubilder sind alle super, aber die erklären doch einem Anfänger nicht "Das Grundprinzip".
Oder sehe ich das falsch?Das Grundprinzip in wenigen Sätzen à la:
Mit iobroker kannst du verschieden Systeme miteinander verbinden. Du kannst Regeln in Form von Skripten erstellen und Visualsierungen bauen. Dabei übernimmt iobroker die Anbindung an ein System mittels eines Adapters. Hast du diesen erfolgreich konfiguriert, dann bildet iobroker eine sogenannte Instanz aus. Diese Instanz sorgt dafür, dass alle verfügbaren Daten des angebundenen Systems als Objekte in iobroker dargestellt werden. Usw. Ein Piktogramm mit einem Beispiel-Datenfluß-Diagramm. Fertig. -
@homoran sagte in Das ioBroker Grundprinzip verstehen:
keinen Schimmer davon
hehehe - denken wir da an das gleiche
ich dachte auch an andere - die das wirklich können und verstehen
der gedanke war - wenn derjenige was damit verdient und von der community empfohlen wird- wird das ganze auch besser gewartet
eigentlich " win - win " , wenn's funktionieren würde
wenn das aber nicht gewünscht wird, ist das auch ok für mich - aber wir sollten wirklich irgendwie anders bzw um-denken, um das problem zu einem result zu bringen - leider fällt mir da nichts anderes ein
aber - alles gut - ich warte , was dir einfällt
@liv-in-sky sagte in Das ioBroker Grundprinzip verstehen:
eigentlich " win - win " , wenn's funktionieren würde
das klappt ja mit dem ....
wer hat denn gerade die Startseite geändert?
da war doch gerade noch das Einsteiger Seminar verlinkt??????Sorry
-
@homoran @liv-in-sky
Die Schaubilder sind alle super, aber die erklären doch einem Anfänger nicht "Das Grundprinzip".
Oder sehe ich das falsch?Das Grundprinzip in wenigen Sätzen à la:
Mit iobroker kannst du verschieden Systeme miteinander verbinden. Du kannst Regeln in Form von Skripten erstellen und Visualsierungen bauen. Dabei übernimmt iobroker die Anbindung an ein System mittels eines Adapters. Hast du diesen erfolgreich konfiguriert, dann bildet iobroker eine sogenannte Instanz aus. Diese Instanz sorgt dafür, dass alle verfügbaren Daten des angebundenen Systems als Objekte in iobroker dargestellt werden. Usw. Ein Piktogramm mit einem Beispiel-Datenfluß-Diagramm. Fertig.@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Oder sehe ich das falsch?
ja und nein

@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Ein Piktogramm mit einem Beispiel-Datenfluß-Diagramm. Fertig.
so wie in meinem Schnellschuss (to be finetuned!)

Aber auch die Struktur innerhalb von ioBroker ist nicht uninteressant.
Wenn man die verstanden hat (oder nachlesen kann) fällt einem die Logik, die Datenstruktur (z.B. nicht auf Änderung des Geräts - auf Änderung des States triggern, oder die Auswahl der DP in vis) wesentlich leichter.Oder warum :8081 für den admin und der WebAdapter für vis auf :8082
-
@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Oder sehe ich das falsch?
ja und nein

@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Ein Piktogramm mit einem Beispiel-Datenfluß-Diagramm. Fertig.
so wie in meinem Schnellschuss (to be finetuned!)

Aber auch die Struktur innerhalb von ioBroker ist nicht uninteressant.
Wenn man die verstanden hat (oder nachlesen kann) fällt einem die Logik, die Datenstruktur (z.B. nicht auf Änderung des Geräts - auf Änderung des States triggern, oder die Auswahl der DP in vis) wesentlich leichter.Oder warum :8081 für den admin und der WebAdapter für vis auf :8082
Gib mir mal 30 Minuten - ich hab da etwas angefangenesm- muss ich nur noch sauber machen und kann das dann posten - als etwas besserer Startpunkt zum verfeinern.
Edit: 30 Minuten sind um:
So sieht das bei Mir im Moment aus. Jede "Art" von Adapter kann beliebig oft installiert werden.
Beispiele für die verschiedenen Adapter sind:
- Cloud Service: Telegram, IoT, dasWetter, Tankerkönig, Traccar, etc.
- Cloud Based: hier fehlen mir Beispiele für Geräte die nur über die Hersteller-Cloud angesprochen werden
- Gateway Based: Hue, Homematic, Tuya, ...
- Hardware Based: Sonoff, Zigbee, WLed, ...
- Structure Based: Alias Manager, History, Backitup, Sourceanalytix, Szenen Adapter, ...
- Logic Engine: Node Red, JS Adapter, Device Reminder,
- UI Adapter: Vis, Yahka, Lovelace, Flot, ECharts, ...
Vielleicht hilft das ja weiter. Ich kann auch gerne das Draw.io Original bereit stellen.
A.
-
@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Oder sehe ich das falsch?
ja und nein

@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Ein Piktogramm mit einem Beispiel-Datenfluß-Diagramm. Fertig.
so wie in meinem Schnellschuss (to be finetuned!)

Aber auch die Struktur innerhalb von ioBroker ist nicht uninteressant.
Wenn man die verstanden hat (oder nachlesen kann) fällt einem die Logik, die Datenstruktur (z.B. nicht auf Änderung des Geräts - auf Änderung des States triggern, oder die Auswahl der DP in vis) wesentlich leichter.Oder warum :8081 für den admin und der WebAdapter für vis auf :8082
@homoran sagte in Das ioBroker Grundprinzip verstehen:
@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Oder sehe ich das falsch?
ja und nein

@ofbeqnpolkkl6mby5e13 sagte in Das ioBroker Grundprinzip verstehen:
Ein Piktogramm mit einem Beispiel-Datenfluß-Diagramm. Fertig.
so wie in meinem Schnellschuss (to be finetuned!)

Hab das Ganze mal bisschen ergänzt:

-
Gib mir mal 30 Minuten - ich hab da etwas angefangenesm- muss ich nur noch sauber machen und kann das dann posten - als etwas besserer Startpunkt zum verfeinern.
Edit: 30 Minuten sind um:
So sieht das bei Mir im Moment aus. Jede "Art" von Adapter kann beliebig oft installiert werden.
Beispiele für die verschiedenen Adapter sind:
- Cloud Service: Telegram, IoT, dasWetter, Tankerkönig, Traccar, etc.
- Cloud Based: hier fehlen mir Beispiele für Geräte die nur über die Hersteller-Cloud angesprochen werden
- Gateway Based: Hue, Homematic, Tuya, ...
- Hardware Based: Sonoff, Zigbee, WLed, ...
- Structure Based: Alias Manager, History, Backitup, Sourceanalytix, Szenen Adapter, ...
- Logic Engine: Node Red, JS Adapter, Device Reminder,
- UI Adapter: Vis, Yahka, Lovelace, Flot, ECharts, ...
Vielleicht hilft das ja weiter. Ich kann auch gerne das Draw.io Original bereit stellen.
A.
@asgothian Danke - das muss ich jetzt erst einmal verdauen.
Mich hat's auf den ersten Blick erschlagenkann aber auch schon an den englischen Texten liegen.
Nicht dass ich damit Probleme habe, ich versuche das nur immer mit den Augen eines Newbies zu sehen -
Gib mir mal 30 Minuten - ich hab da etwas angefangenesm- muss ich nur noch sauber machen und kann das dann posten - als etwas besserer Startpunkt zum verfeinern.
Edit: 30 Minuten sind um:
So sieht das bei Mir im Moment aus. Jede "Art" von Adapter kann beliebig oft installiert werden.
Beispiele für die verschiedenen Adapter sind:
- Cloud Service: Telegram, IoT, dasWetter, Tankerkönig, Traccar, etc.
- Cloud Based: hier fehlen mir Beispiele für Geräte die nur über die Hersteller-Cloud angesprochen werden
- Gateway Based: Hue, Homematic, Tuya, ...
- Hardware Based: Sonoff, Zigbee, WLed, ...
- Structure Based: Alias Manager, History, Backitup, Sourceanalytix, Szenen Adapter, ...
- Logic Engine: Node Red, JS Adapter, Device Reminder,
- UI Adapter: Vis, Yahka, Lovelace, Flot, ECharts, ...
Vielleicht hilft das ja weiter. Ich kann auch gerne das Draw.io Original bereit stellen.
A.
@asgothian sagte: Beispiele für die verschiedenen Adapter sind:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
- UI Adapter: Admin, ...
-
@asgothian sagte: Beispiele für die verschiedenen Adapter sind:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
- UI Adapter: Admin, ...
@paul53 sagte in Das ioBroker Grundprinzip verstehen:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
ja
@Asgothian
Doch sieht als Basis gut aus - mit ein paar Erläuterungen müsste man das schon hinbekommen.
jetzt ist doch intern und extern in einem Diagramm, dafür fehlt mit ein wenig noch die ObjektstrukturIch mach für heute Schluss und verdaue das heutige erst mal.
Danke an alle, war schön konstruktiv
-
@asgothian sagte: Beispiele für die verschiedenen Adapter sind:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
- UI Adapter: Admin, ...
@paul53 sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte: Beispiele für die verschiedenen Adapter sind:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware. Die gesamte Intelligenz ist im Adapter.
Letztendlich ist da genau der Unterschied zwischen "gateway" und "hardware" basiert: Gateway basierende Adapter kommunizieren mit einem Gateway mit eigener Intelligenz, wobei auch mehrere Systeme parallel mit dem gleichen Gateway kommunizieren können. Hardware basierte Adapter sprechen direkt mit der Hardware - ggf. über einen (dummen) Umsetzer (Zigbee-Stick, ZWave Stick, Netzwerkkarte) der selber keinerlei Logik zum Steuern der Geräte hat.
UI Adapter: Admin, ...
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
p.s. Wenn ich da zigbee schreibe, dann ist das der Zigbee Adapter, nicht Hue oder deconz, die beide Gateway basierte Adapter sind.
-
@paul53 sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte: Beispiele für die verschiedenen Adapter sind:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware. Die gesamte Intelligenz ist im Adapter.
Letztendlich ist da genau der Unterschied zwischen "gateway" und "hardware" basiert: Gateway basierende Adapter kommunizieren mit einem Gateway mit eigener Intelligenz, wobei auch mehrere Systeme parallel mit dem gleichen Gateway kommunizieren können. Hardware basierte Adapter sprechen direkt mit der Hardware - ggf. über einen (dummen) Umsetzer (Zigbee-Stick, ZWave Stick, Netzwerkkarte) der selber keinerlei Logik zum Steuern der Geräte hat.
UI Adapter: Admin, ...
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
p.s. Wenn ich da zigbee schreibe, dann ist das der Zigbee Adapter, nicht Hue oder deconz, die beide Gateway basierte Adapter sind.
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware.
Das würde ich ebenfalls Gateways nennen um das Prinzip klarer kommunizieren zu können!
Wobei der Netzwerkkartentreiber ja auch als Intelligenz herhalten könnte@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
das würde bei mir aber in die "interne" Struktur gehören
ihr schafft mich noch
-
Gib mir mal 30 Minuten - ich hab da etwas angefangenesm- muss ich nur noch sauber machen und kann das dann posten - als etwas besserer Startpunkt zum verfeinern.
Edit: 30 Minuten sind um:
So sieht das bei Mir im Moment aus. Jede "Art" von Adapter kann beliebig oft installiert werden.
Beispiele für die verschiedenen Adapter sind:
- Cloud Service: Telegram, IoT, dasWetter, Tankerkönig, Traccar, etc.
- Cloud Based: hier fehlen mir Beispiele für Geräte die nur über die Hersteller-Cloud angesprochen werden
- Gateway Based: Hue, Homematic, Tuya, ...
- Hardware Based: Sonoff, Zigbee, WLed, ...
- Structure Based: Alias Manager, History, Backitup, Sourceanalytix, Szenen Adapter, ...
- Logic Engine: Node Red, JS Adapter, Device Reminder,
- UI Adapter: Vis, Yahka, Lovelace, Flot, ECharts, ...
Vielleicht hilft das ja weiter. Ich kann auch gerne das Draw.io Original bereit stellen.
A.
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Jede "Art" von Adapter kann beliebig oft installiert werden.
Das wenn du so, einem Anfänger erzählst, hast du ihn doch schon veräppelt

-
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Jede "Art" von Adapter kann beliebig oft installiert werden.
Das wenn du so, einem Anfänger erzählst, hast du ihn doch schon veräppelt

@crunchip sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Jede "Art" von Adapter kann beliebig oft installiert werden.
Das wenn du so, einem Anfänger erzählst, hast du ihn doch schon veräppelt

hatte ich auch schon auf der Feder, da gibt es dann diese schöne Meldung `can only be installed once' oder so
-
@paul53 sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte: Beispiele für die verschiedenen Adapter sind:
Ist Zigbee nicht "Gateway Based"? Ebenso Z-Wave.
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware. Die gesamte Intelligenz ist im Adapter.
Letztendlich ist da genau der Unterschied zwischen "gateway" und "hardware" basiert: Gateway basierende Adapter kommunizieren mit einem Gateway mit eigener Intelligenz, wobei auch mehrere Systeme parallel mit dem gleichen Gateway kommunizieren können. Hardware basierte Adapter sprechen direkt mit der Hardware - ggf. über einen (dummen) Umsetzer (Zigbee-Stick, ZWave Stick, Netzwerkkarte) der selber keinerlei Logik zum Steuern der Geräte hat.
UI Adapter: Admin, ...
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
p.s. Wenn ich da zigbee schreibe, dann ist das der Zigbee Adapter, nicht Hue oder deconz, die beide Gateway basierte Adapter sind.
@asgothian sagte: über einen (dummen) Umsetzer (Zigbee-Stick, ZWave Stick, Netzwerkkarte) der selber keinerlei Logik zum Steuern der Geräte hat.
Wirklich dumm ohne Microcontroller? Erfolgt das Anlernen der Geräte nicht an den Stick? Ein wirklich dummes Funkmodul ist das von HomeMatic.
-
Können wir das bitte etwas einschränken.
Ich denke die Idee ist klar, und ich werde mir die Freiheit nehmen (mit entsprechender Formulierung) auch die exakte Wahrheit im Sinne der Verständlichkeit für Einsteiger ein wenig zu verbiegen -
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware.
Das würde ich ebenfalls Gateways nennen um das Prinzip klarer kommunizieren zu können!
Wobei der Netzwerkkartentreiber ja auch als Intelligenz herhalten könnte@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
das würde bei mir aber in die "interne" Struktur gehören
ihr schafft mich noch
@homoran sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware.
Das würde ich ebenfalls Gateways nennen um das Prinzip klarer kommunizieren zu können!
An der Stelle ist es meiner Meinung nach wichtig sauber zu trennen. Wenn ein (externes) Gateway existiert dann impliziert das
- das einzelne Aktionen ohne einen laufenden ioBroker funktionieren (können)
- das das Gateway auch ohne den ioBroker angesprochen werden kann
- die Gateways eigene Intelligenz (in Form einer nicht im ioBroker laufenden Software) besitzen - so ist das (wenn meine geringen Homematic Kenntnisse ausreichen) bei Homematic mit einer PiVCcu)
Bei Hardware-basierten Adaptern ist das nicht so, der ioBroker spricht halt direkt und zumeist exclusiv mit der Hardware.
Nebenbei gibt es auch noch Adapter die nicht sauber in die Trennung passen. So bin ich bei Sonoff und MQTT nicht sicher wo der einsortiert gehört. MQTT müsste eigentlich als "cloud basiert" eingestuft werden.
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
das würde bei mir aber in die "interne" Struktur gehören
In die Interne Struktur - ja, aber als eigener Kasten, nicht als einer der "UI Adapter"
ihr schafft mich noch
Wir arbeiten dran

Spass beiseite.
Ich hatte für mich innen und aussen gemeinsam dargestellt - es ist aber durchaus denkbar die interne Struktur einfach zu überblenden und vereinfacht darzustellen so das nur die externen Verbindungen erhalten bleiben.
Ich schaue mal ob ich das Draw.IO Original hier hinterlegen kann.A.
p.s. Hinter dem Spoiler ist das Draw.io Original. -
@asgothian sagte: über einen (dummen) Umsetzer (Zigbee-Stick, ZWave Stick, Netzwerkkarte) der selber keinerlei Logik zum Steuern der Geräte hat.
Wirklich dumm ohne Microcontroller? Erfolgt das Anlernen der Geräte nicht an den Stick? Ein wirklich dummes Funkmodul ist das von HomeMatic.
@paul53 sagte in Das ioBroker Grundprinzip verstehen:
Wirklich dumm ohne Microcontroller? Erfolgt das Anlernen der Geräte nicht an den Stick? Ein wirklich dummes Funkmodul ist das von HomeMatic.
Nein, das anlernen findet nicht am Stick statt. Das Anlernen findet am Zigbee-Herdsman statt. Die Verschlüsselungsdaten werden allerdings auch auf dem Stick gespeichert.
A.
-
@homoran sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware.
Das würde ich ebenfalls Gateways nennen um das Prinzip klarer kommunizieren zu können!
An der Stelle ist es meiner Meinung nach wichtig sauber zu trennen. Wenn ein (externes) Gateway existiert dann impliziert das
- das einzelne Aktionen ohne einen laufenden ioBroker funktionieren (können)
- das das Gateway auch ohne den ioBroker angesprochen werden kann
- die Gateways eigene Intelligenz (in Form einer nicht im ioBroker laufenden Software) besitzen - so ist das (wenn meine geringen Homematic Kenntnisse ausreichen) bei Homematic mit einer PiVCcu)
Bei Hardware-basierten Adaptern ist das nicht so, der ioBroker spricht halt direkt und zumeist exclusiv mit der Hardware.
Nebenbei gibt es auch noch Adapter die nicht sauber in die Trennung passen. So bin ich bei Sonoff und MQTT nicht sicher wo der einsortiert gehört. MQTT müsste eigentlich als "cloud basiert" eingestuft werden.
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
das würde bei mir aber in die "interne" Struktur gehören
In die Interne Struktur - ja, aber als eigener Kasten, nicht als einer der "UI Adapter"
ihr schafft mich noch
Wir arbeiten dran

Spass beiseite.
Ich hatte für mich innen und aussen gemeinsam dargestellt - es ist aber durchaus denkbar die interne Struktur einfach zu überblenden und vereinfacht darzustellen so das nur die externen Verbindungen erhalten bleiben.
Ich schaue mal ob ich das Draw.IO Original hier hinterlegen kann.A.
p.s. Hinter dem Spoiler ist das Draw.io Original.@asgothian sagte in Das ioBroker Grundprinzip verstehen:
An der Stelle ist es meiner Meinung nach wichtig sauber zu trennen. Wenn ein (externes) Gateway existiert dann impliziert das
wenn hier Einsteiger schon schreiben, dass sie den Begriff Gateway erst einmal googlen mussten.....
Ich nutze sowieso immer die Formulierung ...über ein Gateway/Zentrale/Bridge/wasAuchImmer angebunden sind...
-
@homoran sagte in Das ioBroker Grundprinzip verstehen:
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Nein, Zigbee und Zwave nutzen direkt die am ioBroker angeschlossene Hardware.
Das würde ich ebenfalls Gateways nennen um das Prinzip klarer kommunizieren zu können!
An der Stelle ist es meiner Meinung nach wichtig sauber zu trennen. Wenn ein (externes) Gateway existiert dann impliziert das
- das einzelne Aktionen ohne einen laufenden ioBroker funktionieren (können)
- das das Gateway auch ohne den ioBroker angesprochen werden kann
- die Gateways eigene Intelligenz (in Form einer nicht im ioBroker laufenden Software) besitzen - so ist das (wenn meine geringen Homematic Kenntnisse ausreichen) bei Homematic mit einer PiVCcu)
Bei Hardware-basierten Adaptern ist das nicht so, der ioBroker spricht halt direkt und zumeist exclusiv mit der Hardware.
Nebenbei gibt es auch noch Adapter die nicht sauber in die Trennung passen. So bin ich bei Sonoff und MQTT nicht sicher wo der einsortiert gehört. MQTT müsste eigentlich als "cloud basiert" eingestuft werden.
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Würde ich an dieser Stelle ungern aufführen. Auch wenn es technisch korrekt ist sehe ich den Admin eher als Wartungswerkzeug für den ioBroker selber und nicht als (end)User Interface.
das würde bei mir aber in die "interne" Struktur gehören
In die Interne Struktur - ja, aber als eigener Kasten, nicht als einer der "UI Adapter"
ihr schafft mich noch
Wir arbeiten dran

Spass beiseite.
Ich hatte für mich innen und aussen gemeinsam dargestellt - es ist aber durchaus denkbar die interne Struktur einfach zu überblenden und vereinfacht darzustellen so das nur die externen Verbindungen erhalten bleiben.
Ich schaue mal ob ich das Draw.IO Original hier hinterlegen kann.A.
p.s. Hinter dem Spoiler ist das Draw.io Original.@asgothian sagte in Das ioBroker Grundprinzip verstehen:
Nebenbei gibt es auch noch Adapter die nicht sauber in die Trennung passen. So bin ich bei Sonoff und MQTT nicht sicher wo der einsortiert gehört. MQTT müsste eigentlich als "cloud basiert" eingestuft werden.
MQTT ist ein sehr spezielles Thema, da man bei ioBroker ja zwei Möglichkeiten hat, es zu nutzen.
Als Client, oder als Server.
Ich würde es einfach nur mit einzeichnen, das es möglich ist mit mqtt zu kommunizieren.
Ansonsten müsste es zweimal in der Grafik erscheinen.Wie es mit Sonoff aussieht, weiß ich nicht.
Das kann bestimmt jemand beantworten, welcher es einsetzt. -
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
An der Stelle ist es meiner Meinung nach wichtig sauber zu trennen. Wenn ein (externes) Gateway existiert dann impliziert das
wenn hier Einsteiger schon schreiben, dass sie den Begriff Gateway erst einmal googlen mussten.....
Ich nutze sowieso immer die Formulierung ...über ein Gateway/Zentrale/Bridge/wasAuchImmer angebunden sind...
@homoran
Ich musste den Begriff Gateway nun nicht googeln, aber das müssen Einsteiger sicher . Sonst denken die sicher erst mal an einenFlughafen
-
@asgothian sagte in Das ioBroker Grundprinzip verstehen:
An der Stelle ist es meiner Meinung nach wichtig sauber zu trennen. Wenn ein (externes) Gateway existiert dann impliziert das
wenn hier Einsteiger schon schreiben, dass sie den Begriff Gateway erst einmal googlen mussten.....
Ich nutze sowieso immer die Formulierung ...über ein Gateway/Zentrale/Bridge/wasAuchImmer angebunden sind...
@homoran An dieser Stelle zitiere ich Dich einfach mal:
@homoran sagte in Das ioBroker Grundprinzip verstehen:
Ich denke die Idee ist klar, und ich werde mir die Freiheit nehmen (mit entsprechender Formulierung) auch die exakte Wahrheit im Sinne der Verständlichkeit für Einsteiger ein wenig zu verbiegen
Genau so ist es richtig. In wie weit die einzelnen Klassen von Adaptern getrennt werden und welcher Adapter zu welcher Klasse gerechnet wird ist am Ende auch Ansichtssache.
@homoran sagte in Das ioBroker Grundprinzip verstehen:
wenn hier Einsteiger schon schreiben, dass sie den Begriff Gateway erst einmal googlen mussten.....
... dann brauchen wir einen besseren Begriff dafür.

A.