@michaellearnstocode sagte in SONOFF iHost Open-Source – ioBroker-Entwickler gesucht!:
@david-g Wir möchten, dass ioBroker die iHost-Hardware steuert und alle über vorhandene Adapter integrierten Geräte verwaltet. Wir möchten nicht viel Softwareentwicklung für ioBroker über iHost betreiben. Sollten wir uns also für die zweite Option entscheiden?
We actually want ioBroker to control the iHost hardware and manage all devices integrated by all kinds of existing adapters. We don't want to do a lot of software development for ioBroker over iHost. So We probably should go with the second option you mentioned?
Auf der offiziellen ioBroker-Downloadseite gibt es ein ioBroker-Image für Raspberry Pi 5. Daher kam unsere ursprüngliche Idee. Wir dachten, wir könnten einfach ein ioBroker-Image für iHost erstellen.
There is an ioBroker image for Raspberry Pi 5 on the ioBroker official download page. That's where our initial idea comes from. We thought we could just make an ioBroker image for iHost.
ioBroker_on_RaspberryPi5.png
Es sollte machbar sein ein ioBroker Image zu erzeugen welches auf dem iHost läuft. Allerdings halte ich es für Sinnvoll, nicht auf die Hardware-Adapter zurück zu greifen um die Hardware auf dem iHost zu steuern da es dafür bereits funktionierende Software gibt. Besser wäre es, eine entsprechend leistungsfähige API bereit zu stellen, über die der ioBroker mit der 'Standard' iHost Software kommunizieren und die Hardware steuern kann. Eine direkte Weiterleitung der Hardware an entsprechende Adapter führt da eher zu erhöhtem Aufwand bei den entsprechenden Adaptern, insbesondere wenn weitere Hardwareunterstützung im iHost entsteht. Bei Nutzung einer API lässt sich das entsprechend gut kapseln.
Dadurch kann der Benutzer entscheiden ob ein ioBroker auf dem iHost oder auf einem leistungsfähigeren System neben dem iHost laufen kann. Insbesondere wenn es um komplexe Automatisierung, Visualisierung und/oder Datensammlung geht sind die Hardware-Voraussetzungen des iHost für den Betrieb des ioBroker grenzwertig.
Durch Nutzung einer sauberen API lässt sich die notwendige Softwareentwicklung
klar segmentieren
eindeutig zuordnen
auf ein minimum reduzieren.
Wenn die API entsprechend gut dokumentiert ist dann lässt sich der iHost über diese API auch an weitere Smart-Home Systeme andocken, auch wenn sie nicht selber auf dem iHost laufen.
A.
Nachtrag: In meiner eigenen (begrenzten) Erfahrung mit Docker ist insbesondere die saubere Weiterleitung von hardware-Ressourcen eine häufige Fehlerquelle. Auch auf diese kann bei Nutzung einer API weitgehend verzichtet werden, sofern diese API via Netzwerk zugänglich ist.
