Hi! Danke für den Hinweis! Ich habe es ausprobiert und es funktioniert tatsächlich. Man sollte nur auf allen iobroker Instanzen einen Admin Adapter installiert haben.
Meine Zusammenfassung: mit Redis und Redis Sentinel habe ich eine Sorge weniger bei ioBroker.
Danke für den Thread hier und die Hilfe!
@pedder007 Also gestartet habe ich, indem ich den Datenpunkt clean auf true gesetzt habe. Danach habe ich ihn zum Beenden wieder auf false gesetzt und den Datenpunkt charge auf true. Er ist dann sauber in die Station gefahren.
Einzig in der Ecovacs App blieb die Anzeige der aktuell laufenden Aufgabe auf fortsetzen/beenden stehen. Laut den Timestamps in den Datenpunkten muss man dazu stop auf true und pause auf false setzen. Werde ich noch testen.
@robschii
Ich steuere im Shuttercontrol niemals die Rolladenschalter direkt, sondern über einen Datenpunkt, den ich für jeden Rollläden unter Userdata definiert habe.
Hier legt Shuttercontrol die von ihm gewünschte Höhe an.
Auf jedem Daten Punkt existiert im JS ein on-change-any Watcher, der bei Änderungen den Wert ausliest und an den echten Rolladenschalter sendet.
Funktioniert gut und Shuttercontrol merkt nicht, wenn jemand manuell die Rollläden fährt.
Hallo Zusammen!
Ich musste eine Weile probieren, bis ich einen Slave ioBroker-Container unter Docker auf meinem MacStudio als Docker-Host in mein ioBroker Setup einbinden konnte. Daher habe ich hier ein paar Anmerkungen aufgeschrieben, falls das noch einmal jemand versucht.
Zunächst einmal ist wichtig, daß man den Slave im Container NICHT mittels "iobroker multihost connect" in den existierenden Master/Slave-Verbund einhängen kann, denn 'iobroker multihost connect' findet den Master nicht!
Die Konfiguration als Slave muss unbedingt über Environment-Variablen zum Startzeitpunkt des Containers erfolgen. Gleiches gilt, wenn der Container seine States und Objects aus einer bestehenden Redis-(Sentinel) DB oder über einen anderen der möglichen Datenbanktypen erhalten soll. Auch hier funktioniert "iobroker setup custom" zunächst nicht.
Ich habe mir eine Datei mit den Environment Settings auf meinem Mac in einem lokalen Verzeichnis angelegt. Meine Konfiguration ist für ein Redis Sentinel mit 3 Nodes ausgelegt. Wer nur Redis oder etwas anderes nutzt, muss das entsprechend auf (s)eine IP und den Port 6379 usw. anpassen.
ioBroker-env/vars.env:
IOB_MULTIHOST=slave
IOB_OBJECTSDB_TYPE=redis
IOB_OBJECTSDB_HOST=192.168.178.xx1,192.168.178.xx2,192.168.178.xx3
IOB_OBJECTSDB_PORT=26379
IOB_STATESDB_TYPE=redis
IOB_STATESDB_HOST=192.168.178.xx1,192.168.178.xx2,192.168.178.xx3
IOB_STATESDB_PORT=26379
Um besser an den ioBroker Log-Output des Containers zu kommen, habe ich das Verzeichnis /opt/iobroker mittels '-v' noch auf ein lokales Verzeichnis auf dem Mac-Host gemounted. Achtung: das Verzeichnis muss vor dem ersten Start des Containers unbedingt leer sein, sonst glaubt ioBroker, es handelt sich um eine bereits fertige Installation und kommt aus dem Tritt mit der initialen Installation!
Zusätzlich habe ich einige wichtige Ports expilzit aus dem Container nach aussen geführt. 'docker --net=host' ist unter MacOS nämlich mit Vorsicht zu genießen, denn es exponiert nur alle Ports auf der IP der Docker-Mac internen Virtualisierungsschicht.
Mein Docker-Aufruf lautet dann so (kann man natürlich auch noch in ein Dockerfile oder einen Compose-Aufruf packen), wobei ich halt den Container als Slave mit Hostnamen iobroker8 verwende. Der Hostname wird ja über den Parameter '-h' im Docker-Aufruf festgelegt, müsst ihr also nach Bedarf anpassen:
docker container create --restart always --name iobroker8 --env-file ioBroker-env/vars.env -v /PATH_TO_LOCAL_DIR/ioBroker:/opt/iobroker -p 1880:1880 -p 2001:2001 -p 8081:8081 -p 8082:8082 -p 8088:8088 -p 8284:8284 -p 9000:9000 -p 9001:9001 -h iobroker8 buanet/iobroker
So weit, so gut. Startet, updated sich, konfiguriert sich - Host wird im ioBroker-Verbund aber nicht als aktiv gezeigt. Und kommt dann in eine Restart-Loop wegen 'error: host.iobroker8 No connection to databases possible, restart'. 'iobroker status' meldet ebenfalls 'no connection to databases possible'.
Abhilfe ist hier dann doch der Aufruf von 'iobroker setup custom' in einer Shell des Containers. Anscheinend kennt ioBroker die IPs eines Redis oder eines Sentinels zwar aus der Environment-Konfiguration, muss aber trotzdem noch einmal auf dem neuen Slave 'iobroker setup custom' durchlaufen, ehe er den Sentinel Cluster findet und dann dem ioBroker-Verbund als neuer Slave beitritt. Vielleicht ein Bug?
Vielleicht hilft es ja dem ein oder anderen hier weiter!
Viele Grüße
Dirk
@pedder007 Ja, vor 4 Tagen nach Gartenumbau komplett neu installiert in der App.
@arteck
Das hatte ich natürlich auch getan - leider ohne Erfolg. Die Slaves waren vom Master aus nicht mehr zugreifbar, also man konnte keine Instanzen auf einen Slave verschieben usw.
@arteck
So, Ok, kleines Update. Die Zurück-Umstellung auf Redis/Sentinel war erfolgreich, alle States und Objects sind da und - alle ioBroker-Slaves sind wieder vom Master aus steuerbar und verbunden!
Die dump.rdb ist nur um ein paar MB gewachsen durch die Umstellung.
Insofern alles super, ich laufe wieder! Danke!
Ah, doch noch mein Fazit, falls hier jemand mitliest und eventuell muss das als Bug in den Entwicklungspfad von ioBroker: wenn man einmal eine ioBroker Multihost Umgebung auf Redis/Sentinel umgestellt hat, sind die ioBroker Slaves nach der Rück-Umstellung auf JSONL NICHT mehr im ioBroker Cluster verfügbar für den Master!
Das ist m.E. sehr unschön.
Und beobachtet das Verhalten eures Sentinel sorgfältig. Falls die Datenmengen plötzlich ansteigen, lauft ihr in echte Probleme mit Full-Replica Anfragen usw.
@arteck said in Fragen/Probleme Redis (Sentinel):
redis-cli info replication
Ok, danke.
Habe ich alles gecheckt, passt soweit. Das dump.rdb wird auch tatsächlich nicht größer, sondern bleibt bei 307MB.
Ich habe 17829 States und 17528 Objects.
Ich riskiere es und stelle mal auf Sentinel zurück. Dann werde ich mir einen Watchdog einrichten, der die Größe des dump.rdb im Auge behält.
Zunächst mal danke für Deine Antwort!
Ich weiß, daß Redis eine InMemory-DB ist. Wie oft das Dump-File gesichert wird, habe ich in der Config-Datei konfiguriert.
Mir ist auch klar, daß 15GB ein irrer Wert sind, deswegen ja meine Fragen und mein Post hier. Ich bin davon ausgegangen, daß Redis immer den aktuellen Stand aller States und Objects im Speicher hält und dann nach einer gewissen Zeit bzw. Anzahl Änderungen das dump.rdb erstellt.
Bei mir sind aber scheinbar irgendwelche Altdaten (?) im Memory hängen geblieben und das hat sich dann auf 15GB hochgeschaukelt.
Die aktuellen Größen meiner objects.jsonl: 16MB und meiner states.jsonl: 5,7MB. Ich denke mit diesen Werten sollte Redis vernünftig umgehen können.
EDIT: habe gerade nachgesehen. Das dump.rdb ist mittlerweile wieder auf 307MB (!!) angestiegen, obwohl redis/sentinel gar nichts macht, sondern nur so vor sich hin läuft. Das kann oder darf doch nicht sein?!?
Dazu kommt, daß mein Sentinel-Master regelmäßig alle paar Stunden in den Tilt-Mode fällt (Meldung: +tilt #tilt mode entered). Keine Ahnung, was das ist und warum das passiert. Kannst Du mir bitt erklären, was dieser Tilt-Modus bedeutet?
Und wie meinst Du das "mit einem eintrag im LOG ???? bestimmt" ? Meine Slaves werden im Master ausgegraut, also als nicht verbunden, dargestellt. Ein "iobroker multihost browse" auf den Slaves ergibt: "No Multihost server found. ..." Der ist alledings sehr wohl aktiv, siehe die iobroker.json meines Masters:
"multihostService": {
"enabled": true,
"secure": true,
"password": "$/aes-192-cbc:XXXXXX", (censored)
"persist": true
},
Die Slaves sind alle per setup custom auf JSONL mit der IP des Masters und den Default-Ports 9000 und 9001 umgestellt worden.
Hallo Zusammen!
Ich habe es jetzt hinbekommen. Falls jemand hier diesen Thread ausgräbt, ein paar Tips von mir.
A) ich hatte ursprünglich standardmäßig den Wemos mit dem Tasmota Image geflasht, weil ich das bisher bei dem anderen Arduinos auch so machen musste. Das ist natürlich völlig falsch. Es reicht, über die Arduino IDE den Sketch (also auf gut Deutsch das Programm) vom Github zu laden und auf den Wemos zu übertragen.
B) statt der Batterie-Version habe ich ein 5V Netzteil angeschlossen und die Geschichte mit dem Relais weggelassen. Mein Sketch macht in setup() nur initial das WLAN an und loggt sich ein. Dann läuft in der loop() eine Prüfung, ob WLAN verfügbar ist (sonst neu einschalten), die Abfrage und das Senden der Daten an mqtt, der Wemos wartet dann 60 Sekunden und die loop läuft neu los.
C) Mit DeepSleep hatte ich nur Probleme, da kommt mein Wemos nicht mehr richtig wieder raus. Lasse ich also weg.
D) der Wemos scheint nicht stabil zu laufen. Ich betreibe das Netzteil an einer HMIP Schaltsteckdose und schalte die per ioBroker regelmäßig alle 4 Stunden für 10 Sekunden aus. Dann wird der Wemos neu gestartet.
E) es gibt leider beim großen Fluss diverse Wemos Lieferanten und Versionen, die nicht alle gleich gut sind. Achtet auf die Versionen mit dem kleinen schwarzen WLAN Chip, der um 45 Grad gedreht verlötet ist. Nicht die mit der Metall-Abschirmung, die sind mehr als instabil im WLAN!
Viele Grüße
Guten Morgen Zusammen!
Ich hatte meine iobroker Installation (1 Master und 5 Slaves) vor rund 1,5 Jahren auf Redis Sentinel (mit 3 Nodes) umgestellt.
Bis letzte Woche Freitag lief die Geschichte stabil, schnell und unauffällig ohne Ausfälle.
Am Freitag fiel mir auf, dass mein iobroker mehrfach pro Stunde für ein paar Minuten "hängen" blieb. Eine Untersuchung ergab dann, dass der Redis Master regelmäßig kommentarlos abgestürzt ist. Einer der Slaves hat dann versucht zu übernehmen. Da der Master im Docker läuft, wurde er automatisch restartet. Dies hat dann aber aufgrund der riesigen dump.rdb (15GB!) 90 Sekunden gedauert und dabei "hing" ioBroker. Anschließend hat einer der Slaves eine komplette Neu-Übertragung der Redis Daten (15GB!) vom Master angefordert und ist dabei gescheitert.
Dann ging das Spiel wieder von vorne los...
Meine Lösung: ich habe jetzt erst einmal auf JSONL zurück umgestellt. Das war zwar auch nicht smooth und hat mich viel Schweiß und Zeit gekostet, in der ich mehrmals an dem Punkt war, dass ich beinahe meine komplette Installation verloren habe. Backups und viel Gefummel haben mich aber gerettet.
Jetzt meine Fragen...
a) warum wird die Redis DB so riesig? Wird da nicht regelmäßig geflusht und alte States Einträge und anderer Garbage gelöscht?
b) trotz Umstellung auf JSONL motzt der iobroker Master, dass er keine Sentinels finden konnte, wenn ich Sentinel auf allen 3 Nodes runterfahre.
Warum ist das so?
c) meine Slaves verbinden sich nicht mehr (bis auf einen komischerweise). Auf dem Master ist Multihost dauerhaft enabled, aber ein Multihost connect oder Scan sagt, dass kein Multihost Master im LAN gefunden werden kann.
Gestern habe ich festgestellt, dass sich ein weiterer Slave nach Reparatur (Löschen der dump.rdb!) des Sentinel mit dem Master verbunden hat. Interessanterweise ist das so ein Test-Slave in Docker, den ich bisher gar nicht auf JSONL umgestellt habe. Er läuft also über Redis und kann sich plötzlich zum Master verbinden! Der auf JSONL läuft...
Ich habe schwer den Eindruck, dass man die Redis-Geister, die man rief, so ohne Weiteres nicht mehr los wird.
Ob ich wieder auf Redis Sentinel zurück umstelle weiß ich nicht. Die Geschichte mit der ständig wachsenden Datenbank unter Redis stört mich immens. Da ist die nächste Katastrophe in ein paar Monaten vorprogrammiert.
Wer hat Langfristerfahrungen mit redis und kann mir u.U. helfen?
Viele Grüße
Dirk
P.S.: Lesson learned - mein 0_userdata.0 Bereich war komplett weg, also alle selbstangelegten Objects. Das wird auch nirgendwo mitgesichert. Ich konnte ihn aus den JSON-Scripten rekonstruieren und habe jetzt ein Script, welches den Bereich komplett neu anlegt. Für den Fall der Fälle. Sollte man so machen. Oder die Userdata Objekte im JS, welches sie benutzt, einmal initial anlegen.
@saeft_2003 said in ioBroker mit Feuchtesensor zur Rasenbewässerung:
https://forum.iobroker.net/topic/33078/feuchtigkeitssensor-trübner-smt50-und-iobroker/11
Ich muss mich korrigieren: das Projekt an sich ist super, aber das Compilieren und Flashen ist ein totaler Krampf. Ohne intensive ESP/Arduino Kenntnisse nicht zu bewältigen. Und leider ginbt es auch keine Straight-Forward-Anleitung, wie man sowas macht.
Schade, viel Geld in den Sand gesetzt.
@pedder007 Ja, vor 4 Tagen nach Gartenumbau komplett neu installiert in der App.
@pedder007 Also gestartet habe ich, indem ich den Datenpunkt clean auf true gesetzt habe. Danach habe ich ihn zum Beenden wieder auf false gesetzt und den Datenpunkt charge auf true. Er ist dann sauber in die Station gefahren.
Einzig in der Ecovacs App blieb die Anzeige der aktuell laufenden Aufgabe auf fortsetzen/beenden stehen. Laut den Timestamps in den Datenpunkten muss man dazu stop auf true und pause auf false setzen. Werde ich noch testen.
@ofbeqnpolkkl6mby5e13 Danke, guter Tip! Jetzt funktioniert es. Da muss man aber auch erst einmal drauf kommen...
