@maximal1981 grundsätzlich richtig. Ich würde aber nicht von "nur" sprechen, der Adapter ist eine riesen Erleichterung, die Inhalte darzustellen. Ich hatte vorher einen Node-Red Flow für die Awtrix Anbindung über die HTTP API und das war schon ziemlich fummelig. Die Zugänglichkeit zu dem Gerät ist durch den Adapter deutlich besser!
Zur Info für alle Betroffenen: Ich habe auf Github zwischenzeitlich ein entsprechendes Issue angelegt:
https://github.com/DrozmotiX/ioBroker.wled/issues/315
beim Testen mit einer geänderten IP habe ich den Fehler gefunden: mein Aufruf erfolgt stets über HTTPS - das liefert bei den neuen Containern keine Antwort. Ein kurzer Test mit HTTP in der URL führt zu einem Ergebnis in der Admin-Oberfläche. Durch die Verwendung der bisherigen IP-Adresse verwendet der Browser automatisch HTTPS, was aber in Chrome erst sichtbar wird, wenn man die URL manuell editiert.
Ich vermute, der HTTPS Zugang wird erst bei der Einrichtung durch diese Einstellung aktiviert:
Da ich bisher immer die Containerdaten mit migriert habe, ist mir das bisher nie aufgefallen. Bei einem frischen Container aber ein sehr wichtiger Unterschied.
Vielen Dank für eure schnelle Unterstützung - das hat mir sehr weitergeholfen!
@haus-automatisierung direkt mal 2 Stück über deinen Link bestellt, danke!
Hi Gerhard,
ESPHome habe ich mir bisher noch nicht näher angesehen, aber spricht aus deiner Sicht etwas dagegen, auf den ESP WLED zu flashen? Das ist ziemlich ausgereift und für adressierbare LED's hervorragend geeignet. Es gibt auch einen fertigen WLED Adapter für ioBroker, über den habe ich bereits erfolgreich ähnliche LED's (SK6812) eingebunden.
LG Percy
@grml ich habe seit knapp 4 Jahren eine Inotherm Tür mit elektrischem Motorschloss im Einsatz und bin zufrieden. Ich habe mir bei meiner Realisierung ein paar Gedanken um das Thema Sicherheit gemacht und deshalb folgende Realisierung gewählt:
Meine Haustür ist ein Inselsystem. Keine Anbindung an irgendein smartes-System. Selbst wenn ich meine Netzwerk-Konfiguration falsch konfiguriere und mein komplettes Netzwerk mal im Internet stehen sollte - die Haustür bekommst du nicht auf. Dafür muss man auf einen gewissen Komfort verzichten - die Haustür per Handy öffnen ist nicht. Aber da überwiegt für mich ganz klar das Thema Sicherheit. Öffnen kann ich sie trotzdem über 2 Taster im Haus. Diese sind aber nur an der Tür angeschlossen und nirgends sonst
Die Lösungen für Keypad oder Fingerprint, welche in der Tür integriert sind, sehen zwar gut aus. Hier hatte ich aber Angst, was die Ersatzteilversorgung in 10 Jahren angeht. Daher habe ich nur den Motor ohne in die Tür integriertes Keypad/Fingerprint-Reader genommen. Stattdessen habe ich neben der Tür eine Mediendose gesetzt und ein Gira-Keyless in System verbaut. Hier gibt es verschiedene Module wie z.B. Fingerprint oder Keypad, welche sich einfach aufstecken lassen. Selbst wenn es das in 10 Jahren nicht mehr geben sollte, baue ich einfach ein anderes System in die Dose außen ein.
Die Tür selbst bietet potentialfreie Kontakte zum Auslesen von Zuständen für
Diese habe ich auf einen Binäreingang meines KNX Bus gelegt. Weiterhin kann über das Anlegen von 24V auf den entsprechenden Eingangskontakten der Türmotor aufgefahren werden. Darüber öffnet dann das Gira Keyless-In auch die Tür.
Das auf deinem Bild gezeigte Inosmart System habe ich aus o.g. Gründen nicht genommen, an Komfort vermisse ich aber nichts. Der größte Vorteil liegt in meinen Augen darin, dass man das Abschließen nicht vergessen kann (Tür fällt ins Schloss -> Motor schließt automatisch ab) und man kann sich nicht ausschließen. Außerdem ein Schlüssel weniger, den man herumschleppen muss. Nachbarn und Eltern haben einen eigenen Zugangscode, der bei Bedarf geändert werden kann.
Um auf deine eigentliche Frage zurückzukommen: Ja, Inotherm Türen können in den ioBroker eingebunden werden. Es gibt zwar keinen inosmart Adapter, aber das Auslesen der Kontakte und Anfahren des Motors ist kein Problem. Machen würde ich letzteres aber nicht.
Gruß,
Percy
Hallo Biber,
für den sicheren Zugang von außen würde ich grundsätzlich einen VPN Zugang empfehlen, das bietet ein Höchstmaß an Sicherheit.
Zigbee ist so eine Sache, denn Zigbee ist nicht gleich Zigbee. Denn während der Funkstandard genormt ist (Stichwort OSI-Layer 1+2), sind es die darüberliegenden Kommunikationsschichten nicht. Nicht jedes Zigbee-Gateway kann also auch mit jedem Zigbee Endgerät kommunizieren. Ich habe mich deshalb bei meinen Funkanwendungen gegen Zigbee entschieden und nutze stattdessen Homematic Komponenten. Das 868MHz Frequenzband bietet eine große Reichweite, die CCU (das Homematic Gateway) lässt sich auf einem Raspberry installieren und die Homematic Geräte (Bewegungsmelder, Türkontakte, usw) lassen sich einfach und zuverlässig einbinden. Keines der Geräte "telefoniert nach Hause" und die Einrichtung geht schnell. Dafür zahlt man pro Gerät etwas mehr als bei günstigeren Zigbee-Lösungen.
Viele Tuya-Geräte können (je nach Anwendung: müssen) geflasht werden, damit sie sich so einbinden lassen, wie man es sich vorstellt (und nicht mehr nach Hause telefonieren). Als out-of-the box Lösungen sind diese Geräte meistens nur bedingt geeignet. Sicherheitstechnisch wären sie definitiv nicht meine erste Wahl (siehe Artikel von Heise: https://www.heise.de/select/ct/2019/4/1550226849835235)
Ein Zigbee-Gateway ersetzt sicherlich nicht den ioBroker, sondern stellt nur die Kommunikationsschnittstelle für die Zigbee-Endgeräte dar.
Gruß,
Percy
Backups sind so ein Thema - du wirst hier im Forum vermutlich verschiedene Ansätze finden, alle haben verschiedene Vor- und Nachteile, letztlich hängt es auch von deinem System ab.
Auf welchem System laufen deine Docker-Container? Bei mir laufen sie auf einer Synology. Das Betriebssystem DSM bietet einen Dienst namens Hyper-Backup, über den ich automatisiert die Volumes sichere. Zusätzlich erstelle ich manuell ein vollständiges Docker-Backup (Image + Konfiguration + Volume-Daten), bevor ich größere Änderungen an einem Container vornehme. Dafür bietet die Docker Verwaltung von Synology eine eigene Funktion zum Export von Containern. Falls du ein anderes System nutzt, müsste sich ähnliches aber auch z.B. über Portainer realisieren lassen. Über Portainer dupliziere ich manche Container z.B. vor größeren Updates. Sollte etwas schief gehen, fahre ich einfach den alten Container wieder hoch (hier muss man je nach Container ggf. auf Abhängigkeiten zu den Volumes aufpassen)
Für eine InfluxDB reicht es normalerweise, ein initiales Backup des Containers vorzuhalten und dann nur das Volume regelmäßig wegzuschreiben, welches die eigentlichen Serien und Messungen der Datenbank enthält.
Falls du dich nicht so intensiv mit den Docker Containern auseinander setzen möchtest, ist ein Backitup-Backup vermutlich die einfachste Variante. Ich habe den vollständigen Docker-Klon immer bevorzugt, falsch ist sicherlich beides nicht.
@dieter_p
Ich habe einen ähnlichen Anwendungsfall, bei mir sind Reolink Kameras in der Surveillance Station von Synology eingebunden und Aufnahmen werden durch einen Homematic Bewegungsmelder getriggert (deutlich weniger Fehldetektionen als mit Motion-In-Picture Erkennung). Die gleiche Logik verwende ich auch an anderen Stellen mit anderen Kameras und Auslösern, das Skript ist daher recht universell nutzbar:
//Kameraaufzeichnung starten, wenn eine Bewegung auf der Terrasse erkannt wird
on({id: 'hm-rpc.1.000XXX.1.MOTION'/*Motion*/, val: true}, function (obj)
{
try{
// Die URL triggered eine Aktionsregel der Surveillance Station an, welche die Kameraaufzeichnung der Terrassenkamera startet
const url='https://192.168.178.100:5001/webapi/entry.cgi?api=SYNO.SurveillanceStation.ExternalEvent&method="Trigger"&version=1&eventId=2&eventName="This is external event2"&account="ACCOUNTNAME"&password="ACCOUNTPASSWORD"';
var encodedAlarmmessage = encodeURI(url);
console.log("Bewegung an der Terrasse erkannt, Kameraaufzeichnung wird gestartet...");
//HTTP Request vorbereiten...
var options = {url: url, method: 'GET', rejectUnauthorized: false, headers: { 'User-Agent': 'request' }};
//...und abschicken
request(options);
}
catch{console.log("Es ist ein Fehler aufgetreten, es konnte keine Aufzeichnung gestartet werden...")};
});
Damit das Skript funktioniert, muss in der Surveillance Station eine Aktionsregel für die betroffene Kamera erstellt werden:
Über "Befehl Abrufen" findest du deine URL für das ioBroker Skript
Ich hoffe, das hilft dir weiter.
Gruß,
Percy
Ja, ein Full-Backup für den Docker ist - zumindest auf der Synology - grundsätzlich möglich.
Ich persönlich setze hier nicht auf ein einziges Pferd. Generell aktualisiere ich Adapter nur nach einem Backup, z.B. alle 1-2 Monate. So habe ich immer einen sauberen Stand und "zerschieße" mir nicht versehentlich im laufenden Betrieb etwas durch ein Update (kommt selten vor, ist aber schon passiert). Vom Vorgehen her mache ich es wie folgt:
1.) Sicherstellen, dass es ein Backitup Full Backup gibt. Dieses muss nicht zwangsläufig manuell gesichert werden, da es sich im ioBroker Ordner befindet und damit bei den nächsten Schritten mitgespeichert wird
2.) Über DSM den Container exportieren und dabei auswählen, dass die Containerdaten mitgespeichert werden sollen. Das ist wichtig, da so auch das opt/iobroker Verzeichnis mitgespeichert wird und damit die Nutzerdaten. Die Datenmenge steigt aber auch dementsprechend. Nicht wundern, kann gerne mal eine halbe Stunde dauern.
3.) Eine Kopie des Container-Volumes (opt/iobroker) erstellen. Sollte eigentlich nicht nötig sein, aber bei Problemen kann das genutzt werden, um Daten besonders einfach wiederherzustellen.
4.) im Portainer den Container stoppen und über "Duplicate/Edit" ein Duplikat mit aktuellem Image erzeugen. Das geschieht vollautomatisch unter Beibehaltung aller Container-Einstellungen, indem einfach die Image-Version angepasst wird und (ganz wichtig) der Name des Containers geändert wird (ansonsten ist es ein "edit" und kein "duplicate")
Sollte der neue Container nicht sauber hochfahren (hatte ich bisher noch nie) oder einzelne Adapter mit der Node.js/NPM/Linux Umstellung Probleme haben (kann schon eher mal passieren), kann man einfach den alten Stand wiederherstellen. Im ersten Schritt stoppe ich den Container und starte den alten (siehe Schritt 4). Im Idealfall läuft jetzt alles so wie vorher, außer es gab bereits gravierende Änderungen am opt/iobroker Verzeichnis. In diesem Fall kann man entweder das backitup backup (Schritt 1), das opt/iobroker Verzeichnis-Backup (Schritt 3) oder das DSM-Container Backup (Schritt 2) nutzen. Selbst wenn hier eine Backup-Methode mal versagt, spätestens die zweite regelt es.
Meine Methode mag vielleicht umständlich sein und ein paar Dinge doppelt speichern. Dafür habe ich im Fall von Problemen vielfältige Möglichkeiten, die Daten wiederherzustellen.
@simplyclever Das Müsli-Docker Backup kenne ich noch gar nicht, schau ich mir aber auch mal an, sieht interessant aus 
@mcm1957 said in Anbindung von Meshtastic LoRa Geräten:
a) wenn das LORAWAN Geräte sind sollte dochvder Adapter passen:
https://github.com/BenAhrdt/ioBroker.lorawan
Wenn mit dem Adapter was nicht geht ist ev ein Post im Testopic des Adapters sinnvoll.
b) Was meinst du mit mqtt Adapter besitzt keine vollständige Implementierung? Wenn ein Fehler vorliegt mach bitte ein Issue auf. Wenn was unklar ist ein Topic hier.
Wie Marc schon erwähnte, leider hat Meshtastic außer dem physical Layer (und ein paar Bestandteile von Layer 2) nicht viel mit LoRaWAN zu tun - das funktioniert also leider nicht
@marc-berg Den Thread kenne ich, der Ansatz mit Node Red würde mir aber besser gefallen. Dachte vielleicht hat da jemand schon Erfahrungen gesammelt
Hallo Zusammen,
ich überlege zurzeit, wie ich meine Meshtastic LoRa Geräte mit dem ioBroker verbinde. Einen Adapter gibt es ja nicht, meine erste Idee war es, die Geräte via MQTT mit dem MQTT Adapter zu verbinden. Da der ioBroker Adapter hier aber keine vollständige MQTT Implementierung besitzt, war das leider nicht sonderlich erfolgreich.
Meine zweite Idee war das Aufsetzen eines vollwertigen Mosquitto MQTT Brokers, der mit den Meshtastic Geräten kommuniziert und auf der anderen Seite die Daten an den ioBroker weitergibt. Die Ernüchterung hat sich allerdings auch hier recht schnell eingestellt - die von den Meshtastic Geräten via MQTT zur Verfügung gestellten Informationen sind maximal rudimentär, so erhält man bspw. keine Daten von den Geräten wie Batteriestand, Standort oder empfangene Nachrichten.
Ich habe dann entdeckt, dass es für Node Red ein Paket gibt, welches eine Verbindung zu den Geräten via http herstellt:
https://github.com/danpeig/node-red-meshtastic-msg
Das sieht recht vielversprechend aus. Leider ist die Node Red Implementierung im ioBroker etwas zickig bei der Installation des Pakets (wer sich für Details interessiert: https://github.com/danpeig/node-red-meshtastic-msg/issues/12#issuecomment-3025489674 )
Meine Frage an euch: Hat jemand bereits erfolgreich seine Meshtastic Geräte an den ioBroker angebunden? Für Ideen und Anregungen wäre ich dankbar.
Viele Grüße,
Percy
Ich grabe das Thema mal aus, da der Harmony Hub bis heute ziemlich alternativlos ist:
Der Nachteil der Erkennung als Mediengerät ist, dass man den ioBroker Fake Roku nicht den Medientasten auf der Fernbedienung zuordnen kann. Heißt ich muss die Smart Home Aktionen nicht nur irgendwo auf dem Rest der Fernbedienung unterbringen (Frau freut sich über diese Verkomplizierung), sondern muss die Verknüpfung auch für jede Activity einzeln anlegen (und bei Änderungen jeweils x-mal anpassen). Die Smart Home Tasten auf der Fernbedienung gelten hingegen global und müssen nur einmal gepflegt werden.
Ich habe bisher leider auch keine Möglichkeit gefunden, unter ioBroker die Smart Home Tasten auf der Fernbedienung zu nutzen. Bleibt wohl nur der Umweg über openHAB oder HomeAssistent 
@dragon said in VIS - light für SmartWatch es bis Wear OS:
Uiuiui, peinlich. Adapter installiert, aber leider keine laufende Instanz...
Nachdem ich eine laufende hatte funktionierte die App sofort. Allerdings lässt sich die Lampe nur ein Mal anschalten, nicht wieder aus...BT muss abgeschaltet werden, sonst funktioniert es nicht.
da lag er. Der Websocket Adapter läuft als eigene Instanz und nicht unter web.0 -> Ich hatte ebenfalls keine Websocket Instanz laufen, obwohl der Adapter grundsätzlich installiert war. Evtl. ist das die Standardeinstellung?
Vielleicht hilft das ja noch jemandem
Ich stehe irgendwie auf dem Schlauch, meine Uhr bekommt einfach keine Verbindung zum ioBroker (Meldung "iobroker not reachable). Vielleicht hat noch jemand eine Idee, hier die Eckdaten:
ioBroker websocket läuft auf port 8082. Kein https, keine Authentifizierung im web.0 Adapter eingestellt
Auf der Uhr die Adresse im Format "http://192.168.178.10:8082" eingegeben. Gleiche URL am PC führt zur Web Adapter Hauptseite
SocketIO ist deinstalliert
Wo liegt mein Denkfehler?
@dbweb wie ist die Performance dieser Lösung im Vergleich zu einem Android Tablet und zu einem iPad?
@kilasat Du kannst dir in denen Szenen ein smartes Objekt anlegen, welches du z.B. "Wohnzimmerreinigung" nennst. Das sieht dann auch Alexa. In dem Objekt musst du dann einfach dem Objekt "zoneClean" die passenden Daten übergeben (herauszufinden z.B. über die Flole App, welche dir die Koordination der Zonen anzeigt)
Aufrufen kannst du es dann über "Alexa, aktiviere Wohnzimmerreinigung" (Alexa kennt keine Staubsauger, daher ist die Benennung so noch am intuitievsten). Ich habe so mehrere Szenen für "Hochstuhlreinigung" (saugt rund um den Hochstuhl unseres kleinen Höhlentrolls) oder "Tannenbaumreinigung" (der steht jedes Jahr an der gleichen Stelle und fängt eben irgendwann an zu nadeln) - funktioniert einwandfrei, solange du die Karte nicht neu anlernst
@dbu828 Vielleicht bekommt man die Daten über einen anderen MQTT Broker sauber rein? Hat jemand mal versucht, das Nuki in Node Red anzubinden?
Gibt es neue Erkenntnisse bezüglich des lockactionstate Problems? Löst die beta Firmware des Nuki das Problem?
