Sommerpause beendet - und schon die erste Frage...

[vento66]

Das wäre dann der Punkt, wo EDOMI nativ MQTT unterstützen könnte

[gaert]

Nunja... WLAN mag ich im "Smarthome"-Kontext überhaupt nicht - unzuverlässig meiner Erfahrung nach. Und so ein Arduino-Nano hat nicht unendlich viel Speicher (und Pins)

Die serielle (via USB) Verbindung ist sehr stabil und zuverlässig. Da bei meinen Projekten 9600 Baud vollkommen ausreichend sind, kommt man auch mit einem USB-Hub mit zig Ports garantiert an keine Grenzen.

Also frage ich mal: Was spricht für WLAN/MQTT?!

[gaert]

MQTT ist m.E. für diesen Zweck "etwas" overkill... Der Arduino übergibt 26-Bits vom RFID-Leser (und ein paar Metadaten) an den LBS - das sollte der EDOMI-PC gerade noch so stemmen können

[saegefisch]

Was soll ich sagen... ...architektonisch wäre das mMn der "Schlusstein", um den technologischen Bogen von edomi zu finalisieren. MQTT ist in diesem Kontext die Universalsprache, der Babelfisch, der gemeinsame Nenner unzähliger Systeme, die 42 (okay für Trekkies: 47!), der elektronische Gral, das Manna, das Axiom des IoT,... Und ich bin jetzt noch gar nicht pathetisch geworden... war das schon zu dick aufgetragen?

Alles andere ist in LBS gut aufgehoben. Und auch wenn die MQTT-LBS geschmeidig funktionieren wäre nativ ein Fortschritt, weil es vielleicht sogar nahtlos integriert werden könnte wie eine GA oder ein KO.

Ein Argument gegen nativ und für LBS gibt es aber durchaus: MQTT ist noch etwas lebendiger in der Spezifikation als KNX, Änderungen in einem LBS wohl möglich leichter nachzuziehen als nativ in edomi. Andererseits von V3.1.1 auf V5 waren es auch ~5 Jahre...

[saegefisch]

Und zu Deinen Antworten: Ich kann Deinen Ansatz durchaus verstehen. Es geht auch nicht um die Leistung, die die Geräte ggf. kosten. Wenn es daran hakt hat man definitiv die falsche HW..

MQTT ist ein Broker und sollte gewisse Unzuverlässigkeiten des WLAN weg bügeln, nicht umsonst ist es Industriestandard. Siemens, Bosch, VW, Facebook, <you name it>,... würden es nicht nutzen, wenn es problematisch wäre

Und zum Overkill: Ich steuere auch eine Reihe Dinge damit, da sind's weniger als 26Bit Nutzlast. Aber MQTT ist extrem schlank by design. Es wäre sonst auch nicht zum Industriestandard für derlei geworden.

Aber hey: war ein Versuch wert... Ich sehe weiterhin MQTT als in jeder Hinsicht erheblich leichter an, als USB an edomi und würde es immer bevorzugen.

[gbglace]

Bosch, VW,

Die verbauen auch Funk basierte Autoschlüssel die sich noch leichter Knacken lassen als nen mechanischer... Ja die machen auch ne ganze Menge Blödsin und verkaufen da für teuer Geld.

[gaert]

Ich mag halt Funk generell nicht (wo es sich vermeiden lässt). MQTT ist nicht das Problem, sondern die Übertragung (WLAN)! Lass' mal einen Nano mit Wifi-Modul 1 Jahr lang durchlaufen - ich wette das wird nix

Und darum geht es mir, denn RFID & Co. sollten schon zuverlässig kommunizieren...

Nur ein Beispiel: Mein (nunmehr kaputtes) Android-Tablett war per WLAN angebunden (Visu) und hat sich so alle 2..3 Tage neu verbunden (warum auch immer). Per LAN (PC) kam das noch nie vor! Und ich denke mal, dass die WLAN-Implementierung bei Android durchaus ausgereifter ist, als ein China-Wifi-Modul für den Arduino...

[wintermute]

Was spricht für USB im Vergleich?

Der "Arduino an sich" kann nur seriell, bzw USB. WLAN ist eine Eigenschaft der ESP-Gemeinde, welche mit dem Arduino "an sich" wenig zu hat.
Beispiel: mein "Ambilight" wird von nem Arduino erzeugt, ist seriell am Kodi angeschlossen und weiss noch nicht mal, was WLAN ueberhaupt
sein koennte

[saegefisch]

Treffer, Michael! Danke für‘s erhellen, da war mein Denkfehler. ich gebe zu, ich bin ESP-„versaut“; für mich ist das arduino, aber natürlich ist das schlicht unreflektiert verkürzt. Aber leider sind die halt auch schön einfach, universell und gut...


Und ja, so gesehen, Christian, ist das durchaus logisch mit usb als eine Lösung. Ich bleibe wohl aber weiter den ESP treu und dem MQTT, HW am edomi ist für mich persönlich keine Lösung.

Und... MQTT geht auch per LAN (und mit Gewalt bestimmt auch über USB), es ist also noch nicht alles verloren..., es könnte doch noch integriert werden...

[hartwigm]

Ich habe schon mehrfach für die native Einbindung von mqtt hier pladiert.
M.E wäre das der richtige Schritt.
Ob ich damit aber nun einen Temperaturwert oder tausende von Werten einer Loxone zum Broker schicke und ob ich das per Kabel oder WLan mache bleibt jedem selbst überlassen.

Wichtig ist nur das der Industriestandard MQTT nativ unterstützt wird. Das würde sehr viele neue Dinge erschliessen.

