Fragen eines absoluten Newbees
-
@fnbalu
Die Frage ist, was versteht Du mit mischen?
Tasmota geht zwar mit MQTT, aber mit dem Sonoff Adapter ist es waentlich einfacher. Ebenfalls die Shellys, für die es auch einen einengen Adapter gib (glaub ich, da die bei mir ebenfalls mit Tasmota laufen). -
@fnbalu sagte in Fragen eines absoluten Newbees:
Die Frage ist jetzt ob man das mischen kann oder ob man sich auf eins fixieren sollte?
Meine ersten Erfolge hatte ich schon, auch wenn die Logik hinter Blockly noch nicht ganz da ist.
Man liest vieles, aber vieles verwirrt einen Anfänger ;-(Hallo und Willkommen,
erst einmal vorweg: Du kannst so viel mischen wie du magst. Auf die Leistungsfähigkeit Deines Systems wirkt sich das nur in Sonderfällen negativ aus. Das ist genau eine der Stärken des ioBroker.
Nun Insbesondere zu JS, Typescript, NodeRed, Blockly und den neuen "Rules" im JS Adapter:
Auf der einen Seite ist es ideal das Werkzeug zu nehmen mit dem Du die gestellte Aufgabe am besten umsetzen kannst. Das bedeutet das für je nach Aufgabenstellung ein anderes Werkzeug das beste sein kann.
Generell kann man sagen:- "Rules" ist am einfachsten Umzusetzen, hat aber die härtesten Randbedingungen an die umsetzbaren Funktionalitäten
- "Blockly" ist etwas mächtiger, dafür aber auch komplexer beim Einsatz und erfordert mehr Einarbeitung
- "JS" und "Typescript" sind noch eine Ebene komplexer, aber auch eine Ebene mächtiger. Alles was in Blockly und per Rules umsetzbar ist lässt sich in JS/TS auch umsetzen. Teilweise auch mit weniger Aufwand.
NodeRed hat da eine gewisse Sonderstellung. Letztendlich kann mit NodeRed alles umgesetzt werden was auch mit JS und TS Umgesetzt werden kann. Bis man so weit ist ist aber die Lernkurve auch relativ steil und man kommt nicht umhin auch selber JS code zu schreiben. Wenn man das nicht tut liegt man irgendwo zwischen Rules und Blockly mit der Leistungsfähigkeit.
Ich Persönlich rate zu einer Entscheidung zwischen NodeRed und JS Adapter und würde die beiden nur in Sonderfällen gemischt einsetzen. Das ist aber rein subjektiv und nicht sauber zu begründen.
A.
-
Tasmota habe ich auf Steckdosen, welche sonst über Tuya laufen würden.
Das möcht ich zum einen absolut nicht und zum anderen für eine autark funktionierende Zeitschaltuhr perfekt.Bei den Shellys habe ich auch schon oft davon gelesen, dass die originale Firmware besser ist.
Autark bekomme ich da einen Graus, aber wenn's im ioBroker besser ist, soll es mit recht sein.Aktuell halt ein paar Zwischensteckdosen und Shellys zum Test, die dann erweitert werden.
Tuya oder solch China Cloud möchte ich nicht.Blockly muss man auch erstmal verstehen. Bisher viele Fragezeichen.
Aber es ging.
Ich habe sogar im ersten Gehversuch die Tasmota Steckdose an und ausschalten können über alexa und das so begrenzt, dass es nur ein bestimmter Echo darf.
Aber wie gesagt die Logik habe ich noch nicht inne.Da muss für jeden Befehl extra erstellt werden, ja?
Bisher sind die ja noch als Wemo eingebunden.
Wie ist das dann mit den Geräten? Wenn ich Badlicht nicht in Alexa integriert habe, wird es immer heißen, kenne ich nicht, obwohl die Szene ausgeführt wird -
@fnbalu
installiere doch mal die passenden Adapter, dann wird einiges klar, da ich immer noch nicht weiß wo Du gerade stocherst.
Alles was mit Alexa zu schalten geht, ist die Sprachsteuerung und hat erst mal nicht direkt was mit dem IOBroker zu tun. Man kann das in den IOBroker auch noch mit rein nehmen, spielt aber für das was Du willst, was ich immer noch nicht verstanden habe aber wohl keine Rolle.Alles was Du im IOBroker machts ist erst mal lokal und ohne Cloud. Blockly ist wenn man mal den Einstieg verstanden hat für das meiste selbsterklärend und um die Steckdosen über den IOBroker zu schalten, müssen die Geräte erst mal mit nem Adapter passend zu den Geräten in den IOBroker eingebunden werden und das ist bei Tasmota nun mal der Sonoff Adapter.
-
@jan1 das werde ich nachher mal machen.
Ich habe davon keine Ahnung gehabt und habe einer Steckdose mal MQTT Daten eingetragen.
Da konnte ich dann true und false ersehen als Schalter und auch das gesprochene von Alexa sehen und mir Blockly verknüpfen.Da ich absolut keine Ahnung hatte wusste ich es nicht besser.
Newbee halt.
Ich wusste nicht wie ich sonst Routinen erstellen sollte.Vielleicht denke ich einfach nur zu kompliziert.
-
@fnbalu Wie die Vorposter bereits gesagt haben, ist es wirklich die große Stärke von iobroker eine Datenbank anzubieten, die einige Funktionalität anbietet und auch zum Beispiel mit den History-Adapter einzigartige Funktionen besitzt, Daten auch über einen gewissen Zeitpnkt in einer Datenbank zu verwalten.
Was Du wiederum unter iobroker einsetzt - egal welche Logikmaschine Du einsetzt - bleibt Dir überlassen und wenn Du die Grundzüge verstehst, wirst Du aber das eine oder andere nicht brauchen. Ich komme bislang mit NodeRed alleine aus und bin im Gegensatz zu den Vorpostern nicht der Meinung, dass Du hier JS unbedingt brauchst und auch ohne JS die Leistungsfähigkeit höher als mit Blockly ist - aber das soll Dich nicht beeinflussen - der eine denkt das der andere jenes und jeder hat eben seine Vorlieben. Node Red hat ausserdem den Vorteil, dass es halt auch manche Schnittstellen gibt für die es im iobroker noch keinen Adapter gibt. Ich versuche mich gerade an SNMP und der Adapter in iobroker wrid seit 2 Jahren nicht mehr gepflegt und da gabs zum Beispiel in NodeRed eigene Lösungen. Wie gesagt Du kommst in meinen Augen auch ohne Programmierkenntnisse mit NodeRed aus meiner Sicht am Weitesten.
Auch bei der Wahl Deiner Adapter solltest Du Dir im Grundsatz einige Gedanken machen. Es werden hier oft Adapter im ioBroker angeboten, die ich persönlich für sagen wir mal "nicht unbedingt erforderlich sehe". Ich habe noch keinen Adapter geschrieben und weiß auch nicht wie kompliziert das ist, vielleicht mache ich das ja mal. Ich bevorzuge wenn Geräte über MQTT reden, mosquitto als Broker und den MQTT als Client Adapter. Damit habe ich alle Geräte unter einem Adapter im Blick und bin nicht darauf angewiesen, dass ein Adapter ein bestimmtes Gerät unterstützt etc. Neue Adapter sind in meinen Augen nur sinnvoll, wenn sie eine Kommunikationsschnittstelle bieten, die keinen Standard unterstützt.
So nun kannst Du Dir eine Meinung bilden und ich kann Dir auch mit NodeRed und MQTT Deiner Shellies helfen - nur bei Alexa muss ich passen. Das kann @Jan1 besser.
-
@fnbalu
Du machst ein Fehler und das ist gleich alles verstehen zu wollen.
Welche Adapter zum einbinden nötig sind habe schon geschrieben. Bei Tasmota ist das etwas blöd, weil das der Sonoff Adapter ist, was daran liegt, dass Sonoff Geräte zu Beginn mit Tasmota eben so eingebunden wurden und der Name somit sich auch die Geräte bezieht und nicht auf die FW, was treffender wäre.
Mit MQTT geht das zwar auch, ist aber nicht so einfach. Der Sonnoff Adapter ist ein auf Tasmota angepasster MQTT Adapter. Für Shellys gilt das Gleiche, nur dass es da ein Shelly Adapter gibt.Am besten stellst konkrete Fragen zu dem was Du gerade vorhast und nicht so allgemein, wie oben.
Es gibt viele Wege die funktinieten, welchen Du wählst ist Dir überlassen. Es gibt einfachere und etwas komplexere. -
@mickym sagte in Fragen eines absoluten Newbees:
Ich komme bislang mit NodeRed alleine aus und bin im Gegensatz zu den Vorpostern nicht der Meinung, dass Du hier JS unbedingt brauchst und auch ohne JS die Leistungsfähigkeit höher als mit Blockly ist - aber das soll Dich nicht beeinflussen - der eine denkt das der andere jenes und jeder hat eben seine Vorlieben.
Nur um das richtig zu stellen. Soweit ich das verstanden habe ist es durchaus üblich in komplexeren NodeRed flows innerhalb einzelner Bausteine mit javascript Code-Schnipseln zu arbeiten. Nur das war gemeint als ich geschrieben habe das auch bei NodeRed am Ende ggf. JavaScript Code geschrieben werden muss. Wenn ich da auf dem Holzweg bin dann ist das gut und ich nehme das in meine Liste von Vergleichen entsprechend auf. Es war nicht gemeint das neben NodeRed auch der JavaScript Adapter mit eigenen Skripten zum Einsatz kommen muss.
@jan1 sagte in Fragen eines absoluten Newbees:
das ist bei Tasmota nun mal der Sonoff Adapter.
@mickym sagte in Fragen eines absoluten Newbees:
Ich bevorzuge wenn Geräte über MQTT reden, mosquitto als Broker und den MQTT als Client Adapter.
Diese beiden Aussagen deuten auf eine weitere Stärke des ioBroker hin. @Jan1 setzt auf die direkte und automatisierte Integration Geräten die über MQTT kommunizieren mittels des Sonoff Adapters, der automatisch für die Geräte einen Stamm an Datenpunkten anlegt, während @mickym den Weg über einen externen MQTT Broker mit dem ioBroker als Client geht, und, wenn ich das korrekt erinnere genau die Datenpunkte bekommt die er explizit auch abonniert.
Beide Wege haben ihre Vor- und Nachteile. Was für Dich am besten ist musst du letztendlich probieren. In beiden Fällen wirst Du im Forum sicherlich viel Hilfe erfahren.
A.
-
@asgothian sagte in Fragen eines absoluten Newbees:
@mickym sagte in Fragen eines absoluten Newbees:
Ich komme bislang mit NodeRed alleine aus und bin im Gegensatz zu den Vorpostern nicht der Meinung, dass Du hier JS unbedingt brauchst und auch ohne JS die Leistungsfähigkeit höher als mit Blockly ist - aber das soll Dich nicht beeinflussen - der eine denkt das der andere jenes und jeder hat eben seine Vorlieben.
Nur um das richtig zu stellen. Soweit ich das verstanden habe ist es durchaus üblich in komplexeren NodeRed flows innerhalb einzelner Bausteine mit javascript Code-Schnipseln zu arbeiten. Nur das war gemeint als ich geschrieben habe das auch bei NodeRed am Ende ggf. JavaScript Code geschrieben werden muss. Wenn ich da auf dem Holzweg bin dann ist das gut und ich nehme das in meine Liste von Vergleichen entsprechend auf. Es war nicht gemeint das neben NodeRed auch der JavaScript Adapter mit eigenen Skripten zum Einsatz kommen muss.
Ich hoffe - dass ist eine fruchtbare Diskussion - in der auch Gegenmeinungen ausgetauscht werden können.
Ich hatte das schon richtig verstanden - würde Dir hier aber inzwischen widersprechen. Ich habe nun wirklich eine Menge komplexer Flows und der Anteil der "function"-Nodes in den ich JS schreiben muss, liegt bei unter 5% und auch nur deshalb, weil es dann ggf. zu unübersichtlich wird. Die meisten Dinge kann man über Change Nodes und JSONATA abdecken.@mickym sagte in Fragen eines absoluten Newbees:
Ich bevorzuge wenn Geräte über MQTT reden, mosquitto als Broker und den MQTT als Client Adapter.
Diese beiden Aussagen deuten auf eine weitere Stärke des ioBroker hin. @Jan1 setzt auf die direkte und automatisierte Integration Geräten die über MQTT kommunizieren mittels des Sonoff Adapters, der automatisch für die Geräte einen Stamm an Datenpunkten anlegt, während @mickym den Weg über einen externen MQTT Broker mit dem ioBroker als Client geht, und, wenn ich das korrekt erinnere genau die Datenpunkte bekommt die er explizit auch abonniert.
Beide Wege haben ihre Vor- und Nachteile. Was für Dich am besten ist musst du letztendlich probieren. In beiden Fällen wirst Du im Forum sicherlich viel Hilfe erfahren.
A.
Ich habe den MQTT-Adapter alles aus mosquitto abonniert - der Adapter ist quasi meine GUI für mosquitto. Ich setze deshalb mosquitto als Broker ein, da der MQTT Adapter in meinen Augen oft Problem mit der Verarbeitung des ACK Flags hat - aber egal.
Der eigentliche Grund warum ich auf MQTT direkt anstelle von Adaptern, die auf mqtt basieren einsetzen ist:- Oft muss man warten bis entsprechende Geräte von dem Adapter unterstützt werden, muss man bei reiner mqtt Kommunikation nicht. - Ich auch keine Funktion gefunden eines Adapters gefunden habe, die man nicht auch über die Logikmaschine abdecken kann (wie beispielsweise Firmwareupdate).
- Der größte Nachteil ist aber, wenn ich mehrere Gerätetypen haben die mqtt sprechen. Ich nutze Tasmota, Shellies und owntracks - für alles gibts Adapter die einen mqtt Broker implementieren. Nun muss ich aber für jeden Adapter einen eigenen Port vergeben- Das finde ich halt auch vom Systemaufbau unschön.
Aber nochmal das WICHTIGST für den TE:
Er kann alles mischen auch bei den Logikmaschinen und muss sich nicht festlegen!
Er kann eine Datenpunkt mit Blockly bearbeiten, der einen Datenpunkt in beschreibt, der einen NodeRed Flow antriggert oder umgekehrt er kann in NodeRed einen Flow erstellen, der einen Datenpunkt beschreibt der ein Blockly oder JS antriggert. Der letzte Fall tritt häufig dann ein, wenn es zwar eine NodeRed Node gibt, aber vielleicht keinen entsprechenden Adapter im iobroker. Ich glaube gerade bei Alexa nehmen deshalb viele NodeRed.
Theoretisch wer sich nicht mit NodeRed beschäftigen will, schreibt einfach alles was aus den (z.Bsp. Alexa Nodes) raus kommt, in einen eigenen Datenpunkt und verarbeitet es dann mit Blockly. So muss man sich quasi mit NodeRed nicht befassen. -
@mickym sagte in Fragen eines absoluten Newbees:
Ich hoffe - dass ist eine fruchtbare Diskussion - in der auch Gegenmeinungen ausgetauscht werden können.
Ich hatte das schon richtig verstanden - würde Dir hier aber inzwischen widersprechen. Ich habe nun wirklich eine Menge komplexer Flows und der Anteil der "function"-Nodes in den ich JS schreiben muss, liegt bei unter 5% und auch nur deshalb, weil es dann ggf. zu unübersichtlich wird. Die meisten Dinge kann man über Change Nodes und JSONATA abdecken.Auf jeden Fall. Ich hatte das von meinen Versuchen anders in Erinnerung und werde genau Deine Einschätzung mit in meine Liste aufnehmen. Damit wird NodeRed als Werkzeug wieder interessanter. Wieder etwas dazu gelernt.
Auch die Erklärung zum Hintergrund warum Du einen externen MQTT Broker nutzt ist meiner Meinung nach sehr hilfreich. Das Problem mit mehreren Adaptern die die gleichen Ressourcen nutzen haben sicherlich viele.
A.
-
Danke erstmal für Eure Unterstützung.
Asche auf mein Haupt, ich hatte den Sonoff Adapter bereits.Da habe ich dann auch gesehen wie der Status ist und konnte mit true und false schalten.
Zu der Frage was ich vor habe.
Ich habe meine Alexa bzw den Echo lieb gewonnen.Ich war nie ein Freund von ChinaCloud usw, da solch Systeme irgendwann abgeschaltet werden und dann ist essig, vom Datenschutz fange ich gar nicht erst an.
So habe ich mir letztes Jahr Tuya Steckdosen gekauft und diese mit Tasmota beglückt.
Dank der Wemo Emulation geht das auch mit Alexa.Nun sollen Rolladenmotoren mittels Shelly erweitert werden und den ein oder anderen Shelly soll es dazu geben für Licht, Dimmer, RGBW.
Da die Shellys auch ohne Cloud auskommen sollen, wollte ich das in ioBroker zusammenfassen. Solch eine Basis braucht es dann ja.
Ich finde es auch wahnsinn was manche mit Vis gemacht haben aber das ist faust zweiter Teil.
Zuerst einmal würde ich schauen, dass ich alle Aktoren mit Alexa steuern kann und würde Räume definieren.És soll alles aus einer Hand sein.
Alle Rolladen 80% und es soll geschehen.
Haus verlassen = überall Licht aus usw.Die Möglichkeiten ergeben sich dann mit der Zeit nehme ich an.
-
@fnbalu Auch bei der Visualisierung bist Du nicht komplett festgelegt. Ich rufe beispielsweise aus dem Node-Red Dashboard eine VIS Seite auf.
VIS ist eine sehr mächtige Visualisierung in dem vor allem das Erscheinungsbild im Vordergrund steht - dafür musst Du aber auch für die Endgeräte Deine Visualisierungen auf anpassen.
Das Node-Red Dashboard - hat ein responsive Design und basiert auf Googles Material Design und schaut deshalb den Android-Apps sehr ähnlich. Hier kannst Du dann halt schnell steuern und die Funktionalität steht im Vordergrund, wenn gleich ich auch mit ein paar HTML Kenntnissen gelernt hat, wie man hier auch eigenes Design verwirklichen kann.
Etwas ähnliches was sicher auch zur schnellen Steuerung dient findest Du in anderen Visualisierungs Adaptern unter iobroker.Das Hab-Panel schaut ähnlich wie das NodeRed Dashboard aus, aber auch den iQontrol Adapter finde ich interessant (auch wenn selbst nicht ausprobiert) damit bekommt man dann schnell so ein Kacheldesign wie unter Apples Homekit hin. Aber auch hier steht hauptächlich die Funktion im Vordergrund und das Design ist in einer gewissen Variationsbreite vorgegeben.
-
Hallo, ich mal wieder.
Ich habe noch etwas herumprobiert.
Auch mit den Shellys, welche ich mal etwas mit der Originalfirmware getestet habe.Wie habt Ihr das mit den IOT Geräten? Laufen die Geräte und dr ioBroker im selben Subnet zwecks Multicast?
Ich habe eine pfSense laufen. IOT hat auch im W-Lan ein eigenes Subnet.
Bisher habe ich es noch nicht hinbekommen, den Multicast Traffic durchzurouten.
MQTT ist da weniger das Problem.Nur was ist da nun besser?
Bei MQTT müsste man ja auf einen Standard MQTT Adapter setzen, oder aber verschiedene Ports für beispielsweise Sonoff und Shelly, wenn beides im MQTT läuft.
Was ist da zu empfehlen???
-
@fnbalu Nutze mosquitto als mqtt Broker und mqtt Adapter als Broker.
Alles was über mqtt geht mach ich über mqtt den Rest über HTTP.
-
Noch ein System mehr??
-
@fnbalu ein Adapter stellt auch ein zusätzliches System dar. Gut dann nimm halt den mqtt-Adapter als Broker. Ich hatte eben mit dem Ack=false Probleme, auch in Zusammenarbeit mit Node-Red. Mich hat das halt Monate gekostet, da ich den Fehler immer bei mir gesucht habe. Insofern liegt es an Dir ob Dir meine Erfahrungen was bedeuten. Letztlich ist es ja Dein System, das Du betreibst..
-
@mickym ich meine doch da nichts negativ und möcht Dich nicht angreifen. Sorry, wenn es so rüber kam.
Für mich klingt das nicht wie ein ioBroker Adapter sondern wie ein autarkes Zusatzsystem was eine extra VM e.t.c. bedeutet.Ich verstehe da noch nicht wie das dann verknüpft
-
@asgothian sagte in Fragen eines absoluten Newbees:
ch hatte das von meinen Versuchen anders in Erinnerung
ich allerdings auch!
habe aber in letzten Tagen einige Flows von @mickym gesehen, in denen nodes vorkamen, von denen ich damals nur hätte träumen können.Ich denke einfach, dass sich auch node-red (oder zumindest die Vielfalt dessen nodes) in der Zwischenzeit ebenfalls weiterentwickelt hat, wie die Blöcke bei Blockly.
Als mir als absolutem js-Legastheniker Bluefox damals node-red ans Herz legte, habe ich damit meine ersten "Programmier"schritte gemacht. Blockly kam erst ganz viel später.
Wie beschrieben war die Lernkurve ziemlich steil, aber es kam sehr schnell, dass man js-Schnipsel in fucnction nodes anwenden musste.@asgothian sagte in Fragen eines absoluten Newbees:
Das Problem mit mehreren Adaptern die die gleichen Ressourcen nutzen haben sicherlich viele.
Das hatte ich zu Beginn von Blockly auch.
Da gab es noch eine sehr überschaubare Anzahl von Blöcken und einige Funktionen, die mit node-red ganz einfach zu lösen waren, waren mit Blockly damals nicht lösbar.
Damals hatte ich auf allen Hosts beide Systeme laufen, u.a. um Systemdaten auszulesen. -
Ich versuche das gerade wirken zu lassen.
Also grundsätzlich würde ich gerne meine IoT Devices wie Shelly e.t.c. in ein anderes Subnet packen.
Wenn der ioBroker dort nicht ist, dann bleibt nur MQTT, da Multicast nicht rüber kommt.Nun kann ich in das andere Netz, das andere Netz aber nicht zu mir per se
Ich kann natürlich eine Gruppe mit MQTT Ports erstellen, die dann explizit zum ioBroker geroutet werden.Da könnte man zig Adapter installieren und hätte dann halt die verschiedenen Ports je Instanz.
Oder aber ein MQTT der ehrlich alles sammelt.
In dem Beispiel Mosquitto auf einem anderen System.Ich weiß nicht was da einfacher ist.
Für mich ist alles Neuland.Übersichtlicher ist da wohl alles aus einer Hand für mich auf dem ersten Blick.
-
@fnbalu Bei mir läuft mosquitto auf dem gleichen System wie der iobroker - ohne irgendwelche Probleme. Ich nutze die mqtt Adapter als client und damit alle Datenpunkte im iobroker. Man kann somit sowohl mit mqtt Methoden, als auch mit iobroker Methoden auf die Datenpunkte zugreifen. Es gibt keine Notwendigkeit das zu trennen.
