Sommerpause beendet - und schon die erste Frage...

[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

[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...

[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.

[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.

[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...

[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

[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?!

[vento66]

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

[saegefisch]

RFID und GSM werden übrigens per USB (Arduino) mit dem EDOMI-Server verbunden - der LBS kommuniziert dann per ttyUSB (Seriell) mit dem Arduino. Das klappt sehr zuverlässig und ordentlich,

Wäre für jedwede Kommunikation zwischen einem Arduino und edomi nicht MQTT die flexiblere/universelle und vor allem einfacherer Lösung? Eine Lösung über USB schient mir unnötig kompliziert und ortsgebunden. Ich bin ja durchaus ein Fan von Kabellösungen und vermeide RF bei relevanten Geräten im Haus, weil sie ein paar weniger Optionen kennen, nicht zu funktionieren. Aber bei einem Arduino ist für mich eine WLAN/MQTT-Lösung mMn die Präferenz. Und es ist beliebig und ohne relevanten Aufwand skalierbar; USB-Anschlüsse sind irgendwie endlicher...

Um es besser zu verstehen: Was spricht für USB im Vergleich?

Okay, ich ahne, dass Du noch keinen MQTT sowieso laufen hast - macht ja irgendwie auch Aufwand...

[Peterich]

Geht das auch dann mit einer virtuellen Umgebung wie proxmox?

Kannst du durchreichen ja

[uzi10]

Geht das auch dann mit einer virtuellen Umgebung wie proxmox?

[gaert]

BTW: Ich arbeite an einem LBS, der das alles vereint - also Bildschirm steuern, Standby/Wakeup usw. (einschließlich Überwachung der Zustände). Damit könnte man z.B. einen Visu-PC vernünftig und strukturiert steuern bzw. dessen Status erfassen.

Zudem bastle ich noch an diversen Arduino-Projekten - einschließlich zugehörigen LBS:
- 3-facher Wiegand-Leser (26 bit), z.B. für RFID (so gut wie fertig)
- GSM-Modul zum senden/empfangen von SMS (warte noch auf das OK aus China...)
- und diverse LoRa-Spielerreien (433 Mhz), allerdings mehr für den Eigenbedarf (lüppt schon)

RFID und GSM werden übrigens per USB (Arduino) mit dem EDOMI-Server verbunden - der LBS kommuniziert dann per ttyUSB (Seriell) mit dem Arduino. Das klappt sehr zuverlässig und ordentlich, insbesondere wenn man die entsprechenden USB-Ports per Symlink "fest verdrahtet" (meine China-Nanos haben alle die gleiche Seriennummer etc., so dass nur die feste Zuweisung zu einem physischen Port zuverlässig funktioniert).

[gaert]

Auf "sshpass" bin ich auch gestoßen, aber ich wollte so wenig wie möglich nachinstallieren ("expect" schien mir irgendwie schlanker bzw. systemnäher zu sein). Aber ich schaue mir das noch mal an. Im Prinzip ist es ja auch egal, wie man letztlich den Befehl absetzt - interessant finde ich nur die Möglichkeit, den Kram über SSH zu machen (statt HTTP).

[jonofe]

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>

[gaert]

Das Thema mit den Shell Befehl zum Bildschirm Ein-/Ausschalten würde mich auch brennend interessieren. Habe mir auch neu ein TouchPanel mit MiniPc anbrietst Wand gehängt und finde das eine super Lösung. Von Tablets bzw. einer App bin ich auch kein Fan davon - pflegeaufwand bei Updates usw... Browser läuft immer.

Ich bin da noch in der Experimentierphase, aber in einer CentOS7-VM funktioniert's zuverlässig:

Das Grundprinzip bzw. mein Ziel war es, ohne zusätzliche "Daemons" auf dem Ziel-PC auszukommen - also kein Mini-HTTP-Server, der auf Requests lauscht etc.
Das gelingt mit SSH ganz wunderbar (sofern es auf dem Ziel-PC läuft, aber das ist ja per Default so). Die Sache hat nur einen Haken: Beim Standard-SSH-Befehl kann man kein Passwort übergeben (aus Sicherheitsgründen...), das macht das Absetzen eines Befehls unmöglich (ohne Login läuft halt nix).

Nun gibt es zwar die Möglichkeit die SSH-Keys lokal zu kopieren (also auf den EDOMI-Server), aber das ist mir zu unflexibel und umständlich. Die Lösung ist denkbar einfach: Das Programm "expect" (ein Standard-Linux-Tool) kann u.a. Usereingaben simulieren (Script-gesteuert). Und so kann man das Passwort scriptgesteuert "eingeben lassen"

In der Praxis sieht das dann so aus (alles unter CentOS7 beim Zielsystem - bei EDOMI kann's auch 6.5 sein):

• erstmal auf dem EDOMI-Server "expect" installieren (yum install expect)
• dann einmal eine SSH-Session mit dem Zielsystem starten, damit die Keys generiert werden usw. (ssh user@IP)
• und ab hier kann man für alle Zeiten wie folgt Befehle auf dem Zielsystem ausführen (z.B. in EDOMI mittels HTTP/UDP/SHELL):

In den Standby schicken (und ggf. per WoL wieder aufwecken) oder Herunterfahren:

Standby:
expect -c 'set timeout 3; spawn timeout 3 ssh root@<IP-ADRESSE> "systemctl suspend"; expect "password:"; send "<PASSWORT>\r"; interact'

WoL:
/sbin/ether-wake -i eth0 <MAC-ADRESSE>

Shutdown:
expect -c 'set timeout 3; spawn timeout 3 ssh root@<IP-ADRESSE> "shutdown -h now"; expect "password:"; send "<PASSWORT>\r"; interact'

Die Steuerung des Monitors funktioniert auf viele Art und Weisen (xset, etc.) - bei mir klappt's am Besten mit "xrandr" (die Parameter müssen aber ggf. angepasst werden, diese Parameter sind für die VM ausgelegt, insbesonder "Virtual1" als Displayname...)

Ausschalten:
expect -c 'set timeout 3; spawn ssh root@<IP-ADRESSE> "DISPLAY=:0 && export DISPLAY && xrandr --output Virtual1 --off"; expect "password:"; send "<PASSWORT>\r"; interact'

Einschalten:
expect -c 'set timeout 3; spawn ssh root@<IP-ADRESSE> "DISPLAY=:0 && export DISPLAY && xrandr --output Virtual1 --auto"; expect "password:"; send "<PASSWORT>\r"; interact'

Die Bildschirm-Steuerung läuft bei mir unter CentOS7 mit "Gnome" wunderbar, aber wie gesagt bislang nur in einer VM. Ich warte noch auf echte Hardware...

Linux-Profis werden vermutlich die Hände über'm Kopf zusammenschlagen, aber mein Ziel war ja... siehe oben...