@klassisch

Es gibt heute nichts Simpleres als komplexe Installationen mit vielen Anhängigkeiten mit Containern zu handhaben. Containerfunktionen gibt es je nach Unix Variante seit 10 bis 15 Jahren und länger. Im Kernal, im Unix-System fest verankert. Docker Inc. war halt nur der erste das analog zu Github für Sourcecode breit zugänglich gemacht hat. Nichts hilft besser und mehr beim Deployment, Verschieben, Sichern, Wiederherstellung und Administrieren als Container.

Docker oder ähnliches ist seit Jahren auch kein Nerdzeug mehr. Es ist Standard. Wie git oder apt oder whatever. Das hatten wir früher(tm) auch alles nicht, kaum jemand würde heute drauf verzichten wollen.

Würde ich einem Einsteiger der nur ein einziges Paket betreiben will jetzt nicht direkt unbedingt raten, aber wer das schon kann und kennt wird sich die Frage nach Ja oder Nein gar nicht stellen. Und es ist gemessen am Komfort und Stabilität kein Hexenwerk und überhaupt kein Ressourcen Thema. Weil Teil von Unix. Simpel eben.

An MQTT wird der engagierte Hobby Smarthomer auf Dauer nicht vorbeikommen. Es ist das Protokoll des IoT. Aus vielen guten Gründen.

Für Steckdosen / Aktoren habe ich immer ein offenes Ohr, wenn es neue gute Vorschläge gibt. Die Shelly’s werde ich mir vormerken für den nächsten Kauf. Danke dafür!

Ich habe zuletzt vier tolle Steckdosen die echt wertig sind und super zuverlässig arbeiten, 16 A schalten und die Leistung recht genau messen für 32 EUR gekauft. Die Inbetriebnahme dürfte (für mich) schneller gewesen sein als dass was ich oben gelesen haben. Flash via OTA (over the air) Tasmota und WLAN einrichten. Fertig.

Es gibt auch fertige Tasmota Dosen für um die 20 EUR. Ein Pluspunkt dabei wäre für mich MQTT als Protokoll (Qualität weiß ich dazu aber nicht).

Letztlich muss das immer jeder für sich entscheiden. Ich möchte wirklich nur anmerken, dass es auch andere sehr gute Lösungen gibt die man sich ansehen kann. Sehr gut bedeutet für mich auch „extrem einfache Pflege und Stabilität im Betrieb“. Spaß am weiter entwickenn frickeln, aber keine Not mit den Basics. Und wenn was schief geht, Container droppen und neu hochziehen. Dauer: etwa so lange wie ein Download des Pakets.

Kennt man mehrere Optionen dann ist die eigene Entscheidung einfach leichter. In diesem Sinne diese Anregungen.

Konstruktiv und im besten freundlichsten Sinne.

@klassisch

Es gibt heute nichts Simpleres als komplexe Installationen mit vielen Anhängigkeiten mit Containern zu handhaben. Containerfunktionen gibt es je nach Unix Variante seit 10 bis 15 Jahren und länger. Im Kernal, im Unix-System fest verankert. Docker Inc. war halt nur der erste das analog zu Github für Sourcecode breit zugänglich gemacht hat. Nichts hilft besser und mehr beim Deployment, Verschieben, Sichern, Wiederherstellung und Administrieren als Container.

Docker oder ähnliches ist seit Jahren auch kein Nerdzeug mehr. Es ist Standard. Wie git oder apt oder whatever. Das hatten wir früher(tm) auch alles nicht, kaum jemand würde heute drauf verzichten wollen.

Würde ich einem Einsteiger der nur ein einziges Paket betreiben will jetzt nicht direkt unbedingt raten, aber wer das schon kann und kennt wird sich die Frage nach Ja oder Nein gar nicht stellen. Und es ist gemessen am Komfort und Stabilität kein Hexenwerk und überhaupt kein Ressourcen Thema. Weil Teil von Unix. Simpel eben.

An MQTT wird der engagierte Hobby Smarthomer auf Dauer nicht vorbeikommen. Es ist das Protokoll des IoT. Aus vielen guten Gründen.

