SONOFF iHost Open-Source – ioBroker-Entwickler gesucht!
-
@michaellearnstocode Thanks, which Node.js versions you get for 32 bit? I remember the current LTS ones officially only build on 64 bit. But if it works might be fine.
-
@apollon77 sagte in SONOFF iHost Open-Source – ioBroker-Entwickler gesucht!:
Also was wäre das sinnvolle für ioBroker? Einfach per docker drauf machen (gibt ein image)?
Bei der Zielgruppe fände ich ein docker Image gut.
Da fällt die Systempflege was leichter.
Gerade das schätzen ja viele bei HA.
Mit Hardware durchreichen etc hat der User dann auch nichts zu tun bei einem extra Image für das Gerät.4GB RAM kann natürlich schnell knapp werden.
Der Host unter dem Docker Image will ja auch noch ein wenig haben.@Wei
Ich finde es cool, dass ihr probiert das Gerät so offen zu machen.
Haut doch iobroker by default drauf^^.
iHost powerd by iobroker
-
@apollon77 All Node.js LTS ones support armv7 architecture. You can refer to Node.js download page, or docker hub.
-
@david-g Vielen Dank für Ihren Vorschlag.
Thank you very much for your suggestion.
Wir machen uns gerade mit der Installation und Wartung von ioBroker vertraut. In zwei bis drei Wochen werden wir mit der Arbeit an ioBroker auf iHost beginnen. Wir haben also noch etwas Zeit, darüber nachzudenken.
We are currently getting ourselves familiar with ioBroker's installation and maintenance. We will start to work on ioBroker on iHost in 2 or 3 weeks. So we still have some time to think about it.
4 GB RAM könnten immer noch viel übrig sein, je nachdem, was Sie mit der Smart-Home-Softwareplattform machen. Ich betreibe derzeit einen HA auf iHost mit nur 2 GB RAM. Der HA hat sechs manuell installierte Add-ons, verwaltet mehr als 80 Geräte und mehrere Automatisierungen und verfügt noch über 1,2 GB RAM.
4GB of RAM could still be a lot left depending on what you do with smart home software platform. I am currently running a HA on iHost with only 2GB of RAM. The HA has 6 manually installed add-ons, is managing more than 80 devices and several automations, it still has 1.2GB of RAM left.
-
Was docker angeht (ich habe iobroker noch nie in docker verwendet), liest Mn hier im Forum recht oft vom baunet docker Container.
https://docs.buanet.de/de/iobroker-docker-image/docs/ -
@david-g Danke für die Information Andre. Wir werden versuchen, ihn zu kontaktieren und für ioBroker im iHost-Projekt einzuladen.
Thank you for letting us know Andre. We will try to contact and invite him for ioBroker on iHost project.
-
Plant ihr sämtliche Geräte über einen Adapter (eure Api) einzubinden oder die Hardware direkt an den iobroker weiterzuleiten?
Bei erster Variante nutzt man natürlich eure Software (was ja vermutlich gewünscht ist), bei zweiter Variante hat man alle Freiheiten vom iobroker und kann alles mit dein hauseigenen Adaptern ansprechen. Zigbee, Matter etc.
-
@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.
-
Ich fänd die zweite Option am schönsten, und iobroker die Hardware steuern zu lassen.
Ob Docker oder direkt das Image.... Keine Ahnung.
Hat beides Vor- und Nachteile aus meiner Sicht."Leute" die so ein "All in one" Gerät kaufen erwarten ggf nicht, selber ein Linux administrieren zu müssen.
Bei Docker hat man evtl mehr Probleme mit dem Netzwerk.
-
@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.
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.
-
@asgothian @David-G Vielen Dank euch beiden für den Vorschlag. Ich weiß das wirklich zu schätzen.
Thank you both for the suggestion. I sincerely appreciate it.
Ich werde auf dieses Thema zurückkommen, sobald mein Team und ich mehr über ioBroker wissen.
I will get back to this topic after I and my team have more understanding of ioBroker.
-
@michaellearnstocode A short note about "RAM usage":
ioBroker by defsult runs each plugin in an own Node.js process. This is more reliable regarding code issues but also needs a bit more RAM. Sure, you still get a certain number of processes into 2GB or such, but in fcat you run against limkts earlier as with eg Home Assistant where anything runs in one python process (beside additional Docker containers).
For systems with limited RAM ioBroker has the so called "Compact Mode", where we also allow to run multiple plugins in the same Node.js process (see https://github.com/ioBroker/ioBroker.js-controller?tab=readme-ov-file#start-adapter-instances-in-compact-mode).
