Produktiv- und Testumgebung oder wie testet ihr

[hanshome]

'nabend,

meine Produktivumgebung*) ist ja nu noch sehr klein (nur ein Sensor&2*Aktor), aber das wird ja wachsen. Die Kiste für die weitere Ausbaustufe steht ja schon hier. Daher mal sone grundsätzliche Frage: Wie entwickelt ihr eure FHEM-Umgebung weiter? Macht ihr das in eurer Produktivumgebung? Oder habt ihr parallel dazu eine Testumgebung aufgebaut?

Wenn man nur erweitert sehe ich das ja völlig unkritisch, also z.B. mehr Sensoren/Aktoren der gleichen Bauart die man schon hat. Aber wenn man z.B. ganz was neues macht... besteht da nicht die Gefahr dass man sich seine produktive Umgebung stilllegt? Kann ja auch aus Versehen passieren, weil z.B. irgendwas nicht zusammenpasst o.ä. Ich sehe außerdem die Gefahr dass in derartigen Fällen der WAF deutlich sinkt.

*) die ist bei mir aktuell ein Pi3 mit nanoCUL und Signalduino. Allerdings mittlerweile auch schon mit Echo-Anbindung, da wirds natürlich schwierig mit einer Testumgebung

Grüße

[rudolfkoenig]

Ich teste/entwickle auf dem Laptop, man kann aber auch auf einem RPi locker mehrere FHEMs parallel starten, man muss nur die FHEMWEB/telnet Ports und Log-Verzeichnisse sauber trennen. Wenn man auf "Nummer Sicher" gehen will, dann installiert man FHEM zweimal, das geht einfach mit einem "sudo cp -r /opt/FHEM /opt/FHEM.test". Die Ports aendern muss man trotzdem, sonst startet FHEM nicht.

Zum Entwickeln starte ich FHEM im Terminal, mit "attr global logfile -", da sieht man die Logausgaben direkt, und Beenden (Ctrl-C)/Neustarten (Pfeil nach oben, Return) ist sehr bequem.

Zum Bedienen verwende ich telnet bzw. "socat TCP:fhemhost:7072 readline,history=$HOME/.telnet_history" (mit einem alias) aus einem zweiten Fenster, weil ich damit command-line editing und history habe, und relativ grossen Scrollback-Puffer. Hier aktiviere ich mit "inf timer" das Event-Reporting.

Auf dem Testsystem kann man Events per trigger simulieren, und damit notifies testen, ein at mit "set execNow" testen.
Oder man baut ein "FHEM2FHEM / LOG" zum Produksystestem auf, um "echte" Events zu haben. Falls man die readings des Produktivsystems abfragen will, dann kann man cloneDummy, oder mit einem aktuellen FHEM2FHEM ein dummy mit dem gleichen Namen anlegen.

Wenn es einigermassen tut, dann kann man die Hardware umstoepseln und Code kopieren. Code mitnehmen ist am einfachsten mit "list -r <device>", das entspricht "Raw definition" aus dem FHEMWEB Detailfenster. Das gibt man entweder in dem "produktiv-telnet" ein, oder in einem beliebigen "Raw-definition" des Produktiv-FHEMWEBs. Wenn man vorher ein Kopie von fhem.cfg+fhem.state macht, dann ist man eigentlich auf der sicheren Seite, man kan aber auch ein (komplett-)backup machen.

[peterk_de]

Der etwas Entwicklungsfernere Ansatz, wenn es nur darum geht, neue Devices / Regeln / Spielerchen aus Anwendersicht etc. für sich selbst  hinzuzufügen: Das mach ich  je nach Kritikalität wenn niemand sonst zu Hause ist direkt am Produktivsystem. Vorher (insbesondere vor FHEM-Updates jeglicher Art!!) ein FHEM-Backup. Am Licht oder der kleinen "Amateur-Alarmanlage" z.B. Nachts herumzuspielen hat sich nicht bewährt

OS-Updates oder Änderungen an der Hatdware des Haupt-FHEM-Servers (apt-get upgrade oder dist-upgrade, neuer USB-Sensor etc.) sind auch so ein Thema: grundsätzlich nur nach einem Voll-Backup des gesamten Systems und mit viel zeit alles ggf. wieder ans Laufen zu bekommen.  Der Umzug von FHEM in eine virtuelle Maschine und dazu ein seperater "Hardware-Raspi" mit allem USB-Zeugs, aber ohne eigene Notifies/DOIFs etc. erleichtert bei mir seit kurzem dieses Vorgehen gewaltig.

Zu beachten ist, dass ich kritische Sachen (Heizung, Licht) so aufgebaut habe, dass die auch ohne FHEM funktionieren können. Fällt FHEM weg, fällt Smart aus und Home bleibt

[A.Harrenberg]

Hi,

Zum Entwickeln starte ich FHEM im Terminal, mit "attr global logfile -", da sieht man die Logausgaben direkt, und Beenden (Ctrl-C)/Neustarten (Pfeil nach oben, Return) ist sehr bequem.

ich starte mein Testsystem (unter Linux) mit

Code Auswählen Erweitern

perl fhem.pl fhem.cfg |tee -a log/fhem.log
dann sehe ich die Logausgaben UND habe sie in einem Logfile...
Alternativ kann aber aber auch normal loggen lassen und sich das Logfile mit

Code Auswählen Erweitern

tail -f <logfile> anzeigen lassen.

An socat scheitere ich unter Debian (Jessy) aber gerade... Da ist der Support für READLINE in SOCAT entfernt worden da die Lizenzen von socat/readline/openssl da wohl inkompatibel sind. Das kompilieren von neutralen sourcen klappt aber gerade auch nicht, auch ein selbstgebautes socat sagt das es readline nicht kennt...

Das war dann wohl der Grund warum ich das schon mal nicht hinbekommen habe.

Aber Dein Text ist eine gute Zusammenfassung, könnte so ins Wiki

Gruß,
Andreas.

[A.Harrenberg]

Hi,

kaum macht man es richtig funktioniert es auch... Die "dev" Dateien von readline waren nicht installiert. 

Falls also jemand mal vor dem gleichen Problem (Debian) steht:

Socat-sourcen runterladen: socat-2.0.0-b9.tar.gz
Readline installieren:

Code Auswählen Erweitern

apt-get install libreadline6
apt-get install libreadline6-dev

Sourcen von socat entpacken, im Verzeichnis

Code Auswählen Erweitern

./configure --enable-readline
make all
ausführen.
Mit

Code Auswählen Erweitern

./socat -V kann kontrolliert werden ob der Support auch wirklich einkompiliert wurde, im Output sollte dann ein " #define WITH_READLINE 1" auftauchen.

Ich habe KEIN "make install" gemacht da ich nicht abschätzen kann ob das dann im System zu irgendwelchen Nebeneffekten führt und werde das jetzt einfach aus dem Verzeichnis heraus starten.

Endlich Commandline MIT History 

Gruß,
Andreas.

[hanshome]

Danke für die Antworten! Das mit der Kopie von /opt/fhem sagt mir momentan am meisten zu, da kann man ja dann auch mit verschiedenen Versionen der fhem.cfg spielen.