Für Steckdosen / Aktoren habe ich immer ein offenes Ohr, wenn es neue gute Vorschläge gibt. Die Shelly’s werde ich mir vormerken für den nächsten Kauf. Danke dafür!

Ich habe zuletzt vier tolle Steckdosen die echt wertig sind und super zuverlässig arbeiten, 16 A schalten und die Leistung recht genau messen für 32 EUR gekauft. Die Inbetriebnahme dürfte (für mich) schneller gewesen sein als dass was ich oben gelesen haben. Flash via OTA (over the air) Tasmota und WLAN einrichten. Fertig.

Es gibt auch fertige Tasmota Dosen für um die 20 EUR. Ein Pluspunkt dabei wäre für mich MQTT als Protokoll (Qualität weiß ich dazu aber nicht).

Letztlich muss das immer jeder für sich entscheiden. Ich möchte wirklich nur anmerken, dass es auch andere sehr gute Lösungen gibt die man sich ansehen kann. Sehr gut bedeutet für mich auch „extrem einfache Pflege und Stabilität im Betrieb“. Spaß am weiter entwickenn frickeln, aber keine Not mit den Basics. Und wenn was schief geht, Container droppen und neu hochziehen. Dauer: etwa so lange wie ein Download des Pakets.

Kennt man mehrere Optionen dann ist die eigene Entscheidung einfach leichter. In diesem Sinne diese Anregungen.

Konstruktiv und im besten freundlichsten Sinne.

@cw50

Wenn beide Server auf dem Raspi auf unterschiedlichen Ports laufen, dann sollte das ohne Probleme gehen.

Wichtig ist, wo die Dosen sich einhängen. Also gegen welchen der dann beiden vorhandenen Server die sich verbinden würden (Tasmota cfg. auf der Dose).

Ich würde das eher so machen, dass beide Server identisch konfiguriert sind, aber sicherstellen das nur einer zum Testen läuft. Dann muss Du nur auf dem Raspi Änderungen vornehmen.

EDIT: ioBroker und mosquitto können zeitgleich auf dem selben Raspi laufen. Jedoch nicht die Adapter / Instanzen mqtt.x (server-Modus) zusammen mit dem Mosquitto auf den selben Ports.

Docker ist eine etwas größere Sache. Das geht über einen Post im Form etwas hinaus.

Es geht darum fertig konfigurierte Environments einfach zur Verfügung zu stellen. Eine "Art" (nein, nicht schlagen! ) Virtualisierung im weitesten Sinne. Dreht übrigens hervorragend auf meinem Raspi 4B.

Ich bin auch noch recht frisch im Thema und ich habe mir auch einen abgefrickelt mit dem mqtt.0 und dem sonoff.0

Vor allem habe ich nie verstanden, warum ich meine mit Tasmota 9.2.0 geflashten Dosen auf die sonoff.0 hängen soll, der einen anderen Port haben muss (1886 oder 1500 oder whatever) als der mqtt.0 (1883) der den Server macht.

Ich nutzte bisher immer einen mosquitto als mqtt Server unabhängig von ioBroker. Aus Gründen.

Ich bin wohl auch nicht der einzige der damit Probleme hatte. Egal. Ich habe das wie folgt gelöst und bin mit dem Ergebnis sehr zufrieden.

1.)
Einrichten des mosquitto mqtt Servers im Betriebssystem (oder wie bei mir als Container mit Docker). Der Server lauscht auf 1883 oder / und 1884 (SSL). Er ist mit einem Usernamen und Passwort versehen.

2.)
Alle Steckdosen verbinden sich gegen den mosquitto auf Port 1883 mit Namen und Passwort welches dort hinterlegt ist (mqtt Config in Tasmota). Wenn das läuft, dann blinkt die Lampe an der Steckdose nicht und man könnte z. B. vom Tablet oder Handy mit einer mqtt App auch Befehle versenden. D. h. die Dosen sind jetzt soweit fertig und drehen bereits.

3).
Im ioBroker installiere ich zunächst den mqtt im Modus „Client/Subscriber“, gebe ihm die Verbindungsdaten zum mosquitto (IP) und Port 1883. Außerdem Name und Passwort, damit er sich beim mosquitto anmelden kann. Verbindung testen (Button unten links)

