Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Samson71]

@wei
Herzlich willkommen im Forum.
Ich habe die eingebunden Links im Klartext lesbar gemacht. Das ist nichts Persönliches. Das liegt einfach daran, dass wir leider auch viel mit Spam zu kämpfen haben.

[Bluefox]

@wei sagte in SONOFF iHost Open-Source – ioBroker-Entwickler gesucht!:

Und wir freuen uns sehr über euer Feedback:
• Was erwartet ihr von iHost?
• Welche Funktionen oder Add-ons würdet ihr euch wünschen?
• Wie können wir gemeinsam eine Community-getriebene Plattform aufbauen?

I would expect the SONOFF iHost image to come with the SONOFF, Matter, and Zigbee adapters pre-installed.
However, since I don’t currently own any SONOFF devices myself, I believe the community—as a collective brain—could contribute more ideas and specific requests.

[Wei]

@samson71 Vollstes Verständnis, und vielen Dank an den Moderator für den Hinweis und die Korrektur. Ein Forum zu betreiben ist keine leichte Aufgabe – dafür haben wir großen Respekt. Wir hoffen ebenfalls, dass sich mehr Entwickler uns anschließen, um gemeinsam an sinnvollen Projekten zu arbeiten.

[Wei]

@bluefox Yes, the pre-installed system called eWeLink CUBE have all the capabilities you mentioned , with Matter bridge feature, users can bridge all the eligible managed devices to Matter platforms/fabrics, and with eWeLink smart home addon to drag all Local-control enabled eWeLink supported devices including SONOFF’s in the iHost, enjoy cloud free management, and the build-in zigbee2CUBE feature allows user to link almost any zigbee devices and manage them easily.

[apollon77]

Hm ... dann mal die Frage ... Wenn Matter Hub als Feature dabei ist - als lokales und Sicheres protokoll - warum braucht mal dann noch mehr Smart Home system oder Protokolle?

Wenn ich es verstehe ist der Benefit ioBroker auf dem System direkt laufen zu lassen? Also ist es quasi ein Server und der User erspart sich nen Raspi bzw Host?
Welche Ausstattung hat das iHost System denn? Ok laut Info 1,5 GHz Quad Core mit SD Karte und 2 oder 4GB RAM ...

Hm ... Ja klar eine "Einstiegsvariante" für Smart home um mal Dinge auszutesten.

Wenn ich die Infos zu HA verstehe läuft da nicht in Docker, sondern wird als OS direkt geflasht?

Also was wäre das sinnvolle für ioBroker? Einfach per docker drauf machen (gibt ein image)? Oder ein normales Linux image flashen und dort dann ioBroekr installieren? (Wie haben/hatten ein Raspi Image was das so tut).
Wie es mit 32 bit ist muss mal schauen weil Node.js denke inzwischen eher 64 bit vorrausssetzt?

So viel mal ein paar Gedanken

[Wei]

@apollon77
Hallo Apollon, schön, dass du in diesem Thread dabei bist. Ich möchte gerne @MichaelLearnsToCode, unseren CTO, in diese Diskussion einbeziehen.

Falls etwas unpassend ist, bitte verzeih mir – ich benutze ein Übersetzungstool, um auf Deutsch mit dir zu kommunizieren.

[arteck]

@apollon77 sagte in SONOFF iHost Open-Source – ioBroker-Entwickler gesucht!:

Wie es mit 32 bit ist muss mal schauen weil Node.js denke inzwischen eher 64 bit vorrausssetzt?

da brauchst nicht viel gucken.. zigbee mag nicht 32 bit

[MichaelLearnsToCode]

@arteck @apollon77 Ja, wir denken darüber nach, ein ioBroker-Betriebssystem-Image für iHost zu erstellen, genau wie das ioBroker-Image für Raspberry Pi 5 auf https://www.iobroker.net/#en/download

Yes, we are thinking about creating an ioBroker OS image for iHost, just like the ioBroker image for Raspberry Pi 5 on https://www.iobroker.net/#en/download

Die Spezifikationen und Funktionen von iHost finden Sie unter https://sonoff.tech/product/gateway-and-sensors/ihost/

For the specs and capabilities of iHost, please refer to https://sonoff.tech/product/gateway-and-sensors/ihost/

Node.js, Zigbee2MQTT und Node-Red laufen alle recht gut auf 32-Bit-SoCs. Wir verwenden Zigbee2MQTT und Node-Red schon lange auf iHost.

Node.js, Zigbee2MQTT, Node-Red all run pretty fine on 32 bit SoC. We have been using Zigbee2MQTT and Node-Red on iHost for a long time.

Sicher, 64-Bit-SoC ist jetzt Mainstream und wir entwickeln iHosts der neuen Generation mit 64-Bit-SoC, Wi-Fi 6 usw.

Sure, 64 bit SoC is mainstream now, and we are developing new generation iHost with 64 bit SoC, Wi-Fi 6, etc.

[MichaelLearnsToCode]

Dieser Beitrag wurde gelöscht!

[apollon77]

@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.

[David G.]

@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 😁

[MichaelLearnsToCode]

@apollon77 All Node.js LTS ones support armv7 architecture. You can refer to Node.js download page, or docker hub.

[MichaelLearnsToCode]

@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.

[David G.]

@michaellearnstocode

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/

[MichaelLearnsToCode]

@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.

[David G.]

@michaellearnstocode

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.

[MichaelLearnsToCode]

@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.

[David G.]

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.

[Asgothian]

@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.

[MichaelLearnsToCode]

@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.