shutdown restart startet FHEM nicht neu

[MadMax-FHEM]

Kommt drauf an auf welchem System...

Eine neuere Installation auf Systemen mit systemd haben einen "autostart"...

Gibt Threads im Forum dazu...

Wenn du da fhem stoppen willst, dann mittels systemctl...

Code: [Auswählen]

sudo systemctl stop fhem
Oder

Code: [Auswählen]

sudo systemctl stop fhem.service

(keine Garantie, ist "aus dem Kopf")

Gruß, Joachim

[Sammy51]

Ja hat geklappt - stand auch im Blog von Otto

Wenn ich dann node installiere und fhem-alexa wird dann das SSH Zeug auch nicht automatisch wider überschrieben?

https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa#node.js_installieren

hmm.. EDIT: rpi3b @Buster

Code: [Auswählen]

pi@raspberrypi3b:~ $ node --version
v10.21.0
pi@raspberrypi3b:~ $ sudo npm install -g alexa-fhem
       
npm WARN npm npm does not support Node.js v10.21.0
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9.
npm WARN npm You can find the latest version at https://nodejs.org/
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
/usr/local/bin/alexa-fhem -> /usr/local/lib/node_modules/alexa-fhem/bin/alexa
+ alexa-fhem@0.5.57
added 63 packages from 71 contributors in 25.041s

[MadMax-FHEM]

Bei mir wurde bei noch keinem Umzug was überschrieben...

Bzw. selbst wenn: du hast doch das tar noch

Starte doch alexa-fhem einfach mal (Alexa-Device aus Backup einspielen) und schau, ob sich alexa-fhem noch mit dem Skill verbindet...

Wenn nicht: entweder noch mal neu verknüpfen (oder eben aus dem tar einspielen)

Was willst du mir der "Installationsausgabe" mitteilen?

Sieht doch so aus, als wäre es installiert!?

Gruß, Joachim

[Sammy51]

Hat halt etwas rumgenörgelt die Installationsausgabe das irgendwas nicht geht oder vielleicht nicht geht.

Alexa Ist jetzt eingespielt soweit. Gemäß folgender Anleitung jedoch ohne die Schritte in FHEM - da es ja durch das Backup bereits definiert sein sollte. Richtig? Noch nicht getestet.
https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa

Sonos auch nochmal eingerichtet - das klappt im Test erstmal nicht.
https://wiki.fhem.de/wiki/SONOS#Einbindung_von_Sonos_in_FHEM

Sollte ich jetzt vielleicht auch den NUC (jetzt merkt man das der raspi doch ein gutes stück langsamer ist; jedenfalls beim basteln darauf) erstmal abschalten bevor ich mit dem Raspi weiter mache und die enocean und zwave Sticks übernehme?
HMLAN und Hue kann er ja vermutlich schon ansprechen - aber doppelt verbunden geht zumindest mit HMLAN nicht ordentlich glaube ich.

[MadMax-FHEM]

Zu Sonos kann ich nichts sagen...

Ja, wenn ein Alexa-Device definiert war, kommt es aus dem.Backup (wie ja geschrieben)...

Ansonsten wie man halt umzieht...

Aktuelles System runterfahren, HW umstecken und Backup einspielen und das neue System mal starten...

Dann muss man halt sehen...

Wenn USB-Sticks etc. verwendet werden, sollten diese by-id eingebunden sein, sonst kann/wird es sein, dass die Defines auf dem neuen System nicht mehr stimmen...

EDIT: HMLAN kann nur eine Verbindung. HUE-Bridge (zumindest deCONZ) kann mehrere Verbindungen. Die Anmeldedaten sind ja (normalerweise) im Backup. Ansonsten halt noch mal verbinden (Knopf drücken bzw. Gateway "freigeben")...

Dies und andere Fehler im Log korrigieren...

Aber: was soll schon passieren?

Du hast ein Backup und das aktuelle System...

Gruß, Joachim

[Sammy51]

Zu Sonos kann ich nichts sagen...

Wenn USB-Sticks etc. verwendet werden, sollten diese by-id eingebunden sein, sonst kann/wird es sein, dass die Defines auf dem neuen System nicht mehr stimmen...

Die USB Einbindung habe ich gemäß Eurer Tipps schon vor dem Backup auf dem NUC eingerichtet
Den NUC abschalten und RPI produktiv setzen könnte morgen klappen (mit etwas potentieller Zeit falls es zunächst wo klemmt; wenn das nur Sonos wäre für die Sprachausgabe wäre das im ersten Moment nicht dramatisch; aber unschön). Wenns direkt klappt ist die Zeit morgen dann fürs Löten des HM-Moduls angedacht.
==> Überlege es original zu verlöten um es prinzipiell auch auf dem Raspi nutzen zu können - dann aber per Stiftleiste und angelöteten Drähten an den USB-Adapter "zu stecken".
==> Dann bin ich flexibel (auch wenns nicht so elegant sein wird optisch wie die minimal USB-VAriante im Gehäuse).
==> zudem ist dann der Nutzen der Schutzwiderstände und der Stützkondensatoren gegeben.