mqtt Einstellen des mqtt.0 habe ich als Bild angehängt.

4.)
Wenn das alles soweit läuft, dann baut sich bei den Objekten unter mqtt.0 der Baum automagisch auf. Die Objekt ID z. B. für Schalter in vis.0 ist aus dem Bild in der Anlage ersichtlich.

Es gibt andere Möglichkeiten. Aber nach allem was ich so getestet habe ist das die (für mich!) sinnvollste Lösung. Vor allem wenn man weitere Tools an mqtt anflanschen möchte (z. B. Node-Red o. ä.).

Sonoff.0 ist in dieser Art der Anbindung nicht erforderlich bzw. nicht installiert.

Hoffe es hilft.

mqtt.0 Einstellungen

Schaltpunkt der auszuwählen ist, wenn man in vis.0 z. B. einen Schalter dafür anlegt

Beispielteintrag vis.0

docker-compose.yaml

version: '3.7'

services:
  
  iobroker:
    image: buanet/iobroker:latest
    volumes:
      - ./iobrokerdata:/opt/iobroker
      - /etc/localtime:/etc/localtime
    container_name: iobroker
    network_mode: bridge
    ports:
      - "8081-8089:8081-8089"
    restart: always
    environment:
      - TZ=Europe/Berlin
    hostname: iobroker

Tja, wenn man einfach kopiert und nicht drüber philosophiert oder so.

Ich habe einfach das docker-compose file vom Hub kopiert und nicht weiter drüber nachgedacht. Da mir die Probleme erst später über den Weg gelaufen sind, habe ich da keinen Bezug zu hergestellt.

Das Original reicht nur den Port 8081 über die Bridge durch. Das ist natürlich zu wenig. Ich habe das jetzt mal proaktiv auf 8081 bis 8089 erweitert.

Das File ist nun überarbeitet und damit komme ich an den web.0 und auch an den vis.0 ohne das ich noch etwas am ioBroker hätte tun müssen.

Zur Sicherheit habe ich den mosquitto Port in dessen config file aber auch noch angepasst (s. weiter oben).

Vielleicht hilft es jemand anderen mal.

Danke an alle die sich mit meiner Frage rumgeschlagen haben!

@homoran sagte in vis beendet sich sofort mit (540) (NO_ERROR):

ist alles ok.
vis startet nur einmalig und "beendet"sich dann wieder.
Daher auch keine Ampel
die 540 ist der Prozess mitcdem vis läuft.

Danke für diese Information. Dann forsche ich nicht weiter an dieser Stelle.

Was käme noch in Frage?

Und was hat es mit Logzeilen (s. o.) 6, 9, 11 und 16 auf sich? Was passiert da?

Ich habe noch einen wichtigen Hinweis übersehen bzw. nicht bedacht: Ich nutze als mqtt Broker den Mosquitto und der lauscht auf den Ports 9000:9001 für SSL Verbindungen.

Ich hatte in anderen Posts gelesen, dass der die bessere Wahl sei.... (no complains).

Ich werde da heute abend mal rumschrauben. Falls jemand vorab noch eine (auch gerne nur wage) Idee hat: gerne her damit.

Danke!

@wendy2702 sagte in vis beendet sich sofort mit (540) (NO_ERROR):

@ionode was passiert wenn du hinter der Instanz VIS.0 auf das letzte Icon klickst?

Da passiert auch nichts (mehr als einmalgeprüft). Da liegt doch auch nur der Link auf die Webadresse des VIS hinter oder macht das noch etwas anderes?

@thomas-braun

Weil ich da später noch $Dinge dranflanschen möchte. Auch mit Container(n)

@thomas-braun

Ja, dass läuft auf einem Raspi

Hallo!

Vorab: ich bin noch ganz frisch am Start und auch die Installation ist keine zwei Tage alt bzw. ist noch im Aufbau.

Ich hänge jetzt fest. Ich habe schon einiges im Web und natürlich hier im Formu abgeklappert, aber ich komme einfach nicht weiter.