Es ist zu kurz gedacht, wenn die Überlegung angestrengt wird, dass dies für 26 bytes ein overkill ist, den dann ist die für 26bytes gefundene Lösung für nur 2byte sicher auch ein overkill und müsste dafür wieder neu entwickelt werden.

Jeder Shelly hat heute mqtt und mir ist ein Standard einfach viel lieber als 20 Individuallösungen, bei denen du nach 3 Jahren eine Änderung willst und nicht mehr weisst was sich der Entwickler (meist ich selbst ) dabei gedacht hat.


Und schön wäre es wenn das abonnieren oder publishen auf Ko Ebene freigegeben werden könnte, bzw. auch das automatische Anlegen von abonnierten Werten als KOś

Das wäre für mich dann Edomi 3.x

[gaert]

Industriestandards gibt es viele - soll ich die auch gleich alle mit reinnehmen?

MQTT ist super toll und nur MQTT ist die Zukunft - keine Frage...! Aber: Ich habe mit MQTT nix am Hut - kein einziges Gerät kann MQTT bei mir. EDOMI ist gemacht für KNX, nicht vergessen!

Anders gesagt: MQTT interessiert mich absolut Null, daher wird das wohl nichts. Wenn es irgendwann einen Grund für mich geben sollte, kann sich das Blatt natürlich wenden - bis dahin ist es nicht notwendig alle paar Wochen auf die Vorteile von MQTT zu hinzuweisen

[willchr]

Ich verstehe die fehlende Einsicht, Energie in Entwicklungsarbeit für ein Feature zu stecken, was persönlich nicht gebraucht wird - insbesondere da damit auch keine finanziellen Vorteile einhergehen.

Aus Produktsicht stimme ich Saegefisch zu:

[...]architektonisch wäre das mMn der "Schlusstein", um den technologischen Bogen von edomi zu finalisieren

... und würde noch einen Schritt weitergehen. Meiner Meinung nach wird es ohne MQTT in Zukunft deutlich schwieriger werden, neue Nutzer von EDOMI überzeugen zu können - trotz der unbestreitbaren Vorteile. Was bringt mir jedoch eine mächtige Logic-Engine, wenn ich meine zu vernetzenden Geräte nicht direkt vernünftig anbinden kann.

Ich vermute sogar, dass es ohne Jonoves MQTT-Bausteinen schon heute sehr viel ruhiger wäre hier im Forum.

[mfd]

Mein (nunmehr kaputtes) Android-Tablett war per WLAN angebunden (Visu) und hat sich so alle 2..3 Tage neu verbunden (warum auch immer). Per LAN (PC) kam das noch nie vor!

Mein per LAN angebundenes Android Tablet hatte da bisher auch noch keine Probleme. Die Verbindung läuft über Monate und Jahre stabil, solange kein Stromausfall o.ä. diese "unterbricht". Wieso also wegen eines WLAN-Problems gleich das ganze Betriebssystem verteufeln?
IMHO gibt es sehr ordentliche Android-Geräte zur Auf- oder In-Wandmontage mit LAN-Anschluss. Stromverbrauch ist dabei auch noch ein Pluspunkt.

[derwombat]

Ein andere Möglihckeit wäre sshpass, welches man mit yum install sshpass auf dem EDOMI Server installiert.

Dann kann man mit

sshpass -p <PASSWORT> ssh <user>@<Ziel-IP> <CMD>

einen Befehl ausführen. Das <PASSWORT> kann auch aus einer Datei kommen, dann -f <PASSWORT-DATEI> statt -p <PASSWORT>.

Man könnte auch einmalig mit diesem Konstruct den Public-Key von root@edomi-server auf den Zielserver kopieren und könnte dann nativ ssh mit public-key-authentication verwenden.

Hiermit kopiert man den Public Key des aktuellen Users auf den Zielrechner.

sshpass -p <PASSWORT> ssh-copy-id <user>@<ZIEL-IP>

So habe dies bei mir auch gelöst, schalte den HDMI Ausgang

 sshpass -p <PASS> ssh <ZIEL-IP> -l <USERNAME> -t "vcgencmd display_power 0"

aus und mit

 sshpass -p <PASS> ssh <ZIEL-IP> -l <USERNAME> -t "vcgencmd display_power 1"

wieder ein.

Funktionierte bis jetzt sehr zuverlässig!

[Michael85]

Meiner Meinung nach wird es ohne MQTT in Zukunft deutlich schwieriger werden, neue Nutzer von EDOMI überzeugen zu können - trotz der unbestreitbaren Vorteile. Was bringt mir jedoch eine mächtige Logic-Engine, wenn ich meine zu vernetzenden Geräte nicht direkt vernünftig anbinden kann.

Also ich nutze selbst auch die MQTT Bausteine von jonofe. Die Anbindung ist doch denkbar einfach.
Aber gerade weil es diese Bausteine gibt, glaube ich nicht das es ein großer Nachteil ist.
Natürlich wäre es schön wenn es irgendwann implementiert wird, aber ich denke wir sollten gaert hier einfach wirken lassen.
Die "Liste" hat ja noch mehrere Wünsche druff.

Das System lebt doch davon dass viele User auch für Sonderfälle Bausteine ausarbeiten.
Man darf hier nicht vergessen dass Edomi kostenlos zur verfügung steht. Und hier durchaus flexibler ist als viele teure Kauflösungen.
Ich werde es so nicht mehr hergeben. Wüsste gar nicht was ich die Stunden auf der Couch machen soll wenn ich nicht an der Visu rumspielen kann