[MadMax-FHEM]

Ich würde halt nicht zu lange (fliegende) Drähte nehmen, nicht dass sich das Funkmodul was "einfängt"...

Du kannst aber die USB-Variante auch am PI betreiben.

Hab ich auch...

Viel Erfolg, Joachim

[Sammy51]

Stimmt schon hab ich auch schon überlegt wär praktisch aber vermutlich zu quick-n-dirty praktisch einfach alles zu stecken mit 10cm Drähten zwischen USB und HM-Modul    Das USB auch am RASPI  geht ist klar aber häßlicher wirds, da mit Zusatzplatine kaum möglich es in ein USB-Stick-Gehäuse zu fummeln.

Kinder schlafen hab jetzt kurz getestet klappt ohne Problem mit raspi-3b jetzt produktiv.

==> Selbst Alexa läuft ohne Neueinrichtung durch Eure .ssh Tipps :-)

==> Die Sonos tuns auch wieder inkl. Textausgabe (eigentlich das einzige was ich davon bislang via FHEM zum Spaß nutze). Soll wohl Leute geben die es blöd finden wenn "Die Tante sagt - Das Licht im Hauswirtschaftsraum ist seit 10min an" *g*
          ==> Was komisch ist .. einer der Sonos heißt in FHEM immer noch Schlafzimmer (vielleicht war das mal der Name)
          ==> Über Alexa und die Sonos App ist der seit längerem aber "Büro" ?!
          ==> Idee wie FHEM das aktualisiert?

Enocean ebenfalls noch nicht ganz rund - aber ansprechbar ist es:

Code: [Auswählen]

EnOcean Cryptographic functions are not available.
2020.11.27 21:56:42 2: EnOcean XML functions available.

[MadMax-FHEM]

Na dann: gratuliere!

2020.11.14 11:06:18 2: EnOcean Cryptographic functions are not available.
2020.11.14 11:06:18 2: EnOcean XML functions available.

Habe ich auch so...
...vermutlich: schon immer

Ich schätze, dass das "nur" bedeutet, dass eben keine "verschlüsselte" Kommunikation unter den Komponenten möglich sein wird...

Aber fraglich, ob das in fhem überhaupt implementiert ist bzw. werden kann.

Ist bei ZWave ähnlich, da ist auch noch nicht alles bzgl. "verschlüsselter" Kommunikation implementiert...


Und bzgl. Sonos bleibe ich dabei: keine Ahnung


Ich hatte ein ähnliches Problem mit meinen Echos.
Allerdings nicht in fhem sondern per Amazon-Sprache.

D.h. in fhem war alles ok (da heißen die Echos mit dem Echodevice-Modul eh ECHO_XXXXX / nur der alias ist dann der Name bei Amazon)...
...auch per Alexa-App.

Nur wenn ich per Sprache sagte: Alexa spiele Musik auf Büro

Spielte die Musik auf dem "Ex-Büro", der halt nun laut Alexa-App aber Schlafzimmer war...

"Lösung": zurücksetzen und neu anlernen...

Gruß, Joachim

P.S.: das ssh-tar ist bei mir fester Bestandteil des fhem-Backups. Dazu habe ich das ssh-tar im /opt/fhem Verzeichnis liegen mit Besitzer fhem (eh klar). Dadurch landet das tar in jedem fhem Backup

[Otto123]

Sonos auch nochmal eingerichtet - das klappt im Test erstmal nicht.

Was  klappt denn da nicht?

[Sammy51]

Alias sind doch doof. Ob ich alle löschen sollte? Ist ja inuitiver für Anpassungen, at notify watchdog und so sachen wenn man immer den "echten" Namen sieht.

Bzgl. der Sonos (EDIT:"Alte, verwirrende Namen") Thematik war es scheinbar nur ein Alias. Weiß nicht mehr ob ich die mal manuell gesetzt habe oder die ursprünglich automatisch übernommen wurden.

Enocean ohne Verschlüsselte Übertragung war auch bei der NUC Installation.

Auf Deinen Echos kannst Du aber keinen Sprache ausgeben - oder?

Was  klappt denn da nicht?

Die Testsprachausgabe ging gestern nicht. Heute gings. Geändert hab ich nichts nur den "alten" Server heruntergefahren und evtl. FHEM auf dem neuen nochmal neugestartet.

[MadMax-FHEM]

Alias sind doch doof. Ob ich alle löschen sollte? Ist ja inuitiver für Anpassungen, at notify watchdog und so sachen wenn man immer den "echten" Namen sieht.

Naja habe ja nicht ich gemacht, sondern macht das echodevice-Modul automatisch...