Ist-Zustand
Raspberry Pi 4 B mit Rasipian OS (lite) letzter Update / Upgrade Stand
Installation von Docker und das Docker Image von buanet/ioBroker.docker 5.1.0

node v12.21.0
nodejs v12.21.0
npm 6.14.11

Problem
Weder vis.o beendet sich sofort nach dem Start wieder und ist daher unter http://xxx.xxx.xxx.xxx:8082/vis/edit.html nicht erreichbar. auch web.0 unter http://xxx.xxx.xxx.xxx:8082 meldet sich (nachvollziehbar) nicht. Alle Adapter sind auf dem letzten Stand

Im Log finde ich nur die Fehlermeldungen, mit denen ich aber nicht weiter komme. Ich habe das Log gelöscht. Und dann versucht die Instanz vis.0 zu starten:

host.iobroker	2021-03-02 21:06:24.659	info	instance system.adapter.vis.0 terminated while should be started once
vis.0	2021-03-02 21:06:24.044	info	(540) Terminated (NO_ERROR): Without reason
vis.0	2021-03-02 21:06:23.436	info	(540) vis license is OK.
vis.0	2021-03-02 21:06:23.242	info	(540) starting. Version 1.3.4 in /opt/iobroker/node_modules/iobroker.vis, node: v12.21.0, js-controller: 3.2.16
vis.0	2021-03-02 21:06:23.181	debug	(540) statesDB connected
vis.0	2021-03-02 21:06:23.180	debug	(540) States connected to redis: 127.0.0.1:9000
vis.0	2021-03-02 21:06:23.172	debug	(540) States create User PubSub Client
vis.0	2021-03-02 21:06:23.171	debug	(540) States create System PubSub Client
vis.0	2021-03-02 21:06:23.163	debug	(540) Redis States: Use Redis connection: 127.0.0.1:9000
vis.0	2021-03-02 21:06:23.160	debug	(540) objectDB connected
vis.0	2021-03-02 21:06:23.150	debug	(540) Objects connected to redis: 127.0.0.1:9001
vis.0	2021-03-02 21:06:23.138	debug	(540) Objects client initialize lua scripts
vis.0	2021-03-02 21:06:23.137	debug	(540) Objects create User PubSub Client
vis.0	2021-03-02 21:06:23.135	debug	(540) Objects create System PubSub Client
vis.0	2021-03-02 21:06:23.132	debug	(540) Objects client ready ... initialize now
vis.0	2021-03-02 21:06:23.026	debug	(540) Redis Objects: Use Redis connection: 127.0.0.1:9001
host.iobroker	2021-03-02 21:06:21.974	info	"system.adapter.vis.0" enabled

Mehr steht dann nicht drin.

Merkwürdig ist auch, dass kein "Punkt" vor dem Eintrag ist. Also weder rot, gelb oder grün.

Div. Tipps zu "iobrocker load / iobrocker fix" habe ich schon probiert. Mehrere Reboots ebenfalls. Natürlich auch das deinstallieren und neu installieren der beiden Adapter (vis/web) mit Reboots etc. pp. Alles ohne Erfolg.

Meine Instanzen hänge ich mal als Screenshoot an.

Danke vorab!

@homoran said in Cloudless ioBroker:

natürlich kannst du ohne cloud mit der App im mobilen Internet ohne Cloud nicht auf diene Visualisierung zugreifen

Darüber bin ich gestolpert. Wenn die Visualisierung aber lokal auf dem Server (Raspi) liegt und keinen Einschränkungen unterliegt (einrichten, Design, Funktion), dann würde das für mich auf jeden Fall schon passen.

Ich hatte das wirklich so verstanden, dass es die Visualisierung nur mit Cloudanbindung / Abo gibt.

Ich werde mal Docker anwerfen und die Tage mal testen. Wenn mir jemand geschrieben hätte "Cloud ist musst have", dann würde ich mir das nicht geben.

Aber so wie ich Euch verstehe ist das nicht der Fall und dann ist ioBroker auf jeden Fall mehr als nur einen Blick wert, nachdem was ich bisher so gelesen habe.