Sommerpause beendet - und schon die erste Frage...

[gaert]

Da mein wandhängendes Android-Tablet vor ein paar Tagen auf "curved display" geupdated wurde (das physische Akkuvolumen hat sich über Nacht vervielfacht...), baue ich an einer "richtigen" Lösung (4K-Touchscreen und Mini-PC).

Mit Android-Billig-Tablets bin ich also durch und daher meine Frage: Braucht irgend jemand die EDOMI-Android-App (und die dazu gehörigen Befehle in EDOMI)? Sonst entferne ich die App beim nächsten Update, einschließlich der entsprechenden EDOMI-Funktionen.

Da ich bald Android-frei bin (zumindest an der Wand), werde ich die App wohl eher nicht weiterentwickeln - und dann schleppen wir ewig eine App-Leiche herum.

Übrigens kann man mit ein paar Tricks bequem per Shell-Befehl (Einzeiler) remote den Bildschirm ein- und ausschalten, in den Standby gehen etc. - einfach per SSH. Bedeutet: Auf dem Zielsystem muss nix installiert werden und kein zusätzlicher Dämon auf irgendein TCP-Paket lauschen. Details folgen im nächsten Update...

[uzi10]

Suuuuper,. dass freut mich aber das es dir gut geht! Toll das du weiterarbeitest!
Auf was läuft der mini PC??

verwende dein App nicht

[hartwigm]

gaert
welcome back, schön mal wieder was von dir zu hören, und dann auch noch mit der Andeutung eines Updates

Android frei - von meiner Seite aus sehr gern

[lamiro]

Hey, welcher Glanz in unserer Hütte!!!

Ganz klar die „richtige Lösung“. Tablett ist ganz nett, aber das geht immer (wie du schon schreibst).

Viele Grüße,

Lars

[MiBu1983]

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.

[spielkind1611]

Welcome Back,
Ich muss sagen ich nutze die App schon seit einiger Zeit.
Kann aber notfalls auch wieder darauf verzichten.
Dann muss WOLI halt den Bildschirm einschalten.

Liebe Grüße
Stefan

[ThomasCologne]

...Dann muss WOLI halt den Bildschirm einschalten.

https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/33661-woli2?p=1567693#post1567693

Apps für einen solch kleinen Nutzerkreis sind kaum noch sinnvoll bei dieser schnellen Entwicklung und den verschiedensten Plattformen. Daher eher pro Shell und gegen eine App.

[panzaeron]

Mit Android-Billig-Tablets bin ich also durch und daher meine Frage: Braucht irgend jemand die EDOMI-Android-App (und die dazu gehörigen Befehle in EDOMI)? Sonst entferne ich die App beim nächsten Update, einschließlich der entsprechenden EDOMI-Funktionen.

Von meiner Seite ist auch kein Bedarf, es gibt auch genug Alternativen...

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

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

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

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

[uzi10]

Geht das auch dann mit einer virtuellen Umgebung wie proxmox?

[Peterich]

Geht das auch dann mit einer virtuellen Umgebung wie proxmox?

Kannst du durchreichen ja

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