Wenn man umbenennt weiß ich nicht, ob das noch funktioniert (vermutlich ja).
Aber wenn man dann wieder "autocreate devices" ausführt, dann werden die "ID-Namen" ja wider angelegt...

Für mich ist das so ok...

Auf Deinen Echos kannst Du aber keinen Sprache ausgeben - oder?

Doch.
Mit dem echodevice-Modul: https://forum.fhem.de/index.php/topic,82631.msg747482.html#msg747482

Einfach: set ECHO_XXXX speak das ist ein Test

Gruß, Joachim

[Sammy51]

Ah cool .. vor Jahren ging das zunächst nicht mit Echo Devices

Bzgl. Alias sind doch doof meinte ich mich selbst - nicht dich.
Mein scheinbares Sonos Problem mit den verwirrenden Namen lag nur an falschen / nicht aktualisierten alias 

[MadMax-FHEM]

Bzgl. Alias sind doch doof meinte ich mich selbst - nicht dich.

Ich hab's auch nicht auf mich bezogen, sondern auf: "allgemein" aliase sind doof

D.h. es geht jetzt alles was du wolltest?

Gruß, Joachim

[Sammy51]

Zunächst schon - danke :-) System in umgezogen und Betriebssystem dadurch aktualisiert. Was vorher ging geht wieder :-) Ubuntu auf dem Nuc werde ich dann testweise mal "hochziehen" um Erfahrung zu sammeln ob das gelingt (ohne grafische Oberfläche könnte es ja selbst per SSH klappen vielleicht).

* Darüber hinaus hab ich eine Zeitsteuerung für den Garten bislang immer manuell zwischen "Sommer" und "Wintermodus" umgestellt durch Ein bzw. Auskommentieren in der fhem.cfg. Das ist natürlich wenig elegant und fhem.cfg soll ja offenbar besser nie editiert werden. Besser wäre sicherlihc wenn zB. der Dummy mit dem ich diese Automatik an/ausschalte ":Sommer :Winter :off" als Buttons/Stati hätte und die Steuerung dann das eine oder das andere "at" verwenden würde.

Macht das Sinn so oder gibts noch bessere Varianten? Hab erstmal die Stati erweitert und versuche nun die "at" anzupassen mit Berücksichtigung von "Sommer" und "Winter" statt bislang "on"

Code: [Auswählen]

Internals:
   FUUID      5d028802-f33f-826a-d81b-c9b19c18744db32d
   NAME       GT.Power.NordPool_Automation
   NR         138
   STATE      off
   TYPE       dummy
   READINGS:
     2020-11-28 21:52:41   state           off
Attributes:
   alexaName  Pool Automatik
   alias      NordPool Automode
   devStateIcon on:general_an_fuer_zeit@green off:general_aus_fuer_zeit@red
   icon       general_an_fuer_zeit
   room       Garten
   setList    Sommer Winter on off
   webCmd     Sommer:Winter:on:off
* Das HM RPI Modul hab ich soeben Standardmäßig verlötet bin noch unsicher ob ich es jetzt erstmal in der Schublade lasse solange HMLAN noch funktioniert oder ob ich es als RPI Hat Modul verwende oder den USB Adapter ausmesse (3,3 V und Verlöte). Mit etwas Muße ginge das statt mit Drähten evtl. auch mit einem Reststück Lochrasterplatine die noch in einer Bastelkiste liegen sollte. Kleiner macht es das natürlich auch nicht und es wäre vermutlich ne Skizze nötig um zu schauen wie dort verbunden/unterbrochen werden muss für die korrekte Verbindung der USB/RPI Stiftleisten. Aus der Übung mit so Zeug . Kurze Kabel wohl doch einfacher ;-)

* Ansonsten Vorbereitet (Kabel muss noch in Schaltschrank der Garage eingeführt und verdrahtet werden) ist noch ein Z-Wave Bewegungsmelder für außen mit Helligkeitssensor davon (also nur vom Dämmerungssensor) abhängig soll die Weihnachtsbeleuchtung und sonstige Dinge draußen geschaltet werden. Bewegungsmelder + Dämmerungssensor davon dann künftig für noch zu montierende Wegbeleuchtung.


====

EDIT: Achso da wäre noch was Grundsätzliches bzgl. des nun RPI3b betriebs mit SDCard ... war da nicht noch was zu konfigurieren damit LEse/Schreibzugriffe auf die KArte reduziert werden? Oder gibt es gar empfehlenswerte Ansätze das ohne SD-Karte oder mit ergänzender SSD an USB zu lösen?  (der RPI3 hat wohl nur USB2 glaube ich)?

Die Variante von Beta USer scheint auch super mit dem "alten" Thin-Client als Basis .. aber jetzt läuft ja erstmal der RPI der zu lange in der Schublade lag

Beste Grüße
Sammy